Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
ヘッダフィールド一覧 - インターネットメールの注意点

[付録] ヘッダフィールド一覧

ここでは、ヘッダ中のそれぞれのフィールドについて説明します。
ヘッダ全体の扱い方については、[8]をみてください。

それぞれのフィールドは色々なRFCで定義されているので、それを基に説明します。最初から定義のないものについては私の経験と想像で説明してるだけなので、他の意味で使われているケースも考えられます。

もともと基本的なフィールドはRFC822で定義され。これに載っていないものは拡張フィールド (extension-field)という事になっていました。頭に「X-」を付けるとユーザ定義フィールド (user-defined-field)として自由に使う事が出来ました。
しかし実際にはどこにも定義がないのに「X-」をつけずに使われる非標準フィールドが沢山登場しました。

現在のRFC2822には拡張フィールドもユーザ定義フィールドもありません。載っていないものは単にオプショナルフィールド (optional-field)であり、特に解釈しないとされます。

Content-で始まるフィールドは、MIMEで拡張されたものであり、様々なRFCで定義されています。(Content-Typeフィールドだけ例外あり)

あと、様々なフィールドの一覧がRFC2076にあり、どのRFCで定義されてるかも載っています。もともと定義のないフィールドも非標準ながら説明があります。

差出人のフィールド

`From:` `taro@example.com`

メールを書いた人のアドレスです。
RFC2822で定義されています。

このフィールドは必ず付けなければならないので、一度設定しておけば自動的に付けてくれるマシンやソフトが多いようです。間違えないように十分に確認してください。管理者が設定してくれるところでは、ユーザは何もしなくてもよい場合もあります。

通常は一つのアドレスを書きますが、みんなで書いた共著の場合はカンマで区切って複数のアドレスを書くことが出来ます。この場合、Senderフィールドで実際に送信した1人のアドレスを示さなければなりません。

万が一このフィールドが無い場合、エンベロープのMAIL FROM:の情報を使って、From:を作り出すメールサーバもありますが、これは本来は正しい動作ではありません。

`Sender:` `hanako@example.net`

送った人のアドレスです。
RFC2822で定義されています。

From:と同じ場合は省略すべきとされます。
書いた人と送った人が違うときに使われます。例えば、

From:に社長のアドレスを示し、Sender:に代理で送信した秘書のアドレスを示す
From:に共著した全員のアドレスを示し、Sender:に実際に送信したメンバー1人のアドレスを示す

等です。

ユーザが勝手にFrom:を書き換えたとき、管理者が設定した本来のアドレスをSender:に付けるソフトも実在します。
MSAと呼ばれるサーバは、From:に異常を発見したとき、正しいメールアドレスをSender:に付ける事になっています。この動作についてはRFC2476に載っています。

`Reply-To:` `yamada@example.org`

返信先です。
RFC2822で定義されています。

From:とは別のアドレスに返信して欲しいとき、ここに書きます。送信側で指定します。
また、メーリングリストの中には、自動でメーリングリストのアドレスをここに付けるものがあります。このような場合、問題が出ることがあるのでメーリングリスト管理者に聞いてみてね。

In-Reply-To:とは別物です。

宛先のフィールド

`To:` `ichiro@example.net`

送り先のメールアドレスです。
RFC2822で定義されています。

送信者が指定します。
複数のアドレス宛に送る場合は、カンマ「,」で区切ります。古い方法ではToフィールド自体を沢山付ける事も出来たので、もしそういうメールを受け取った場合もちゃんと処理しなければなりません。マシンやソフトによっては別な区切り方をするかも知れませんが、送信時に正しい形式に変換している筈です。

`Cc:` `jiro@example.net,` `saburo@example.org`

コピーの送り先です。
RFC2822で定義されています。

送信者が指定します。
To:フィールドで送ったものと同じメールが届きます。メール自体はTo:宛だが、一応読んでおいて欲しい人に使うのですね。To:と同様、複数のアドレスが指定出来ます。このフィールドが使えずTo:だけというソフトもあります。

`Bcc:` `shiro@example.com,` `goro@example.net`

RFC2822で定義されています。

ToやCcフィールドに複数のアドレスを書くと、ヘッダに情報が残るので、受信者は「ははーん、誰々が受け取ったな」ということが判ります。Bccフィールドに書いたアドレスはヘッダから消えるので、誰々が受け取ったのか判らないように出来ます。「お知らせメール」などで、互いに関係のない方々に送るときに便利かもしれません。
このとき、Toフィールドを空欄にしたり、To: (My Friends)の様に括弧でコメントの文字を書くだけの人がいますが、この使い方は間違いです。To:には1つ以上のアドレスを書かなければなりません。
そうでないと隠したはずのBcc:のアドレスが見えてしまうことがあります。To:には取り敢えず自分のアドレスを書くのが、常套手段かもしれません。
でも、受け取った人は自分のアドレスがヘッダにないので、不審に思うかもしれません。本文中で「XXXの皆様へ。これはbccのメールです」と書いておくと、安心だと思います。

