ZDNet Mobileが2002年6月4日付けで「FOMAはメールも第3世代？ 人騒がせなFOMAのEメール」という記事を掲載しました。この記事を要約すると、

• NTTドコモのFOMAからDDIポケットのライトEメールへメールが届くと「添付あり」と表示されるが実際には添付が存在せず、接続料金の５円が余計にかかる。
• この原因はFOMAのメールヘッダのContent-Typeが常にmultipartであるのが原因である。
• 他のキャリアや一般的なメールソフトで問題なくメールが受信できるのはContent-Typeを無視しているからだ。
• 可視テキスト（text/plain）メールに添付が無いのにContent-Typeにmultipartをつけるのは誤りである。
• この誤ったヘッダを出すFOMAのメールサーバーを改修すべきだ。

というものです。

では実際に本当にFOMAのメール仕様に問題があるのか見てみましょう。まず、FOMAから送信したメールをメールサーバーからPOP3で受信したものを以下に示します。（メールアドレスを隠すためにその部分に限り、一部修正しています。）

さて、指摘のあったメールヘッダのContent-Typeは確かにmultipartが指定されています。しかし、メールのボディ部分にはきちんと指定されたmultipartが存在しています。そのpartの中にはContent-Typeがtext/plain; charset-ISO-2022-JPとなった、通常の本文が格納されています。

この部分の仕様はRFC2045～RFC2049によって定義されています。このうち、今回の件に関する部分はRFC2046に規定されています。このRFCの「5. Composite Media Type Values」近辺を読むとわかるように、partが１つだけでなおかつtext/plainが入っているのはまったく問題がありません。したがって、「FOMAのメール仕様に誤りがある（原文：誤まったヘッダ情報でEメールを送信してくるのはFOMA、正確にはドコモのメールサーバだからだ。）」、という指摘は誤りであるといえます。もちろん、FOMAのメールもこの様な回りくどいことをせずに、一般的なメールで行われているような構造にした方がリスク回避に役立つ、と指摘していればまったく問題なかったしょう。それどころか、むしろ問題提起としてよかったのではないでしょうか。

では、このメールを添付メールとして処理をするDDIポケットのメールサーバに問題はないのでしょうか？　multipart実際の処理系としては添付ではないものを添付と不適切な判断をしているのですが、RFCに違反していると決め付けることもできないという状態であると思います。ただし、実際に営業用のサービスとしてどうかと問われれば、添付でないものを添付として判断してユーザーに全文受信する様に即す処理は明らかに問題のある処理だと言えるでしょう。「FOMAに対応する」という意味ではなく、より正しいmultipartへの対応とユーザーに対して適切なサービスを提供すると言う意味で、早急に改修すべきであると思います。

つまり..。双方とも問題がまったく無いとはいえないという話です。しかし、ZDNet Mobileの記事では「FOMA側のメール仕様に誤りがある」という書き方をしてしまっており、非常に問題でしょう。この点について、NTTドコモは正式に抗議してもいいくらいだ、と思います。

結論としては、添付ではないmultipartメールを添付と判断してしまうDDIポケットのメールサーバに問題があるが、FOMAのメールについても改善すべき点はある、というところでしょう。

さて、FOMAのメールのヘッダなのですが、生成はサーバではなくFOMA端末側で行っているようです。というのも、Content-Typeのmultipartで指定されるboundaryの文字列が、機種によっては明らかに規則性が異なることが確認できました。前述のメールはP2101Vのもので、ランダムな英数字が使用されていますが、N2002ではboundaryにmimemk00あるいは本文にboundary行と同一と評価できるものがあれば00をカウントアップしていき一致しないものを使用していました。

このことから、メールヘッダはFOMA端末側の仕様に左右されそうな雰囲気です..。完全にメールサーバーがタッチしていない、というわけではないかもしれませんが。