メールヘッダとは、メールの頭に付いていて、様々な情報を提供します。
これには、
等があります。
メールアドレスとかSubject(題名)はここに含まれます。
Return-Path:配送エラーの場合の報告先アドレスReceived:サーバの経路情報Date:メールを送り出すタイミングの日時From:書いた人のアドレスSubject:題名Sender:送った人のアドレスTo:送り先のアドレスCc:コピーの送り先のアドレスMessage-Id:メールを一通一通区別する為の文字列References:どのメールを参照すべきかを示す元メールのMessage-IdIn-Reply-To:どのメールへの返信かを示す元メールのMessage-Id
本文は人間が読むためのものですが、ヘッダは機械が読んで処理を行なうのにも使われます。だから、制約が厳しい。
また、ヘッダはマシンやソフトによっては隠してしまう場合があります。その代わり「送信者」、「題名」など、重要と思われるところを見やすく表示しているようです。
メールヘッダを隠しているマシンやソフトの場合、設定をいじると見えるようになるかもしれません。
また、メールを保存しているファイルを探して、テキストエディタ等で表示すると見えるかもしれません。
メーリングリストによっては、一部のメールヘッダを書き換えたり消したりするものもあります。
一部のパソコン通信や携帯電話やイントラネット等でインターネットメールを受け取ると、大部分のメールヘッダが削除される場合があります。また、ちゃんとヘッダも受信しているのに、保存するときに大部分を削るソフトもあります。
メールヘッダが消えてしまった場合、
等の弊害があるかもしれません。
以前は、ヘッダに日本語は使わないという申し合わせがありました。ヘッダはASCIIのみの世界だったのです。
だから今でも、本文には日本語が使えるが、ヘッダには使えないソフトが現存します。
でもやっぱり日本語が使いたいのは、Subject、名前、ファイル名等でしょうか。
かつては、Subject:はASCIIを使って英語表記したりローマ字表記したのです。
次は、「Subject: 先日の件について」というISO-2022-JPのメールヘッダが化けた一例です。
ところで、後になってからMIMEという決まりが出来て、Subject:等のヘッダで英語以外が使えるようになりました。
これはASCIIの文字列に変換してしまう方法で、"B" encodingと"Q" encodingの2種類があります。
次は、"B" encodingに対応していなかった為に、そのまま表示された例です。
次は、"Q" encodingに対応していなかった為に、そのまま表示された例です。
「=? 文字コード ? 変換方式 ? 内容 ?=」という形式です。
どちらも元に戻せば、「Subject: 先日の件について」になります。
日本語のメールヘッダに対応していないマシンやソフトで受信した場合、上の様に謎の文字列を拝むことになります。
受信者のマシンやソフトがわからない場合、メールヘッダに日本語を使うべきではないのです。あらかじめ、読めるかどうか聞いておきましょう。
"B" encodingや"Q" encodingを解読するツールは、困った時のツール集で紹介しています。
Subject:にISO-2022-JPを使った場合は化ける程度で済む場合が多いのですが、To:やCc:やBcc:等に使った場合はメール自体が送信出来なかったり、届かないこともあります。
メールアドレスの一番シンプルな書き方は、次のような感じです。
taro@example.com
ところで、このメールアドレスには、名前を付け加えるべきだとされています。
メールソフトは、この名前を表示すると便利だという事ですね。
Taro Urashima <taro@example.com> 現在、使うべきだとされる書き方 taro@example.com (Taro Urashima) 使うべきではないとされる書き方
マシンやソフトに「自分の名前」を設定するところはありませんか？また、アドレス帳のような機能があって、名前を書く部分がありませんか？
ある場合、上のどちらかの方法で名前が設定されるでしょう。
ない場合は、メールアドレスを指定するところで直接書けるかも知れません。管理者が設定しているのでユーザが変更出来ない場合もあります。
この自分の名前に日本語を使う人がいます。
浦島太郎 <taro@example.com>
この日本語がISO-2022-JPだと、誤動作してメールが届かない可能性があります。
そこで、MIMEの"B" encodingに変換するわけです。
=?ISO-2022-JP?B?GyRCMTpFZ0JATzobKEI=?= <taro@example.com>
これだとちゃんと届きますが、対応してないマシンやソフトでは結局誰だかわかんねえことになります。ASCIIで書くのが無難でしょう。
この意味でも、本文の最後に署名 (signature)を付けると確実だと思います。
一部のヘッダでは、「;」の後にパラメータ (paramater) と呼ばれるオマケの情報を付ける事が出来ます。
このパラメータにはとても厳しい決まりがあるため、添付ファイルのファイル名に日本語を使った場合などに問題が発生します。
次の例は、「charsetはISO-2022-JPだよ」というオマケ情報が付いています。この例では特に問題はありません。
Content-Type: text/plain; charset=ISO-2022-JP
ところが、このパラメータには、次のような厳しい決まりがあるので面倒です。
MIMEでは、Content-Disposition:ヘッダのfilenameパラメータでファイル名を示す事になっているのです。
○ 正しい Content-Disposition: attachment; filename=data.zip ○ 正しい Content-Disposition: attachment; filename="data.zip" × 間違い Content-Disposition: attachment; filename=資料.zip × 間違い Content-Disposition: attachment; filename="資料.zip" × 間違い Content-Disposition: attachment; filename==?ISO-2022-JP?B?GyRCO3FOQRsoQg==?= × 間違い Content-Disposition: attachment; filename="=?ISO-2022-JP?B?GyRCO3FOQRsoQg==?="
つまり、元々日本語ファイル名を付ける方法がなかったのです。
これは困る話なので、多くのメールソフトは、ISO-2022-JPやShift_JISや"B" encodingを使ってファイル名を表します。間違いを承知でやってるのでしょう。
ところで、1997年になって、ASCII以外を扱う方法がやっと出来ました。この方法には特に呼びやすい名前はついてません。
(原書にはMIME Parameter Value and Encoded Word Extensionsと書かれています。原書の番号からRFC2231方式と呼んだりもします。)
○ 正しい Content-Disposition: attachment;
filename*=ISO-2022-JP'ja'%1B$B%3BqNA%1B%28B.zip
○ 正しい Content-Disposition: attachment;
filename*=''%1B$B%3BqNA%1B%28B.zip
ファイル名が長いときは、次のようになります。
○ 正しい Content-Disposition: attachment;
filename*0*=ISO-2022-JP'ja'%1B$BBh%3B02s%3F7%40%3D%1B%28B;
filename*1*=%1B$BIJ3+H%2F%40oN%2C2q5D$K$D$$$F$N%3B2%1B%28B;
filename*2*=%1B$B9M%3BqNA%1B%28B.zip
この方法は未だ定着しておらず、間違った方法を使っているソフトの方がずっと多いです。
みんなそれぞれ、別の間違い方をしているので、ファイル名に日本語を使うとトラブルが発生する事が多いのです。
メールヘッダは、メールの先頭に付く場合と、MIMEによって分割した部分に付く場合があります。
色々種類があるので、ここでまとめて紹介します。頭痛がしてきたら読み飛ばして[9]に行きましょう。これらはマシンやソフトによっては表示されない場合もあります。
ただ、変なメールが届いた時、ヘッダを調べると謎が解けるかもしれません。
SUBJECT:もsubject:もSuBjEcT:も、おんなじです。大/小文字の区別なし。
Content-で始まるヘッダは、MIMEで決まったものです。(Content-Type:だけ例外あり)
X-で始まるヘッダは、「ユーザ定義」という事になっているので、送受信者間の合意がなければ意味をなしません。でも実際には特に断わりもなく使われているヘッダがいくつかあるので、著者の経験と想像で説明しています。
To: ichiro@example.net
送り先のメールアドレスです。送信側で指定します。
複数のTo:ヘッダを使えば複数のアドレスが指定出来ます。ひとつのTo:ヘッダに複数のアドレスをカンマ「,」で区切って指定することも出来ます。マシンやソフトによっては別な区切り方をするかも知れませんが、送信時に正しい形式に変換している筈です。
Cc: jiro@example.net, saburo@example.org
コピーの送り先です。送信側で指定します。
To:で送ったものと同じメールが届きます。複数のcc:ヘッダを使うか、カンマ「,」で区切れば複数のアドレスも指定できます。マシンやソフトによっては別な区切り方をするかも知れませんが、送信時に正しい形式に変換している筈です。
Bcc: shiro@example.com, goro@example.net
To:やCc:に複数のアドレスを書くと、ヘッダに情報が残るので、「ははーん、誰々が受け取ったな」ということが判ります。Bcc:に書いたアドレスはヘッダから消えるので、誰々が受け取ったのか判らないように出来ます。「お知らせメール」などで、互いに関係のない方々に送るときに便利かもしれません。
このとき、To:を空欄にしたり、To: (My Friends)の様に括弧で文字を書くだけの人がいますが、この使い方は間違いです。To:には1つ以上のアドレスを書かなければなりません。
そうでないと隠したはずのBcc:のアドレスが見えてしまうことがあります。To:には取り敢えず自分のアドレスを書くのが、常套手段かもしれません。
でも、受け取った人は自分のアドレスがヘッダにないので、不審に思うかもしれません。本文中で「XXXの皆様へ。これはbccのメールです」と書いておくと、安心だと思います。
From: taro@example.com
メールを書いた人のアドレスです。
これは必ず付けなければならないので、一度設定しておけば自動的に付けてくれるマシンやソフトが多いようです。間違えないように十分に確認してください。管理者が設定してくれるところでは、ユーザは何もしなくてもよい場合もあります。
万が一このヘッダが無い場合、エンベロープのMAIL FROM:の情報を使って、From:を作り出すメールサーバもありますが、これは本来は正しい動作ではありません。
Sender: hanako@example.net
送った人のアドレスです。From:と同じ場合は省略出来ます。
書いた人と送った人が違うときに使われます。例えば、
From:に社長のアドレスを示し、Sender:に代理で送信した秘書のアドレスを示すFrom:に共著したグループのアドレスを示し、Sender:に実際に送信したメンバー一人のアドレスを示す等です。
ユーザが勝手にFrom:を書き換えたとき、管理者が設定した本来のアドレスをSender:に付けるソフトも実在します。
MSAと呼ばれるサーバは、From:に異常を発見したとき、正しいメールアドレスをSender:に付ける事になっています。
Reply-To: yamada@example.org
返信先です。
From:とは別のアドレスに返信して欲しいとき、ここに書きます。送信側で指定します。
また、メーリングリストでは、自動でメーリングリストのアドレスをここに付ける場合があります。このとき問題が出る場合があるのでメーリングリスト管理者に聞いてみてね。
In-Reply-To:とは別物です。
Subject: about next week meeting
メールの題名です。
付けなくても良いヘッダですが、ネチケットガイドライン (RFC1855)では、「内容を反映したSubjectを付けるべきだ」とされています。
例えば、「Subject: 教えて」よりは「Subject: 明日の予定を教えて」の方がわかりやすいでしょう。
なお、返信のときは、元のメールのSubjectに「Re: 」をつけても良いことになっています。自動で付けてくれるソフトが多いです。
「Subject: Re: 明日の予定を教えて」という感じですね。「Re:」の直後にスペースが一つ入っている事に注意しましょう。
この「Re」はラテン語「res」を由来とする英単語であり、「〜に関して」という意味です。
中には、RE:という大文字を使うものもみかけます。あと、何度もやり取りしたとき、Re^2:だとかRe[2]:という風に数字を付けるものもありますが、3人以上でやり取りするとこの数字が意味をなさなくなるのは明らかですね。Re: Re:のように重なっていく場合もありますが、大抵、元のメールのSubject:でRe:もまとめて "B" encoding されていたため、返信時にRe:が付いているのに気付かず更にRe:を付けてしまった場合が多いようです。
Subject:の情報を使ってメール一覧を並べ変えて見やすくするものもあります。
Date: Fri, 04 May 2001 01:02:00 +0300
メールを送信した時間です。例えば、「送信」ボタンを押す瞬間です。
必須のヘッダなので、サーバに渡すときにメールソフトが付けなければいけません。
2000年問題に対応するため、西暦は4桁以上で書かないとだめになりました。ただし、かつては2桁も認められていたので、00年とか01年とかを受け取った場合はちゃんと2000年、2001年という風に換算しなければなりません。
曜日と秒は省略出来るし、日にちは1桁でも良いので、Date: 4 May 2001 01:02 +0300と書いてもオッケーです。
+0300という数字は時間帯(time zone)であり、協定世界時(UTC)との時差です。
UTCはグリニッジ平均時(GMT)とほとんど同じですが、うるう秒を考慮しています。つまり「59分60秒」という時間もあり得るのです。
時間帯は通常、書いた人の地域に合わせます。日本からだと+0900で、緯度ゼロの地域からだと+0000です。地域に関係なく世界時(UT)のままで表したいときは-0000にします。
かつては、この時間帯にアルファベットを使う事が出来ました。もしアルファベットになってるメールを受け取った場合は、次の表のように換算します。
GMT,UT +0000 EDT -0400 EST,CDT -0500 CST,MDT -0600 MST,PDT -0700 PST -0800
この表には日本標準時(JST)がありません。JSTで送信するメールソフトが結構ありますが、そもそも昔から間違いだったのです。日本製のソフトは+0900に換算してくれるものが多いですが、日本国外製は心配です。
あと、軍事用の時間帯でAとかBの様にアルファベット1文字で示す方法がありましたが、これは非標準です。更に元々の規格書に書き間違いがあったので、-0000に換算すべきという事になってます。
ところで、Date:ヘッダを付けないメールソフトも結構ありますが、これは間違いです。サーバが代わりにDate:ヘッダを付けるのも禁止なので、結局Date:ヘッダがないまま受信者に届いて問題が起きる事があります。実際には付けてくれるサーバもありますが、本来は間違いです。ただし、MSAと呼ばれるサーバは、認証を行なってから付けてもよい事になっています。
Message-Id: <0123456789.AA12345@example.com>
メールを1通1通区別するための文字列です。
インターネットは世界レベルですから、世界で唯一のMessage-Id:でなければいけませんが、これが守られていないケースは非常に多いです。
偶然に同じMessage-Id:が付いたメールが届いた場合、区別が出来なくなって配送されなかったり、読めなくなる可能性があります
このヘッダは付けなくても間違いではありませんが、付けるべきだとされています。ないときにサーバが代わりに付けることもありますが、これは本来は正しい動作ではありません。ただし、MSAと呼ばれるサーバは、認証を行なってから付けてもよい事になっています。
In-Reply-To: <123443210.BB12345@example.net>
どのメールへの返信かを表します。
返信するときに、元のメールのMessage-Id:の中身を付けるのです。複数のMessage-Id:をここに書いてもいいですが、通常なら1つだけですね。
元々このヘッダは、以前届いたメールの日付とか名前とかメールアドレス等、色んなフレーズを書いて良かったのです。例えば、「In-Reply-To: Ichiro's mail of "Thu, 19 Sep 1996 22:11:05 +0200" <123443210.BB12345@example.net>」のような感じです。
しかし、2001年4月に決まりが変わって、Message-Id:の中身だけを書くことになりました。
この情報を使ってメール一覧を並べ変えて見やすくするものもあります。
Reply-To:とは別物です。
References: <19960902101520.AA0F@example.net> <AbCdEfGh%saburo@example.org> <123443210.BB12345@example.net>
参照って意味ですね。
返信するときに、元のメールのReferences:とIn-Reply-To:とMessage-Id:の中身を全部つけます。
だから、何度もメールをやり取りするとどんどん増えていきます。
元々このヘッダは、以前届いたメールの日付とか名前とかメールアドレス等、色んなフレーズを書いて良かったのです。
しかし、2001年4月に決まりが変わって、References:とIn-Reply-To:とMessage-Id:の中身だけを書くことになりました。
この情報を使ってメール一覧を並べ変えて見やすくするものもあります。
Mime-Version: 1.0
メールの本文がMIMEの決まりに沿っていることを示します。MIMEの決まりに従ったマシンやソフトは自動で付けるでしょう。
今のところ、バージョン1.0しかありません。
Content-Type: xxxx
Content-Type:以下は、本文の形式を示します。
xxxxの部分には、印刷用の形式POSTSCRIPTだとか、TEX等の文字が入ります。これはMIME登場以前からあるヘッダです。
Content-Type: xxxx/xxxx
Content-Type:以下が、xxxx/xxxxのようにスラッシュで区切られているものは、MIMEで拡張されたヘッダです。
本文やMIMEによって分割した部分の形式を示します。
Content-Type: text/plain;
charset=iso-2022-jp
text/plainとは「ただのテキスト」ですね。
MIME未対応だとこのヘッダは付きません。
charset=というパラメータは、本文の文字コードを表しています。charset=が書いてない場合はUS-ASCIIです。
日本語メールの場合、本文中のエスケープシーケンスを見れば「日本語だな」という事がわかる筈です。しかし、このヘッダがないと日本語であることに気付かず文字化けするものも実在します。
ISO-8859-1等だと何の文字コードなのか判別出来ないので、どうしてもこのパラメータが必要になります。
Content-Type: text/html;
charset=iso-2022-jpこの場合「htmlのテキスト」ですね。これはwebブラウザ等で使われているものです。
Content-Type: text/enriched;
charset=iso-2022-jpこの場合「エンリッチド テキスト」ですね。ワープロの様に文字を装飾出来る方式です。
Content-Type: multipart/mixed;
boundary="ABC123"
この場合「マルチなパートがミックス」つまり「複数の部分が一緒」ですね。
これを使うと、メールの本文を複数に分割できます。
例えば、MIMEを使って普通の文章にファイル等を添付したとき等に使われます。boundary=でそれぞれの部分の区切りを示します。詳しくは[10]を見てください。
Content-Type: multipart/alternative;
boundary="ABC123"
この場合、「マルチなパートから選択できる」ということです。
つまり、複数の形式がboundary=で区切られているけれど、実は同じ内容なのでどれかを選んで読めばいいという事です。
例えば、普通のテキスト(text/plain)とhtmlのテキスト(text/html)なのだが文章は同じ場合とか、英語と日本語なのだが内容は同じ場合だとか。
Content-Type: multipart/form-data;
boundary="CDE345"
WebブラウザのFORM機能を使って送られてきたメールに自動的に付いています。
メールの本文がboundary=で示した文字列で区切られ、それぞれのデータが付いている事でしょう。
Content-Type: application/x-www-form-urlencoded
WebブラウザのFORM機能を使って送られてきたメールに自動的に付いています。
メールの本文にURL encodingされた文字があることでしょう。
Content-Transfer-Encoding: base64
どんな方法でエンコードされたか書かれています。
7bit, 8bit, binary, quoted-printable, base64等があります。
このヘッダがない場合は7bitとして扱われます。
RFC1468によれば、ISO-2022-JPは最初から7bitなので、このヘッダは必要ありませんが、もし付けるならば7bitが正しい事になります。
Content-Disposition: attachment;
filename="test.zip";
creation-date="Wed, 12 Feb 1997 12:34:56 +0900";
modification-date="Wed, 12 Feb 1997 15:00:12 +0900";
read-date="Wed, 12 Feb 1997 19:29:51 +0900";
size=1024
扱い方が書いてあります。
attachmentとは「添付」の意味であり、受信者が手動で扱えとされています。ここがinlineだったら「インライン」の意味であり、マシンやソフトが自動で扱えという意味です。実際には手動だったり自動だったり様々です。
filename=のところにはファイル名が書いてあります。
creation-date=は作成時間で、modification-date=は更新時間で、read-date=は最後に読まれた時間です。size=はデータのサイズです。
Received:
from smtpserver.example.com
by mailgw.example.net
via uucp
with SMTP
id EAA09615
for <ichiro@example.net>
; Wed, 18 Sep 1996 04:26:36 +0900
メールを受け取ったサーバが付ける情報です。
ヘッダの一番上に付ける事になってます。だから、何台も経由した場合、下から上にReceived:ヘッダがどんどん増えていきます。
fromのドメインからbyのドメインがviaの接続方法を使ってwithの転送方法で受け取り、そのときの区別する番号がidで、forのアドレス宛です。「;」以降は受け取った時間です。
ここの時間を調べると、遅れて届いたメールがどこのマシンで停滞していたかわかるかも。
Return-Path: suzuki@example.net
一番最後にメールを受け取ったSMTP/ESMTPサーバが、Received:ヘッダの更に上に付ける事があります。
エンベロープのMAIL FROM:の内容を一番最後のサーバがReturn-Path:に書き写すのです。
POPで受信した場合等は、このヘッダが付いてない事もあります。
Encoding: 43 Text, 21 uuencode
MIMEでは本文を複数の部分に分割する事が出来ました。このEncodingヘッダは、MIMEとは別に考えられた方法です。
本文を空行で分割するだけの単純な方法です。この例の場合、普通のテキスト(text)が43行あり、1行空けてからuuencodeが21行あるという意味です。
X-Mailer: Super Mail Ver 1.2どうやら、送信側のメールソフトがソフト名とかバージョン番号を付けているように思われます。サーバがこのヘッダを付けているケースもあり、その場合はサーバ側のソフト名とバージョン番号になっているようです。
X-UIDL: 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5e6f
POPサーバがメール毎に自動で付けることがあるようです。
POPでは、届いたメールを区別する為に、unique-idという番号を付けます。この番号が示されているようですが、普通気にする必要はないと思います。
極一部のSMTPサーバもこのヘッダを付けることを確認しています。
ヘッダのところで、スペースや水平タブで字下げした行があったら、それは「前の行の続き」という意味です。つまり、
Header:AAAA BBBBBBBB CCC
は、
Header:AAAA BBBBBBBB CCC
を表しています。
ただし、日本語を使ったヘッダの場合は非常に難しいので、ここに書き切れません。インターネットメイルに関することのページに詳しい説明があります。
メールアドレスの書き方は、RFC822、1123で決められていましたが、2001年4月からRFC2822に置き代わっています。
もっともシンプルな書き方は、次のような感じです。
To:ユーザ名@ドメインTo:taro@example.com
「@」の前がユーザ名で、後ろがドメインです。
ただし、本当は「ユーザ名」ではなく、local partといい、人間ではなく自動システムが送受信したりする場合もあります。
メールアドレス自体を括弧「<>」に入れる事も出来ます。この場合、前に名前を付ける事が出来て、この書き方が推奨されています。
To:<taro@example.com>To:Taro Urashima <taro@example.com>
また、複数のメールアドレスにグループ名を付ける書き方もあります。ただし、この書き方はあまり使われていないようで、扱えないソフトもありますから注意しましょう。
ここで驚くかもしれませんが、メールアドレスの部分は省略出来ます。これで何故届くのか疑問に感じる人は、[12.4.2]を読んでください。
To:グループ名:メールアドレス;To:Sakana Dancers:tai@example.net, hirame@example.org;To:Sakana Dancers:;
括弧「()」はコメントを書く部分です。メールアドレスの前後や、アットマーク「@」やドット「.」の前後に途中に入れる事が出来ます。このコメントに名前を書く場合が多いですが、別に名前だけと決まっているわけではないです。コメントはソフトが読み飛ばすかもしれないので、ここに名前を書くのは勧められていません。
To:taro@example.com (Taro Urashima)To:taro@(Taro Urashima)example.comTo:taro(Taro Urashima)@example.comTo:(Taro Urashima) taro@example.com
アットマーク「@」やドット「.」の前後にスペースを入れたり、行を区切って字下げする事も出来ます。ただし、この方法は推奨されていません。
To:taro @ example . comTo:taro @example. com
ところで、ドメインは大文字/小文字の区別がありません。どっちで書いてもokです。
次の2つは同じです。
To:taro@example.comTo:taro@ExAmple.coM
一方、ユーザ名に大文字/小文字の区別があるかどうかは、そこのネットワーク次第です。ネットワーク管理者に聞いてみないとわかりません。
また、ユーザ名で使っている文字がメールアドレスでは使えない事があります。その場合、大抵はユーザ名全体を「""」で括れば大丈夫です。
次はユーザ名が「urashima taro」であり、使えない文字「スペース」が入っている場合です。
To:"urashima taro"@example.com
もっと面倒なのは、ユーザ名に「"」や「\」が入っている場合です。このときは「""」で括っただけではダメだという決まりがあるので、直前に「\」を付けます。
次は、ユーザ名が「urashima"taro」の場合と、「urashima\taro」の場合です。
To:"urashima\"taro"@example.comTo:"urashima\\taro"@example.com
あと、中継するメールサーバを指定する方法がありますが、よほど特殊な理由がない限り使う必要はありません。これは使うべきではないとされています。
次は、サーバA -> サーバB -> サーバC の順に経由してからtaro@example.comに送る事を指定しています。
To:taro%example.com%サーバC%サーバB@サーバA
以上の様に色々な書き方が出来るわけですが、複雑な書き方をすると処理に失敗するソフトもありますから、ほどほどにしておくのが無難です。
Subject等にISO-2022-JPをそのまま使ってはいけない理由はそれほどありません。ただし、対応していないマシンやソフトで読めないことは確かでしょう。
しかし、From:、To:、Cc:、Bcc:にISO-2022-JPを使うと、エスケープシーケンスが悪さをするのです。エスケープシーケンスには括弧「(」が入っています。括弧「()」はコメントを書くのに使うものですから、ソフトが混乱するのです。また、制御文字「ESC」が悪さする可能性もあります。アドレスを理解できなくなって送受信や配送に失敗する可能性があります。
MIMEのヘッダの決まりは結構複雑なので、完璧に扱えるマシンやソフトはほとんどありません。途中にスペースが混じったり、逆にスペースが消えたりする事があるのはこの為です。
これに関しては、インターネットメイルに関することのページに詳しい説明があります。
だから、こんな理不尽な方式はやめて、ISO-2022-JPをそのまま使うべきだと主張する人もいます。
各ヘッダの定義は、様々な文書にバラバラに書かれていて、探すのが大変ですが、RFC2076に一覧があるので便利です。ただし、あまり厳密ではありませんし、これに全部載っている訳ではありません。
RFC2231で、更なる拡張法が提案されています。
例は[11.5.3]に載せました。これによれば、
=?文字コード*言語名?変換方式?内容?=
だそうです。