情報提供のフィールド

`Subject:` `ashita no kaigi yotei`

メールの主題や要旨といったものを書くフィールドです。
RFC2822で定義されています。

付けなくても良いヘッダですが、ネチケットガイドライン (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:の情報を使ってメール一覧を並べ変えて見やすくするものもあります。

`Comments:` `renraku okurete sumimasen.`

本文に対するちょっとした付け加えのコメントを書くフィールドです。
RFC2822で定義されています。

実際は、あまり使われてません。

`Keywords:` `aka, ao, kiiro`

受信者にとって便利なように、キーワードを書くフィールドです。
RFC2822で定義されています。

カンマ「,」で区切って複数のキーワードが書けます。
実際は、あまり使われてません。

日時のフィールド

`Date:` `Fri, 04 May 2001 01:02:00 +0300`

メールを送信した時間です。例えば、「送信」ボタンを押す瞬間です。
RFC2822で定義されています。

必須のフィールドなので、サーバに渡すときにメールソフトが付けなければいけません。

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と呼ばれるサーバは、認証を行なってから付けてもよい事になっています。この動作についてはRFC2476に載っています。

メールを区別する為のフィールド

`Message-Id:` `<0123456789.AA12345@example.com>`

メールを1通1通区別するための文字列です。
RFC2822で定義されています。

インターネットは世界レベルですから、世界で唯一のMessage-Id:でなければいけませんが、これが守られていないケースは非常に多いです。
偶然に同じMessage-Id:が付いたメールが届いた場合、区別が出来なくなって配送されなかったり、読めなくなる可能性があります

このフィールドは付けなくても間違いではありませんが、付けるべきだとされています。ないときにサーバが代わりに付けることもありますが、これは本来は正しい動作ではありません。ただし、MSAと呼ばれるサーバは、認証を行なってから付けてもよい事になっています。この動作についてはRFC2476に載っています。

`In-Reply-To:` `<123443210.BB12345@example.net>`

どのメールへの返信かを表します。
RFC2822で定義されています。

返信するときに、元のメールの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>`

参照って意味ですね。
RFC2822で定義されています。

返信するときに、元のメールのReferences:とIn-Reply-To:とMessage-Id:の中身を全部つけます。
だから、何度もメールをやり取りするとどんどん増えていきます。

元々このフィールドは、以前届いたメールの日付とか名前とかメールアドレス等、色んなフレーズを書いて良かったのです。しかし、2001年4月に決まりが変わって、References:とIn-Reply-To:とMessage-Id:の中身だけを書くことになりました。

この情報を使ってメール一覧を並べ変えて見やすくするものもあります。

転送の足跡を示すフィールド

`Received:` `from` `smtpserver.example.com` `by` `mailgw.example.net` `via` `TCP` `with` `SMTP` `id` `EAA09615` `for` `<ichiro@example.net>` `;` `Fri, 24 Aug 2001 05:51:00 +0900`

メールを受け取ったサーバが付ける情報です。
ヘッダの一番上に付ける事になってます。だから、何台も経由した場合、下から上にReceived:フィールドがどんどん増えていきます。

RFC2822では、様々な転送方法を想定してか、「;」の後に日時を書くことだけが決まっています。その前に何を書くかは、細かくは決まっていません。
ただし、SMTP/ESMTPで受け取った場合はRFC2821の決まりで次のような書き方になります。

fromのドメインからbyのドメインがviaの接続方法を使ってwithの転送方法で受け取り、そのときの区別する番号がidで、forのアドレス宛です。「;」以降は受け取った日時です。
このとき必須になるのは、「from」、「by」、「;日時」の3つです。

ここの日時を調べると、遅れて届いたメールがどこで停滞していたかわかるかも。

`Return-Path:` `suzuki@example.net`

一番最後にメールを受け取ったSMTP/ESMTPサーバが、Received:フィールドの更に上に付けます。送信側で付けるものではありません。
エンベロープのMAIL FROM:の内容を一番最後のサーバがReturn-Path:に書き写すのです。ただし、必須フィールドではないので付けないサーバもあります。
一応、RFC2822で定義されていますが、細かい事はRFC2821で定義されています。

MIME関係のフィールド

`Mime-Version:` `1.0`

メールの本文がMIMEの決まりに沿っていることを示します。
本文だけを表している事に注意してください。ヘッダの方は、「=? 文字コード ? 変換方式 ? 内容 ?=」とか「パラメータ名*=」という形を取ることで、自分自身でMIME対応を表しています。
MIMEの決まりに従ったマシンやソフトは自動で付ける筈です。

RFC2045で定義されており、今のところバージョン1.0しかありません。

`Content-Type:` `xxxx`

これはMIME登場以前のRFC1049で定義されたフィールドです。
だから、この形式のフィールドが付いている場合は、Mime-Version:フィールドは付いていない筈です。

メールの本文が普通のテキストではなく、何か書き方の決まった方式を使っている事を示します。
xxxxの部分は、POSTSCRIPT、SCRIBE、SGML、TEX、TROFF、DVIといった文字が入ります。textとかgeneric-textという文字を入れるソフトが現存するのですが、これはRFC1049には載っていません。

`Content-Type:` `xxxx/xxxx`

Content-Type:以下が、xxxx/xxxxのようにスラッシュで区切られているものは、MIMEで拡張されたフィールドであり、RFC2045で定義されています。
この形式のフィールドが付いている場合は、Mime-Version:フィールドも付いている筈です。

本文やMIMEによって分割した部分の形式を示します。

`Content-Type:` `text/plain;` `charset=iso-2022-jp`

text/plainとは「ただのテキスト」ですね。
charset=というパラメータは、本文の文字コードを表しています。charset=が書いてない場合はUS-ASCIIです。
もともと日本国内のネットワークでは、本文中のエスケープシーケンスを見て「日本語だな」という事を判断していました。
しかし、世界中が繋がった現在のインターネットでは、このエスケープシーケンスで判断するルールは定着していません。ISO-8859-1等の文字コードはエスケープシーケンスを使ってないので、何の文字コードなのか判別出来ないのです。そこで考えられたのがcharsetパラメータなわけです。

このcharsetパラメータがないとISO-2022-JPであることに気付かず文字化けするものも実在します。特に日本国外製ソフト。

`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.2.3]を見てください。

