英語での仕事の依頼メールに適切な返答が欲しい人に守ってほしい書き方のルール Posted by yoosee on English at 2013-03-30 13:43 JST1 英語業務メールの主な構造と特徴仕事柄、日本からのメールに目を通す事が多いのだが、現地社員や関連会社への依頼がうまく通じずに苦労しているのを見たりフォローせざるを得なくなったりすることが少なくない。英語能力自体の問題や仕事の理解の問題などについては上達してもらうしか無いのだが、仕事のやり取りの流儀的な所で引っかかっている人もしばしば見かける。その辺を踏まえ、英語で仕事をする人向けに英語の依頼メールを書くコツを少しまとめてみた。なにかしらの参考になれば幸いだ。 メールの構造 メールの主題・依頼内容は、理由は後述するが1通のメールに1つに絞る。メールの構成は概ね以下のようなものになる。 Subjectに特定しやすく分
▼ [雑] メールアドレスのバリデーション崩壊のお知らせ、もしくは、全てが UTF-8 になる JANOG31 のページをつらつら見てたら気になるセッションがあった。 「メールアドレスの国際化(JANOG25からの変更点)」というものだ。（多用されているかはともかく）Web で使われるドメイン名では国際化が進んでいたけど、メールアドレスに関してはほとんど進んでいなかった印象だったのに、どうも RFC での標準化がほぼ完了したらしい。 セッションページからダウンロードできる「IETF 85 報告 DNS, 国際化関連」という資料を見てみたら、次のような記述があった。 ほとんどすべてのメールヘッダにUTF-8を許可 – メールアドレス部 <ローカルパート@ドメイン名> – Display-name, (コメント), SubjectヘッダにもUTF-8 (従来はMIME) 資料には具体例も記載さ
今回は「岐阜大学」を取り上げました。 1人の軽い気持ちの転送設定が、数千人の利用者へ影響を与える。。 「岐阜大学」です。 http://www.gifu-u.ac.jp/imc/view.rbz?cd=165（2011/10/28） 10月27日午後から28日未明にかけて発生した電子メールの配送遅延では，利用者の皆様に多大なご迷惑をおかけし申し訳ございませんでした。 この度の障害の原因は，利用者による電子メールの転送機能を利用した一斉同時配信の設定ミス，具体的には以下ような状態によって引き起こされたことが確認されました。 ・転送先として1400件弱のメールアドレスを登録した転送用アドレスを作成した ・転送用アドレスを差出人アドレスとしてメールを送信した ・転送先の中に既に存在しないメールアドレスやメールアドレスの入力ミス等により配送不能な宛先が存在した その結果，以下のような状況が発生して
そんなわけで仕事の話を書いてみよう. どこかで誰かの名前を呼ぶとき, Twitter が @ で mention するように Google+ では "+名前" と書く. 人の名前の所は名字でもメールアドレスでも適当に補完してくれる. "+" の記法はきっとサービス名にちなんだのだろうけど, 以前からメールの中で使われてきた慣習でもある. 今の勤務先にやってきて, かつてよりだいぶ多くのメールを読むようになった. 以前は会社もチームも小さかったし分散開発でもなかったから, 一日の有効メール量は 10 通くらいだった気がする. 私は朝と晩の二回しかメールを読まなかったけれど, ほとんど支障はなかった. 今や私の Gmail は pin tab され, 一日 50 通くらい届くメールをさばいている. これは webkit-dev や chromium-dev, webkit-bugzilla (
はじめに インターネットが一般に普及した現在、電子メールはインターネット利用者の大半が使うコミュニケーションツールとなりました。 それに伴い迷惑メールが増加し、更にウイルスを配布するような攻撃にもしばしば利用されるようになってきました。 加えて近年では、今までの迷惑メールのような無差別な配布ではなく、特定少数を標的とした標的型メール攻撃と呼ばれる攻撃も散見されるようになってきています。 標的型メール攻撃において攻撃者は、企業情報、個人の Web ページや ブログ、メーリングリスト等から特定の個人情報等を入手し、知り得 た情報をもとに標的とされた特定の組織向けにメール文面などをカスタマイズし、その会社の幹部社員などからの社内文書や、組織が関連している分野の資料を装ったメールを作成します。 攻撃者は、標的となったユーザがつい開いてしまうような電子メールを送付することによって、ユーザにメールに添
Googleは、リアルタイムかつ組織的なインターネット上のコミュニケーションを求める需要に応じる上での、同社の回答姿勢を明らかにし始めた。 Googleは米国時間5月28日午後、サンフランシスコで開催の同社開発者カンファレンス「Google I/O」において、「Google Wave」の初の公式デモンストレーションを行った。「未来の電子メール」とも宣伝される、Google Waveは、電子メール、インスタントメッセージング、写真の共有、さらにおそらくは、開発者の協力を得ながら、ソーシャルネットワーキングの世界とのつながりまで統合し、電子メールの受信箱の再発明に挑む、同社の社内で複数年にわたって進められてきたプロジェクトの成果となる。 Google Waveは、「会話タイプのコミュニケーションと、コラボレーションタイプのコミュニケーションを結合する」試みであると、同社により、2004年にマッ
Subject: の日本語文字を符号化する方法(RFC 2047)とファイル名のそれ(RFC 2231)とが何故違うのか説明する機会がありましたので、ブログでも公開するとともに、僕の意見を述べさせてもらいます。 予備知識 Subject: の値に ASCII 文字以外を入れる場合は、RFC 2047 に従って符号化します。たとえば、 Subject: 日本語文字 は、以下のように変換されます。 Subject: =?iso-2022-jp?B?GyRCRnxLXDhsSjg7ehsoQg==?= 一方、「ファイル.pdf」というファイル名は、RFC 2231 に従って以下のように符号化します。 Content-Disposition: attachment; filename*=iso-2022-jp''%1B%24B%25U%25%21%25%24%25k%1B%28B%2Epdf RF
ここから署名です (ココカラショメイデス) セルフインフォ とは? このキーワードの内容に関わる方が 書いたキーワード（記事）です。 詳しくはヘルプをご覧ください。 署名とは、よくメールの最後に名前とか所属とかが書かれていたりしますが、それのことです。そのままですが、シグネチャともいいます。 署名に工夫を凝らしたりしているものもよく見かけます。特に、署名の上下につける飾り罫のようなものも、いろいろな種類があると思います。 --------- とか ********* とか ★★★★★ といった具合で。 この飾り罫が、いわば「ここから署名です」という合図にもなっているといえます。しかしこの合図には、事実上標準とされるものがあったりします。 その事実上標準とされる「ここから署名です」の合図とは、これです。 -- 実際、こういうのを合図にしている人も結構いますね。しかし実は
独立行政法人 情報処理推進機構（略称：IPA、理事長：藤原武平太）は、メールの受信に利用される認証方式の一つであるAPOP（エーポップ）方式におけるセキュリティ上の弱点（脆弱性）に関する注意喚起を2007年4月19日に公表しました。 具体的には、APOP方式にはパスワードが漏えいする脆弱性があるというものです。悪用されると、メールの受信に利用しているパスワードが、SSHやウェブサイトへのログインに利用しているパスワードと同一の場合、不正なログインに利用される可能性があります。 プロトコル(通信手順)上の問題であり、現時点で根本的な対策方法はありません。 回避方法は「『POP over SSL』や『ウェブメール』など、SSLによる暗号化通信を利用する」ことです。回避方法が取れない場合「メールのパスワードを他のシステムのパスワードと同一にしない」ことで悪用された際の被害を軽減できます。 電子メ
メールというコミュニケーションシステムは、 昔はシンプルでよかったのだが、 以下のような様々な問題点を持っている。 確実に届くかどうかわからない 読んでもらえたかどうかわからない 一度送ってしまうと訂正できない 発信者を詐称できる 誰にでも送れてしまう 送られてきたものはすべて受け取らなければならない 相手を知っていてもアドレスを知らなければ送れない テキストしか送れない アドレスを間違えやすい 複数の人間で情報を共有しにくい もちろん様々な工夫によりこれらの多くは解決されているのだが、 複雑な情報をきめ細かく交換したり共有したりするには根本的に向いていないので、 今後は消えゆく運命にあると思われる。 現在そういう兆候が全然見られないのは、 メールを完全に駆逐できる優れたコミュニケーションシステムが まだ発明されていないからなのだろう。 メールは使えるがWebは使えないような端末などほぼ存
WEBの活用により、様々な作業を効率よく進めることが可能になりました。しかしそれがあまりにも身近な存在となってしまったために、WEBがいかに私たちの生活を効率化しているかということにはあまり意識が向けられません。そこで逆の発想をして、WEBに「不便さ」を持ち込んでみようという人々が現れました： ■ Real snail mail (we make money not art) 様々な「あえて不便にしたIT」を紹介している記事。"snail mail"とは通常の郵便のことを指す言葉で、Eメールと対比させるために使われます。普通郵便はEメールよりもずっと遅く、かたつむり（snail）のようだということから（ついでに韻を踏んでいるので）"snail mail"なのですが、本当に snail にメールを届けさせようなんてアイデアが紹介されています。 まあ、そんなアイデア（Real Snail Ma
Expired：掲載期限切れです この記事は，ロイター・ジャパンとの契約の掲載期限（30日間）を過ぎましたので本サーバから削除しました。 このページは20秒後にNews トップページに自動的に切り替わります。
私は携帯電話のメール機能をほとんど使わない。PCメールを携帯電話からやりとりする（リモートメール、とかいうのだろうか）ことはあるのだが、それすらも自分から送るのは最小限にしている。理由は簡単で、打ちにくいからだ。あんな小さいキーボードで打てるわけないじゃん、と書いたあたりでもういまどきの人には「なんだこいつ」と思われているにちがいない。慣れた人が高橋名人ばりの速さで携帯メールを打つさまには、正直驚愕する。要するについていっていないのだ。 以上を前提として。 今回「発見」したのは、PCの電子メールを書くときの流儀が、私たちの世代と今の若い世代とではちがっている、という話だ。何いってるのあたりまえじゃん、となるのだろうが、とりあえず補足する。 私の世代だと、電子メールといえばPCで送受するものとして覚えた。メールを書くときに手本としたのは紙で書く手紙だ。電子メールができる前は、PC（とかワープ
<< 2005/09/ 1 1. AC体験 2 1. 夏休み 2. 夕食会 3 1. The Inbox Makeover 2. 図書館→電気工事 3. 人間の器 4 1. [教会] 松江 5 1. 目標管理 6 1. [Ruby] るびま 9号 2. 東京出張と台風 3. 眼鏡破壊 7 1. 自宅への長い道 8 1. [morq] ラベル検索 2. [Ruby] Ruby Committers Now on Basecamp 9 1. [言語] Python411 Podcast Series 2. 眼鏡作成 10 1. [Ruby] 『Ruby on Rails』入門 2. [原稿] UNIXUSER 11月号 11 1. [教会] 松江 12 1. [原稿] 日経Linux 11月号 2. 新しいソフトウェアの創造を - IPA「未踏ソフトウェア創業事業」成果報告会 3. [Ruby
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く