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.
US-ASCII以外の場合は (スコア:1)
との事で、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以外の場合は (スコア:1)
日記を書いてから、RFC2822 [ietf.org]、RFC2237 [ietf.org]、RFC2045 をざっと読んでみました。
ご指摘の通り、マルチバイト圏では実質必須となるようですね。
ただ今回は J-Phone が「自分たちは悪くない！！」のような主張をしているのがちょっと気にかかったのです。
全部で現象が発生するのではなく、一部の端末で問題の現象が発生するのは、開発者側としてはちょっと面倒です。
気をつけなければならないことが増える上、検証作業が大変なので。
ドコモの iアプリダウンロードの [ietf.org]４月問題もあったし [nttdocomo.co.jp]。