`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`

どんな方法でエンコードされたか書かれています。
RFC2045で定義されており、これによると、 7bit, 8bit, binary, quoted-printable, base64等があります。

7bitはエンコードなしの7ビットのテキストです。
8bitはエンコードなしの8ビットのテキストです。ちゃんと届く保証はありません。
binaryはバイナリです。ちゃんと届く保証はありません。
quoted-printableはlatin1 (ISO-8859-1)等のテキストをASCIIに変換して送るときに使います。
base64はバイナリをASCIIに変換して送るときに使います。

このフィールドがない場合は7bitとして扱われます。
RFC1468によれば、ISO-2022-JPは最初から7bitなので、このフィールドは必要ありませんが、もし付けるならば7bitが正しい事になります。

なお、uuencodeとかx-uuencodeという文字列を付けるソフトがありますがこれは非標準です。そもそもuuencodeは敢えてMIMEから外したという経緯があります。

`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=はデータのサイズ(オクテット単位)です。

RFC2183で定義されています。filename=パラメータに日本語ファイル名を使う場合は、RFC2231に従う必要があります。

ソフト名を示すフィールド

`X-Mailer:` `Super Mail Ver 1.2`

非標準フィールドですが、RFC2076に情報があります。
どうやら、送信側のメールソフトがソフト名とかバージョン番号を付けているように思われます。サーバがこのフィールドを付けているケースもあり、その場合はサーバ側のソフト名とバージョン番号になっているようです。

`User-Agent:` `Super Mail Ver 1.2`

非標準フィールドです。
どうやら、送信側のメールソフトがソフト名とかバージョン番号を付けているように思われます。X-Mailerフィールドと同様な使われ方でしょうか。
なお、RFC2616ではWebブラウザがHTTPサーバに自分のソフト名やバージョン等の情報を知らせるときにUser-Agent:フィールドを使うことになってますが、これはWebの話でありメールとは何の関係もありません。

その他

`Return-Receipt-To:` `taro@example.com`

非標準フィールドですが、RFC2076に情報があります。
一部のメールサーバは、ちゃんと配送出来たかどうか、開封されたかどうかを知らせるメールをここに書いてあるアドレスに送ります。
しかし、このフィールドは非標準なので最近のメールサーバはサポートしません。これについては、[12.4.6]も読んでください。

`Disposition-Notification-To:` `taro@example.com`

MDNという方式の開封通知を要求するフィールドです。このフィールドを付けて送信すると、受け取った側のMDN対応メールソフトは「開封しました」という通知をここに書いてあるアドレスに送ります。
ただし、これに対応してないソフトは何も通知しません。対応してるソフトでも「通知を送りますか？(Yes/No)」という事を確認してくるものも多いです。人間に確認もせず勝手に通知すべきではないとされるからです。悪意のある相手に勝手に通知されたりしたら困るわけです。
これについては、[12.4.6]も読んでください。

RFC2298で定義されています。

`Errors-To:` `taro@example.com`

非標準フィールドですが、RFC2076に情報があります。
一部のメールサーバは、配送に失敗した場合、エラー通知をここに書いてあるアドレスに送ります。
しかし、このフィールドは非標準なので最近のメールサーバはサポートしません。エラー通知はエンベロープのMAIL FROM:に送るのが正しい動作だからです。ただし、SMTPではない独自形式のネットワークに転送されたとき、エンベロープの情報が失われる事があるので、代わりにこのフィールドの情報を使う場合があります。
これについては、[12.4.6]も読んでください。

インターネットメールの注意点 - [参考] ヘッダフィールド一覧