Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for header "folding" and "unfolding" as described in section 2.2.3).
セマンティクスとしては、unstructured field のボディ部分は、単純なキャラクターの連続として扱い、それ以上の処理を施すべきではない、と書かれている。つまり、それが ISO-2022-JP のシークエンスのように見えても、それは US-ASCII として扱うべきだ、(RFC2047 の形式で無い限り)、プロアクティブに「何か別のコード体系」として処理してはならない。
いい加減、Microsoft も実践的な解法に従うべきではないのか。つまり、Subject にRFC2047で定義されたセマンティクスを与えてやればよい。たんに ISO-2022-JP を B-Encoding するだけで達成できる。そして、日本語対応を謳うメールクライアントなら、Subject 行の B-Encoding された ISO-2022-JP なら間違いなくデコードできる(※2)。
僕の手元に Outlook 12 (Outlook 2007?)があるわけではないので、送信者がどのような設定をしているのかはわからない。だが、どのような設定であれ、ISO-2022-JP をベアで(つまり生 JISで) Subject に突っ込むべきではないと思う。そのぐらい、もう Outlook を日本市場に投入して長いのだから、いい加減改めろよな、と思う。
※1
まわりくどい言いかたをしているけれど、つまりは 7bit ということ。
※2
もちろん、B-Encoding がまっとうに行われていれば、の話。外国産のメールクライアントには、いまだに B-Encoding を RFC に書かれたとおりに行わないものがある。行のフォールディングに CR + LF を使わずどちらかだけになっているとか、一行が 75文字を越えているとか、US-ASCII 部分と encoded-word 部分が一文字以上の空白文字で区切られていない、とか...
そもそも、B-Encoding などという「しちめんどうくさいこと」をしなければ日本語の情報が交換できないということ自体、現行の規格には無理がある。そろそろ、7bit ではないと通信路上でのデータの安全が確保できないなどという前世紀のくびきから解き放たれて良いころだろう。8bit 転送を前提に、よりシンプルなマルチバイト文字の交換が本当の意味で可能になるのはいつの日のことか...