wiki:Outlook2007

なぜ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)