メールのヘッダーについて (Windows2000第8巻第2号参照)

2003/2/21

ヘッダー情報についての知識不足で、あるメーリングリストでの発信不能に陥った。そのMLでは発信者の認定をReturn-Pathで行っていた。Beckyでこの設定方法が分からず数日を費やした。副産物としてYahooの送信者認定の方法がわかり、Fromに別のプロバイダのドメインを使っても送信できることが分かった。

差出人に関するフィールド

From

必須

メールを作成した者の名前やアドレス。次のようにいくつかのスタイルがある。
アドレスのみ  From:jira@xxx.ne.jp
名前+アドレス From:Fujii Motoya<jira@xxx.ne.jp>
"名前"+アドレス From:"Fujii Motya"<jira@xxx.ne.jp>
"名前"+アドレス+コメント From:Fujii Motoya<jira@xxx.ne.jp>(office)

OEでは、アカウントのときに指定した「名前」とメールアドレスをFromに付けた3番目のスタイルで送信される。(Becky!では2番目のスタイル)

Sender メールの作成者と送信者が異なる場合に、送信者の名前やアドレスを記述するフィールドで、書式はFromと同一。作成者と送信者が同一ならば省略しても良いことになっている。
複数人が1本のメールを作成した場合、Fromですべての筆者の名前やアドレスを指定し、Senderフィールドで送信者を指定する。
これはRFC822にも規定されているが、OEなど一般的なメールソフトではSenderフィールドをサポートしていない。メーリングリストで発信する場合自動的にSenderフィールドにメーリングリストのオーナーのアドレスが付加される事がある。
Becky!ではサポートしている。
Yahooでは「you must use your Yahoo! BB mail address for the Sender/From field.」としている。 この / は and のようで、FromアドレスにYahoo以外のアドレスを記入すると送信出来なくなる。
Envelope-FromにはプロファイルのFromよりSenderが優先される。
Reply-To 送り主が返信先としてアドレスを指定したい場合に用いるフィールド。普通メールソフトは「返信」の機能を実行するとReply-Toを自動的に認識しアドレスを決めてくれる。Reply-Toが無い時にはFromに返信する。(返信先としてReply-To が Fromに優先する)

宛先に関するフィールド

To メールの宛先を指定するフィールド。宛先の指定は必須なのだが、Ccフィールドで宛先を指定するとToフィールドは省略できる。
ToフィールドのスタイルはFromフィールドと同様である。カンマで区切って複数の宛先を指定できる。
特殊な方法として次のスタイルでグループ名のあとに複数のアドレスを指定することも可能である。To:<グループ名>:<アドレス1>,<アドレス2>,・・・・; ただしOEではこの方法をサポートしていない。
受信したメールに対して「返信」を実行すると、受信メールのFromフィールドの内容がTOフィールドに適用される。
Cc スタイルはToフィールドと同様。Ccフィールドの場合、同じメールの送信先が全員にわかるので、送り忘れが全員でチェックできる。
Ccフィールドで宛先を指定する場合にはToフィールドは省略できる。
Bcc スタイルはToフィールドと同様。Bccフィールドで宛先を指定した場合、受け取った相手はほかの誰に同一のメールが送られているのか分からない。Bccフィールドを使う場合には、Toフィールドに最低一つのアドレスが指定されている必要がある。

内容説明などのフィールド

Subject

(必須)

メールの題名を指定するためのフィールド。本来は必須のフィールドではなく、メールソフトでタイトルを入力せずに送信することは可能だが、メールソフトはその場合でもSubjectフィールドを空欄で付加する。(その意味では必須扱い)
受信メールに返信しようとすると、メールソフトが元のタイトルにRe:をつけたものが自動的にタイトル欄に表示される。
転送メールには、元のタイトルにFw:又はFwd:が付けられるようになっている。
Date

必須

メールの送信日付を記録しておくフィールド。この場合の送信日付とは、メールソフトがサーバーにメールを送り出す瞬間を指す。
Dateフィールドのスタイルは次の通り
Date:<曜日>,<日><月><年><時刻><時差>
例] Date: Wed, 19 Feb 2003 22:38:30 +0900
時差は「協定世界時(UTC)」との時間差。GMTと異なっているのは、UTCでは、「うるう秒」が考慮されている点にある。 (年1回程度うるう秒修正が行われている)
時刻はメールソフトの内蔵時計を利用しているので、内蔵時計の期間を常に正確に補正しておく必要がある。

メールを識別するためのフィールド

Message-ID

(必須)

メールのユニーク性を保つためのID番号。(全世界で無数のメールがやり取りされているが,その中でたった一つしかないID番号)絶対に付けるようにと定められてはいないが、現在のシステムでは必須と考えてよい。ID番号はメールを送信したメールサーバーによって決められる。
基本的なスタイルは <任意の文字列>@<ドメイン名> 文字列は重複しないように各サーバーで独自に決める。ドメイン名はメールサーバーのものが使われる。
In-Reply-To そのメールがどのメールに対する返信であるかを示すためのフィールド。
このフィールドには元のメールのMessage-IDフィールドの内容が用いられる。
このIn-Reply-Toフィールドをサポートしているメールソフトでは、タイトルや差出人だけでなく、ID番号を用いた分類(スレッド表示など)が可能になる。
ただしOEではサポートされていない。MLなどでスレッド表示にしていると、返信の形で新規投稿されると、表示が乱れて困ることがある。(OE使用の人は注意して欲しいもの)
References 参照すべきメールを示すためのフィールド。本来は元のメールのMessage-IDフィールド、In-Reply-Toフィールド、Referencesフィールドを全て加えるため、やり取りをするにつれて長くなっていくはずだが、OEのようにIn-Reply-ToやReferecesフィールドをサポートしないメールソフトでは、In-Reply-Toと同様にもとのメールのMessage-IDだけが用いられる。

