なぜOutlook 2007がダメなのか
Outlook 2007は良くないです。
いや、いまどき「Outlook(Express)は邪悪だ」キャンペーンではありません。
Outlookは邪悪なのか
マイクロソフトがマイクロソフトだという理由だけで邪悪な会社だと言われたように、Internet Explorerがまたマイクロソフト製だという理由だけで邪悪だと言われたように、Outlookも邪悪だと言われ続けた時代がありました。たいていの《ちょっと知ってる人》は皆、OutlookとOutlook Expressの区別も付いてないのに、ことさらに「Outlookは良くない」と言い張りました(OutlookとOutlook Expressは全く違うソフトウェアですよ)。ちゃんと技術を知っている人さえも、OutlookやOutlook Expressを使うのは人にあらずと言わんばかりに非難しました。Outlookのせいでウイルスに感染するとか、ね。そりゃ、Outlook(など)が完璧で素晴らしいソフトウェアでないにしても、そこらの他のメールソフトに比べたら格段に使いやすいですよ。そこらのパソコン初心者のほぼ全員が使っていて、なおかつ、曲がりなりにも使えてるってことが証明してます。
…という、Outlook擁護は今回の主題ではありません。
Outlook 2007
Outlook 2003にしてもOutlook Express 6にしても、まあまあ真っ当なソフトウェアだったと言えます。 しかし、Outlook 2007はちょっとひどい。マイクロソフト製品がひどかった時代に戻ってしまったようです。 見た目は素晴らしいんですけどね。
何なのかと言えば、MIMEマルチパートにするとRFCに違反するのです。 メールにファイルを添付したりHTMLメールにしたりするとマルチパートなMIMEメッセージに成ります。 すると、RFCに違反したメッセージを生成してしまうのです。 うちではSMTPサーバとして、RFC違反にとても厳しい「courier」を使っています。 courierは、Outlook 2007で送信したマルチパートなメールを通してくれません。 エラーとして、怒りのメールが返ってきます。
怒りのメールはこんなかんじ。
CORRUPTED MESSAGE This is the Courier Mail Server 0.53 on hotei.accense.com. I received the following message for delivery to your address. This message contains several internal formatting errors. This is often caused by viruses that attempt to infect remote systems. Instead of blocking this message, I converted it to a safe, text-only attachment that can be safely read with a text editor. This sometimes also happens when the sender's mail software has a bug that creates improperly-formatted messages. Although these kinds of formatting errors may often be ignored by other mail servers, this server detects and intercepts improperly-coded messages in order to prevent viruses from taking advantage of bugs in E-mail programs: ----------------------------------------------------------------------------- This message contains improperly-formatted binary content, or attachment. See <URL:ftp://ftp.isi.edu/in-notes/rfc2045.txt> for more information. -----------------------------------------------------------------------------
このメールには、問題となったメールがテキストファイルとして添付されているので開いてみます。 前後をだいぶ省いていますが、こんな感じです。
To: "'sgk'" <sgk@accense.com> Subject: =?iso-2022-jp?B?GyRCJEYkOSRIJEEkYyRzGyhC?= Date: Wed, 4 Jun 2008 18:09:19 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001D_01C8C66E.1C0C9CF0" X-Mailer: Microsoft Office Outlook 12.0 これは MIME 形式のマルチパート メッセージです。 ------=_NextPart_000_001D_01C8C66E.1C0C9CF0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B$F$9$H$A$c$s$J$N!A(B $B$b!<!#(B
うおっ。日本語入ってますよ! 「これは MIME 形式のマルチパート メッセージです。」って。 シフトJISですよ! これが悪さをしているようです。 こんなとこにシフトJIS入れていいんだっけ??
ここ、普通は「This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages.」とか何とか書いてある部分ですよね。 誰かさんが素直に日本語訳しちゃったようです。
Outlook 2007が悪いのかcourierが悪いのか
こんな場所にシフトJISの文字列をつっこんだOutlook 2007が悪いのでしょうか? それとも、ASCII文字列を勝手に仮定して厳しいチェックを行ったcourierが悪いのでしょうか? RFCを読んでみます。
「RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types」
There appears to be room for additional information prior to the first boundary delimiter line and following the final boundary delimiter line. These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line or after the last one. NOTE: These "preamble" and "epilogue" areas are generally not used because of the lack of proper typing of these parts and the lack of clear semantics for handling these areas at gateways, particularly X.400 gateways. However, rather than leaving the preamble area blank, many MIME implementations have found this to be a convenient place to insert an explanatory note for recipients who read the message with pre-MIME software, since such notes will be ignored by MIME-compliant software.
「最初の区切り文字列の前、最後の区切り文字列の後は、通常はカラにするが、何か入ってても無視しなさい。 ただし、ここに、MIMEに非対応のメールソフトを使っている人に向けたメッセージを入れるような実装が多い。」 とのこと。 「何が入ってても無視しなさい」で無視すべき対象として、ASCII文字列以外を含めるのか含めないのかって問題。 ASCII以外も無視するのが正しいのなら、口うるさいcourierが悪くて、Outlook 2007は悪くない。
もっと読み進めます。
Appendix A -- Collected Grammar
By itself, however, this grammar is incomplete. It refers by name to
several syntax rules that are defined by RFC 822. Rather than
reproduce those definitions here, and risk unintentional differences
between the two, this document simply refers the reader to RFC 822
for the remaining definitions. Wherever a term is undefined, it
refers to the RFC 822 definition.
discard-text := *(*text CRLF)
epilogue := discard-text
preamble := discard-text
最初の区切り文字列の前のことを「preamble」、最後の区切り文字列の後のことを「epilogue」と呼んでいます。 「text」が何を指すのかわかりません。 「この構文定義で定義してない要素についてはRFC822を見なさい」ってことなので、見てみます。
「RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES」
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
これによれば、textはASCIIコード0x00~0x7fの範囲の文字でなければならないらしい。
そんなわけで、「最初の区切り文字列の前、最後の区切り文字列の後は、何か入ってても無視しなさい」とは言うものの、0x80~0xffの範囲の文字を入れるのは間違っているように思います。 この論理で言えば、Outlook 2007が悪い。
courierの言い分
courierはなぜそこまでRFCに厳しいのでしょうか。
courierの開発者に言わせると、迷惑メールを排除するため、だそうです。 迷惑メールを送信するプログラム、特に、わけわかってない素人スパマー向けに作られたPC用ソフトや、ウィルスに仕込まれたボットのSMTPクライアントなどは、RFCをきちんと守ってないことが多いのだそうです。そのため、SMTPのやりとりや、届いたメッセージの内容を厳しくチェックすると、一定数の迷惑メールは簡単に排除できるというわけです。
まとめ
そんなわけで、意味もわからずにむやみに日本語訳しちゃったOutlook 2007がひどいって話です。 IISのHTTPサーバが「404 みつかりません」とか日本語で返してきたのを見たときよりも驚きました。
でも、courierはそこまで厳しくチェックするべきなのかという疑念はやはり残ります。
当社社内はOutlook 2007禁止にしました。 社内はこれにて一件落着なのですが、心配なのは、うちのお客様がOutlook 2007を使った場合です…。 どうしましょう。困りました。
(2008/6/6 - sgk)
