pasasの日記： J-Phone とメール

もしかしたら今後必要になる情報かもしれないのでメモ。

J-Phone には「スーパーメール通知」という機能があるらしい。
これが一体なんなのかはわからないけど、この機能を使ったメールでメール本文が表示されないことがあるらしい。
リンク先で書いているように、J-Phone では端末の故障ではなく、送信側プログラムの問題だと主張している。

この問題は、メールヘッダの中で、

• MIME-Version
• Content-Type
• Content-Transfer-Encoding

が記述されていないことが原因のようだ。
メーラを使用せずにプログラムから送信する場合、これらのヘッダを正しく気記述しないと、
メールが表示されないことがあるらしい。

でも、メールヘッダに MIME 関連のヘッダって本当に必須なの？

US-ASCII以外の場合は

[makoko (8394)]

RFC2045 [ietf.org] Multipurpose Internet Mail Extensions (MIME) Part One: によると、

Since RFC 822 does not specify mechanisms for mail containing audio, video, Asian language text, or even text in most European languages, additional specifications are needed.

(page2より抜粋)
との事で、US-ASCII以外、特にマルチバイト圏では実質必須と考えて良いと思います。

が、それはあくまでRFC的建て前であって、(特にWin/Macでは)大抵のMUAは Content-Type: text/plane; charset=iso-2022-jp だけ有れば本文は化けないと思いますけど。正しくエンコードされていれば。(UNIX系は出来ないとかでは無く、わたしの知識が無いだけです。申し訳ない。)

MIME自体、RFC1341系、1521系、からの改定になっていますし、本体のメールの方も821, 822から2821,2822になってますね。とりあえずRFC2822 [ietf.org]には必須とはなっていませんね。たぶん、US-ASCIIには、という限定が暗黙で付いてしまうと思いますが。

J-PHONEの問題に関しては、「他(PCやimodeなど)で問題なく読めているのに？」と言うのをどう考えるか？でしょうね。正しい事だけ行って、間違っているものはエラーにするのが理想かもしれませんが、結局MUAは、RFCだけ見ていては、いろいろと面倒なので。(例えばデコードすべきではないものでも、ユーザの声で対応せざるを得ないもの等多いはず。特にWin用は顕著でしょうね。あとはMozillaとか。)

Re:US-ASCII以外の場合は

[pasas (5776)]

詳細な情報ありがとうございます。

日記を書いてから、RFC2822 [ietf.org]、RFC2237 [ietf.org]、RFC2045 をざっと読んでみました。
ご指摘の通り、マルチバイト圏では実質必須となるようですね。
ただ今回は J-Phone が「自分たちは悪くない！！」のような主張をしているのがちょっと気にかかったのです。

全部で現象が発生するのではなく、一部の端末で問題の現象が発生するのは、開発者側としてはちょっと面倒です。
気をつけなければならないことが増える上、検証作業が大変なので。
ドコモの iアプリダウンロードの [ietf.org]４月問題もあったし [nttdocomo.co.jp]。