メールの送信経路を示すフィールド

Received

必須

そのメールがどのようなサーバーを経由して届けられたかを記録するフィールド。メールを受け取ったサーバーは、その時点でメールヘッダーの先頭にReceivedフィールドを書き加える。Receivedフィールドのスタイルは次の通り
Received:from<送信サーバー>by<受信サーバー>via<接続方式>with<転送方式>id<識別番号>for<宛先>;<受信日時>
部分的に省略されている場合もあり、特にviaは殆ど省略される。
Return-Path

必須

メッセージを受け手に届ける最終のサーバーがメールヘッダーの先頭部分に付加する。このフィールドは、メッセージの創作者まで戻れるアドレスとルートについての確定的な情報を含むよう意図されている。
即ち、メールがサーバー間でのみ使われるエンベロープと言われる情報からMail From<送信者アドレス>が使われる。Mail FromフィールドはFromフィールドの差出人のアドレスとは必ずしも一致しない。メールの送信が正常に行われないときには、Mail Fromアドレスにエラー通知が届けられる。したがって、ML の場合,エラーメールが差出人に届かないように,Return-Path を ML の管理人にする場合が多い。
"Reply-To"フィールドは創作者により付加され、ダイレクトな返信を導くのに役立つ。一方"Return-Path"フィールドは、創作者まで戻れるパスを識別するために使われる。
BECKY!の場合にEnvelope-Fromはプロファイルのメールアドレスを使っているので、EnvelopeのMail-From(即ちReturn-Path)を変えるには別のプロファイルを作る必要がある。
乃至はSenderアドレスを付加すればそちらが優先される
Return-Pathは必ず付けられているが、メールサーバーによってはヘッダー情報に付加せずに配信するものがある。

本文やMIMEデータに関するフィールド

Mime-Version メールの本文が対応している「MIME(Multipurpose Internet Mail Extensions)」のバージョン番号を示すフィールド。現在バージョンは1.0のみ。
本来MIMEは「US-ASCII」のみを扱うインターネットにおいて、それ以外の文字コードやバイナリデータを扱うための拡張仕様である。
Content-Type 本文の内容がどのようなスタイルで書かれているのかをあらわすフィールド。
日本語のテキストメールであれば
Content-Type: text/plain; charset=iso-2020-jp となっているはず。
charsetで指定されるのが本文で使われている文字コードである。
単なるテキストのほかに、次の形式がある。
Content-Type: text/html (HTMLテキスト形式)
Content-Type: text/enriched (エンリッチドテキスト形式)
テキスト形式のみで表示するメールソフトではHTMLテキスト形式のメールは正しく読めない。そこで、OEをはじめたいていのメールソフトはHTML形式で作成したメールでも通常のテキスト部分を付け加えて,どちらの形式でも読むことが出来るようにしている。
Content-Type: multipart/alternative; boundary="<区切り文字列>" 
「multipart」で内容が分かれていることを、「alternative」は読み方が選択可能であることを示している。「boundary」では、分かれた部分の区切り文字を指定している。
メールにファイルを添付して送った場合には
Content-Type: multipart/mixed; boundary="<区切り文字列>"
これも「multipart」によって内容が分かれており、「mixed」なので異なる内容が混ざっていることを示している。
Content-Transfer-Encoding エンコード方式を示すフィールド。 「エンコード」とは,データ形式(テキスト/バイナリなど)を変換することで、それを元に戻すことを「デコード」と言う。エンコードが省略されている場合「エンコードなしの7ビットテキスト」と言う意味で次のようになる。
Content-Transfer-Encoding:7bit
「8bit」(エンコードなしの8ビットテキスト)と言う指定もあるが、インターネットで扱うメールは7ビット情報が基本なので,正常に届く保証は無い。
7ビット以外の文字やバイナリーデータは7ビットのテキストデータにエンコードされて送信される。その変換方式に、base64、quoted-printable、uuencodeなどがある。例えば、base64でエンコードされているなら、次のようになる。
Content-Transfer-Encoding: base64

 

その他のフィールド
先頭に「X-」が付けられたものは拡張フィールドであることを示している。RFCに有るもの無いものがあり、さらにメールソフトが独自に付けるフィールドもあるので、同じフィールド名でも異なる使われ方もありうる。

X-Mailer そのメールを作成する際に使用したメールソフトの名前やバージョンを示す。
X-Priority 重要度を示す。1から5まで指定でき、1が最も重要度が高い。
Precedence 重要度を示す。「bulk」「first-class」「list」の3段階がある。
X−Accept-Language 受け付ける言語を示す。日本語ならja
Disposition-Notification 開封確認機能。「MDNs」(message disposition notifications)というインターネットの標準仕様に基づいており、対応するメーラー同士であれば開封したことを自動的に確認できる。
Lines 一部のメールソフトで本文の行数を示す。
Errors-To エラー通知の送り先を示す。本来はエンベロープのMAIL-FROMに送るべきものなので、一部のメールサーバーでしかサポートされない。