鳥さんの落書き帳

Resent-X:

リ・セント(再び送られる)フィールドと呼ばれています。
「あまり意味のないものに通信費用を使わせやがって」と相手を怒らせる為のフィールドです、という下らない冗談はさておいて。
このフィールドは再送メールには再送するごとに付け足すべきとされています。
滅多な事では使わないと思います。
Resent-Date:、Resent-From:、Resent-Sender:、Resent-To:、Resent-Cc:、Resent-Bcc:、Resent-Message-Id:があります。制約は同じです。
これは転送(自動・手動両方)ではないらしいです。
曰く、元のヘッダ(To:、From:など)はそのままで、これらのヘッダフィールドは再送された場所での情報をつけるそうです。

Date:

メールが完成した時間。送信した時間でも届いた時間でもない点に注意。
必須。

From:

メールを書いた本人。つまり文責者。送信者はSender:ヘッダフィールドに書きます。
送信者が文責者と同一の場合はSender:フィールドは書くべきではないとされています。
必須。

Sender:

送信者本人を指します。
From:に複数のメールアドレスがある場合に必須。
そうでない場合でも、送信者が文責者と違う場合は書くべき。

Reply-To:

返信先のメールアドレスを示します。普通はTo:宛に返信するので、このヘッダはあまり使われません。

To:

メールの主たる受取人を指します。

Cc:

「カーボン・コピー」のことで、主な受取人以外の受け取るべき人を列挙します。

Bcc:

「ブラインド・カーボン・コピー」のことで、受取人からは他の受取人は見えません。メール・マナー上、普通は多数の人にメールを送る時は、To:、Cc:ヘッダフィールドではなく、このヘッダフィールドに書きます。このヘッダに対するメーラの挙動は示されておらず、不安定なヘッダフィールドと言えそうです。

Message-ID:

そのメールの識別子です。このIDとIn-Reply-To:、References:ヘッダフィールドを元にメーラはメールのツリーを展開します。
あるべき。

In-Reply-To:

返信もとのメールIDを含みます。複数のメールに同時に返信する特殊なケースを除いて、通常はIDは一つということになります。
返信にはあるべき。

References:

返信元となっている全てのメールのIDを含みます。
返信にはあるべき。

Subject:

いわゆる「件名」です。
「Re:」は1回限り付与するべき。

Comments:

そのまんま、本文に対するコメントです。
コメントですから通常見えません。

Keywords:

カンマで区切られたキーワードの一覧です。
これがあると検索の時に有用ではないかと思いますが、どれほどのメーラが対応しているのでしょう…

Return-Path:

配信エラーの場合にここへエラーを送ってくだされ、というメールアドレスが書かれています。
ウィルスメールの場合、ここに本当の配信元が書かれていたりします(場合があるだけですから、本気にしないように)。

Received:

メールがメールサーバに到着するまでに通った経路が記録されています。これを元に送信元を探る事ができます。
from xxxx: 渡した側のメールサーバの名前です。
by xxxx: 受け取った側のメールサーバの名前です。
with xxxx: どのようなプロトコルで渡されたかが書かれています。
for xxxx: どこのメールアドレスに送るのかが書かれています。
id xxxx: メールサーバが勝手に付けるIDです。あまり気にする必要はありません。
via xxxx: その経由地点の環境とプロトコルが書かれています。
しかし、はじめからこのヘッダフィールドを幾つか付けて送信元を偽装しているケースもありますので、必ずしも送信元を特定できるわけではありません。一般的に、最後にある(一番上の)Receivedヘッダフィールドはほぼ確実とされています。

Content-Features:

MIMEの本体部分の特徴を示唆する為の注釈

List-ID:

メーリングリストを識別する為のヘッダフィールドです。そのまんま、メーリングリストのIDです。

Content-Disposition

内容の扱いを指定します。"inline"は本文と同列に、"attachment"は本文とは別に添付ファイルとして扱え、と言うことです。そのあと、filename=に続いているのが、ファイルの名前に当ります。

Content-Description:

中身の説明

Content-ID:

そのパートのID

Content-Type:

メールの中身はなんぞ、ということが書いてあります。
text/plain: 普通のテキストだよ、と書いてあります。開いても害はありません。「charset=」以降で、文字セットはこれだよん、と言っています。普通はISO-2022-JPです。
multipart/xxxx(例えばmixed): 色々混じってるよん、と書いてます。「boundary=」ってのは、これを区切りで使ってまっせ、という意味です。この場合、更に個々のファイルにContent-Type:が付いてます。
image/xxxx(例えばjpeg): 画像です。画像ファイル経由のウィルスというのは希のようですので、比較的安心して開けます。
text/html: HTML ファイルでっせ、と言っています。HTMLファイル経由のウィルスは最近珍しくありませんので、開く前に、ちょっと待った!　1度、普通のテキストファイルとして開いてみましょう。怪しそうなスクリプトはないかどうか、分からなければ開かずによく知っている知人などに聞いてみましょう。もしメールを貰った相手が信用できる人なら、その人に聞いてみるのも良いかもしれません。相手も知らないようなら、即ゴミ箱へ送りましょう(念の為に、完全に削除した方が良いかもしれません)。
message/partial: 分割して送ったよ、という意味です。「total=」幾つのうち、「number=」幾つ目です。
後は、video/xxxx(動画+音声)、application/xxxx(アプリケーション。ウィルスが潜り込む可能性があります)とmessage/xxxx(テキストエディタで開けられますが、デフォルトでは対応してない)。
他にもmodel/xxxxというのがありますが、あまり用いられていません。これはRFC2077にあります。

