ヘッダの扱い方を知っていると、トラブルの原因究明に役立つ場合が非常に多いです。
ここでは、ヘッダ全体の扱い方を説明します。
一つ一つの意味を知りたい人は、付録のヘッダフィールド一覧をみてください。
ヘッダは、メールの先頭に付いています。ただし、MIMEによって分割した部分に付く場合もあります。
ヘッダ中のDate:、From:、Subject:等の事をフィールドといい、これには、
等があります。
ただし、ヘッダの一部を隠してしまうソフトやマシンもあります。その代わり「送信者」、「題名」など、重要と思われるところを見やすく表示しているようです。
Return-Path:エンベロープの MAIL FROM:の内容Received:サーバの経路情報 From:書いた人のアドレス Sender:送った人のアドレス To:送り先のアドレス Cc:コピーの送り先のアドレス Date:メールを送信するタイミングの日時 Subject:主題 Comments:本文に付け加えるコメント Message-Id:メールを一通一通区別する為の文字列 References:どのメールを参照すべきかを示す元メールの Message-IdIn-Reply-To:どのメールへの返信かを示す元メールの Message-Id
本文は人間が読むためのものですが、ヘッダは機械が読んで処理を行なうためにも使われます。だから、扱い方が細かく決まっていて制約が厳しいのです。
特に決まりの厳しいフィールドはstructured header fieldと言います。「構造化ヘッダフィールド」とでも訳しましょうか。
Subject:とComments:は人間が読むのが主な目的なので、他のフィールドよりは制約が緩く、unstructured header fieldと言います。「非構造化ヘッダフィールド」とでも訳しましょうか。
ヘッダは、次のように書きます。
それぞれをフィールドとかヘッダフィールドと呼びます。
フィールド名: フィールド内容
という書き方です。
基本的には1行に1フィールドです。ただし、スペースや水平タブで字下げしてある場合は前の行の続きなので、まとめて1フィールドです。
上の例では、Received:フィールドの内容が長すぎるので3行になっています。
括弧()の部分はコメントといい、機械は読み飛ばします。人間が読むためのオマケ情報を書き加えるのに使います。
上の例では、Received:のところに、何やらサーバ名らしき情報がついてますね。
ただし、Subject:等のフィールドはもともと人間が読むためのものなので、括弧()があっても特別扱いしません。
一部のフィールドでは、「;」で区切ったパラメータというより詳しい情報を付ける事が出来ます。
パラメータ名=パラメータ内容
という書き方です。
上の例では、Content-Type:フィールドに「charsetはISO-2022-JPだよ」「formatはfixedだよ」という2つのパラメータが付いています。
フィールド名に大文字/小文字の区別はありません。SUBJECT:もsubject:もSuBjEcT:も、おんなじです。
メールヘッダを隠しているマシンやソフトの場合、設定をいじると見えるようになるかもしれません。
また、メールを保存しているファイルを探して、テキストエディタ等で表示すると見えるかもしれません。
メーリングリストによっては、一部のフィールドを書き換えたり消したりするものもあります。
一部のパソコン通信や携帯電話やグループウェア等でインターネットメールを受け取ると、大部分のフィールドが削除される場合があります。また、全てのフィールドを受信しているのに、保存するときに大部分を削るソフトもあります。
メールヘッダが消えてしまった場合、
等の弊害があるかもしれません。
以前は、ヘッダに日本語は使わないという申し合わせがありました。ヘッダは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で書くのが無難でしょう。
パラメータにはとても厳しい決まりがあります。
通常はあんまり気にしなくてもいいのですが、添付ファイルの名前に日本語を使った場合などに問題が発生します。
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
この方法は未だ定着しておらず、間違った方法を使っているソフトの方がずっと多いです。
× "B" encodingや"Q" encodingを使っている × Shift_JISを使っている × EUC-JPを使っている × ISO-2022-JPを使っている ○ RFC2231方式を使っている
みんなそれぞれ、別の間違い方をしているので、ファイル名に日本語を使うとトラブルが発生する事が多いのです。
RFC2822に代表される多くのRFCでは、メールの最初の空行までの全部をheaderと呼び、To:やCc:等の行それぞれをheader fieldあるいは単にfieldと呼んでいます。
ただし、RFC2076では、前者をheading、後者をheaderと呼んでいます。
でも、様々な文書や会話等では、どっちもヘッダと呼んでいる場合を多くみかけます。フィールドという言葉はあまり定着していないようで。
ヘッダ中のスペースや折り返し(folding)の扱いは曖昧です。
英語等のラテン系言語では、スペースや折り返しは、単語と単語の区切りでしかありません。スペースを連続したり、何文字分字下げしても、所詮は単語の区切りなのです。
つまり、
Subject: aaaa bbbb
cccccccc
dddd
は、
Subject: aaaa bbbb cccccccc dddd
と同じだと考えるのです。
ところが、日本語のために"B" encodingや"Q" encodingを使った場合は、途端にルールが難しくなります。あまりにも難しすぎるようで、ほとんどのソフトは正常に処理出来ません。これが原因で、スペースが消えたり、変なところに現われたりします。
例えば、
Subject: こんにちは Hello
の筈なのに、
Subject: こんに ちはHello
にみえたりします。
この問題の詳しい解説は、インターネットメイルに関することのページ書かれています。
なお、ヘッダではなく本文に変なスペースが現れる現象は、別の原因です。
メールアドレスの書き方は、RFC822、1123で決められていましたが、2001年4月からRFC2822に置き代わっています。
もっともシンプルな書き方は、次のような感じです。
To: ユーザ名@ドメイン
To: taro@example.com
「@」の前がユーザ名で、後ろがドメインです。
ただし、本当は「ユーザ名」ではなく、local partといいます。人間ではなく自動システムが送受信する場合もあるので、「ユーザ名」という言い方はあまり正しくないかもしれません。
アットマーク「@」やドット「.」の前後にスペースを入れたり、行を区切って字下げする事も出来ます。ただし、この方法は推奨されていません。
To: taro @ example . com
To: taro
@example.
com
メールアドレス自体を括弧「<>」に入れる事も出来ます。この場合、アドレスの前に表示名(display name)を付ける事が出来て、この書き方が推奨されています。ソフトが名前を表示するときに使う事を想定しています。
To: <taro@example.com>
To: Taro Urashima <taro@example.com>← 推奨
To: "Taro Urashima" <taro@example.com>← 推奨
表示名を「""」で括ると、この部分をヒトカタマリとして扱えという意味になります。そのまま表示名に使うと問題が出る文字がある場合に威力を発揮します。例えば、カンマ「,」はアドレスの区切りに使う文字ですから注意が必要です。
To: Urashima,Taro <taro@example.com>← Urashimaとtaro@example.com宛
To: "Urashima,Taro" <taro@example.com>← 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.com
To: taro (Taro Urashima) @example.com
To: (Taro Urashima) taro@example.com
ところで、ドメインは大文字/小文字の区別がありません。どっちで書いてもokです。
次の2つは同じです。
To: taro@example.com
To: taro@ExAmpLe.coM
一方、ユーザ名に大文字/小文字の区別があるかどうかは、そこのネットワーク次第です。ネットワーク管理者に聞いてみないとわかりません。
また、ユーザ名で使っている文字がメールアドレスでは使えない事があります。その場合、大抵はユーザ名全体を「""」で括れば大丈夫です。
次の2つの例は、使えない文字スペース「 」とカンマ「,」が入っているケースです。
To: "urashima taro"@example.com
To: "urashima,taro"@example.com
特にカンマ「,」が入っているときに「""」で括るのを忘れると、ソフトは2つアドレスがあると解釈してしまうので注意しましょう。
To: urashima,taro@example.com← urashimaとtaro@example.com宛
もっと面倒なのは、ユーザ名に「"」や「\」が入っている場合です。このときは「""」で括っただけではダメだという決まりがあるので、直前に「\」を付けます。
次は、ユーザ名が「urashima"taro」の場合と、「urashima\taro」の場合です。
To: "urashima\"taro"@example.com
To: "urashima\\taro"@example.com
あと、どこを中継するか指定する方法がありましたが、廃止になりました。現在はソフトがDNSというシステムを使って届け先を調べるので、わざわざ指定する必要がないのです。
次は、サーバA → サーバB → サーバC の順に経由してからtaro@example.comに送る事を指定する%-hackという方法です。
To: taro%example.com%サーバC%サーバB@サーバA
更に、UUCPでは「!」記号を使って経路を指定する方法があります。これに関してはRFC976に情報があります。しかし、現在はUUCP自体がほとんど使われていません。
以上の様に色々な書き方が出来るわけですが、複雑な書き方をすると処理に失敗するソフトもありますから、ほどほどにしておくのが無難です。
そもそも、メールの扱いを決めているRFC2822はASCIIに限定されており、それ以外の文字コードは対象外なので他の文書に委ねる事になっています。
ISO-2022-JPをヘッダに使う場合、MIMEの"B" encodingや"Q" encodingやRFC2231形式を使うしか手段はありません。
特に深刻なのは、structured header fieldの場合です。
エスケープシーケンスが悪さをするのです。エスケープシーケンスには括弧「(」が入っており、これはコメントを書くのに使うものですから、ソフトが混乱するのです。他にも混乱を招く文字がいくつかあり、それらを避けるように作られたのが、"B" encodingや"Q" encodingやRFC2231形式なわけです。
宛先のフィールド (To:、Cc:、Bcc:) にISO-2022-JPをそのまま使うと、アドレスを理解できなくなって送受信や配送に失敗する可能性すらあります。
各ヘッダの定義は、様々な文書にバラバラに書かれていて、探すのが大変ですが、RFC2076に一覧があるので便利です。ただし、あまり厳密ではありませんし、これに全部載っている訳ではありません。
RFC2231はパラメータでASCII以外を使う方法を決めていますが、"B" encodingと"Q" encodingに言語名を追加する方法も決めています。
例は[11.5.3]に載せました。これによれば、
=? 文字コード * 言語名 ? 変換方式 ? 内容 ?=
だそうです。