Content-Transfer-Encoding:

どのようにエンコードしたか。
"7bit"(メール本文などのテキスト)、"quoted-printable"(バイナリファイルのエンコード方式の一種)、"base64"(標準のバイナリファイルのエンコード方式。いわゆる「Bin-Hex」もこの表記になるようです)。
後は"8bit"、"binary"がありますが、これらの値が現れた場合は、そのメールはかなり危ないメールです。

MIME-Version:

どのバージョンのMIMEに対応しているか。
普通は「1.0」です。

Disposition-Notification-Options:

将来の開封通知メール拡張の為の予約です。書き方だけが定義されています。

Disposition-Notification-To:

OutlookExpress5.5以降で言う、「開封確認通知」を出すメールアドレスです。開封確認通知メールはFrom:にあるメールアドレスではなくこちらに送られますので、もしかしたら知らない誰かにメールが行ってしまうかもしれません。注意が必要です。

Original-Recipient:

SMTPの"RCPT TO"コマンドのORCPTパラメータがあった場合に、それをReturn-Path:ヘッダフィールドの次に挿入するのだそうです。
あれば、仮にDisposition-Notification-To:を偽装された場合に役に立つかもしれません。そんなドジを踏む可能性は低いでしょうが(^^;

で、送信されるレポートの内容部分にも決まりがあったりなんかします。それについては、RFC2298にあるボディフィールドの説明をどうぞ。

Encoding:

どんな方法でエンコードされているかが記述されています。

このRFCでは、一般向けではないとされているヘッダフィールドが定義されています。
X.400という規格をRFC822(メールの規格。これはRFC2822によって廃棄されています)規格上で扱う為のものとされています。
しかし一般に有用なものも含まれ、使用されているものも幾つか存在します。

Alternate-Recipient:

仮に送信相手に届けられない場合に、例えばポストマスターのような違うところに転送させるかどうかを制御します。
値は"Prohibited"(禁止)若しくは"Allowed"(許可)。

Autoforwarded:

自動転送されたか否か。
値は"TRUE"若しくは"FALSE"。

Autosubmitted:

そのメールが明確に人の手によって送信されたかどうか。
値は"not-auto-submitted"(手動で送信されました)、"auto-generated"(メールは自動生成されました)、"auto- replied"(自動で応答されています)、"auto-forwarded"(自動転送されました)です。どうも他に"auto- submitted"等の値があるようです(期限切れの草案にありました)。
参考にしたのはRe: bin/5039: change to vacation to support wider variety of mailers。(何せ13件しか掛からない(^^;)

Content-Language:

言語情報。英語なら"en"、日本語なら"ja"といった具合。

Conversion:

他の文字セットへの変換(例えばiso-2022-jp→EUC-jp)の許可、不許可。
値は"Prohibited"(禁止)若しくは"Allowed"(許可)。

Conversion-With-Loss:

情報が失われる可能性がある場合の他の文字セットへの変換(例えばiso-2022-jp→EUC-jp)の許可、不許可。
値は"Prohibited"(禁止)若しくは"Allowed"(許可)。

Disclose-Recipients:

メールの受け取り相手に、他の受け取り相手の名前(多分メールアドレス)を開示するか否か。
値は"Prohibited"(禁止)若しくは"Allowed"(許可)。

Expires:

そのメールの内容の期限。Usenetではデフォルトの期限が設定されており、投稿者は投稿メッセージの内容の保存期間を変更したい場合は、このヘッダフィールドを使用する必要がありました。
また、重要なメールを長期間補完する事を期待する場合にも使用されます。

Deferred-Delivery:

最初のメールサーバに渡った時刻

Delivery-Date:

そのメールが相手に到着した時刻

Discarded-X400-IPMS-Extensions:

X.400-IPMS拡張ヘッダフィールドが認識されず削除される場合、且つサーバが拡張ヘッダフィールドである事を認識して処理を行えるなら、その消した拡張ヘッダフィールドをここに書き込みます。

Discarded-X400-MTS-Extensions:

X.400拡張ヘッダフィールドがメールの送信に支障をきたす場合、且つそれが当該ヘッダフィールドである事を認識して処理を行えるなら、その消した拡張ヘッダフィールドをここに書き込みます。

DL-Expansion-History:

配送リストの拡張があった場合、その履歴がここに貯められます。

Generate-Delivery-Report:

メールの配送に成功した場合に、配送された旨のメールを返すか否か。
値は空です。このヘッダフィールドがない場合は、通知されません。あれば、通知されます。

Importance:

重要度を示します。緊急性を示すものではありません。緊急性は「Priority:」で指定します。"low"が低、"normal"が普通、"high"が高となります。
しかし、各メーラ、独自の重要度を示すヘッダフィールドを使用しており、まったくと言って良いほど統率も整合性もとれていないのが現状です。

Incomplete-Copy:

本文が一部欠けていることを意味します。
このヘッダフィールドの値は空です。

Latest-Delivery-Time:

最も最近メールサーバ間で受け渡しが行なわれた時刻

Message-Type:

"Delivery Report"(配達通知。MIMEで既に設定されており、この値の指定は冗長さを招くが、RFC1327との後方互換性の為に残されています)、"InterPersonal Notification"(X.400のIPN)、"Multiple Part"(MIMEで既に設定されており(multipart/xxxx)、この値の指定は冗長さを招くが、RFC1327との後方互換性の為に残されています)

Original-Encoded-Information-Types:

メールの本体がどのような形式で書かれているか。"Encode"とありますが、文字セットのことではありません。例えば、"G3-Fax"とか"Voice"とか、そういったものです。

Originator-Return-Address:

メールが生じた場所のメールアドレス。ですから、通常は「From:」と同じはずです。

Prevent-NonDelivery-Report:

メールの配送に失敗した場合に、配送されなかった旨のメールを返すか否か。値は空です。このヘッダフィールドがある場合は、配送エラーは通知されません。なければ、通知されます。

Priority:

急を要するか否か。重要性を示すものではありません。重要度は「Importance:」で指定します。"urgent"が急ぐ用事、"normal"が標準、"non-urgent"が遅くても良いとなります。
これによってメールサーバは転送順を変更します。
が、今は非標準ヘッダフィールド「Precedence:」の天下です。こっちに対応しなかった「sendmail」に非があるのだとは思いますが。

Reply-By:

この時間までに返信してくれよー、という時刻を記述します。勿論、強制力は持ちません。

Sensitivity:

メールの内容を他の人に公開する場合に、どの程度の慎重さを必要とするか。"Personal"(私信)、"Private"(親展)、"Company- Confidential"(社外秘)という値がありますが、厳密な違いについては不明です。このヘッダフィールドがない場合にのみ、フリーで公開できます。(但し、勿論常識の範囲で!)

Supersedes:

そこに書かれているメールの内容を改めたものである事を示します。しかし、その古い版を削除するものではありません。

X400-Content-Identifier:

メールの中身を識別する為の文字列。
旧「Content-Identifier:」ですが、MIMEの定義したヘッダフィールド(多分「Content-ID:」)と紛らわしいので、このように変更されました。

X400-Content-Return:

配達エラー通知にもとのメールの内容を含むか否か。
値は"Prohibited"(禁止)若しくは"Allowed"(許可)。

X400-Content-Type:

値は"P2"。後方互換性の為だけに残されています。
後ろに「1988」等コメントが付いているところを見ると、X.400のバージョン情報ではないかと思います。

X400-MTS-Identifier:

「Message-ID:」と似たものです。
ある場合を除いて、付けないようにと言うことになっています。

X400-Originator:

メールの発生元を示します。ですから通常「From:」と一緒です。

X400-Received:

「Received:」のもっと詳しい版のようです。どのようなやり取りが成されたかまで残されています。

X400-Recipients:

元のメールが自動転送された場合や、複数の相手に向けてメールを送り出した場合にそのメールの真の送信すべき相手のようです(複数の相手に出した場合は、その数だけメールが生成されます)。

Wanted-X400-Conversion:

メールの内容を変換する必要が生じた際に、どのように変換されたかが記述されます。

List-Archive:

そのメーリングリストの過去ログ

List-Help:

そのメーリングリストのヘルプのある場所

List-Owner:

そのメーリングリストのオーナー

List-Post:

そのメーリングリストの投稿先

List-Subscribe:

そのメーリングリストに参加するための場所

List-Unsubscribe:

そのメーリングリストから退会するための場所

Deliver-By-Date:

その時間までに配送できなかったら配送しません。

Content-Alternative::

そのメッセージの入手可能な他のフォーマット

Media-Accept-Features::

そのほかのフォーマットの細かな仕様

Content-MD5:

内容が改変されたかどうかのチェックサム。
メーラが勝手に処理するらしいので、人間は意識する必要ナッスィング。

Illegal-Field:

滅茶苦茶な書き方のヘッダフィールドがあり、それを認識できなかった場合に、それらをすべてこのフィールドの値とします。

Illegal-Object:

変な値を持つヘッダフィールドがある場合、そのヘッダフィールド名とどのような変な値だったか

PICS-Label:

メールのフィルタリング用の格付け