ここでは、ヘッダ中のそれぞれのフィールドについて説明します。
ヘッダ全体の扱い方については、[8]をみてください。
それぞれのフィールドは色々なRFCで定義されているので、それを基に説明します。最初から定義のないものについては私の経験と想像で説明してるだけなので、他の意味で使われているケースも考えられます。
もともと基本的なフィールドはRFC822で定義され。これに載っていないものは拡張フィールド (extension-field)という事になっていました。頭に「X-」を付けるとユーザ定義フィールド (user-defined-field)として自由に使う事が出来ました。
しかし実際にはどこにも定義がないのに「X-」をつけずに使われる非標準フィールドが沢山登場しました。
現在のRFC2822には拡張フィールドもユーザ定義フィールドもありません。載っていないものは単にオプショナルフィールド (optional-field)であり、特に解釈しないとされます。
Content-で始まるフィールドは、MIMEで拡張されたものであり、様々なRFCで定義されています。(Content-Type:フィールドだけ例外あり)
あと、様々なフィールドの一覧がRFC2076にあり、どのRFCで定義されてるかも載っています。もともと定義のないフィールドも非標準ながら説明があります。
これらはRFC2822で定義されています。
From:はメールを書いた人のアドレスで、Sender:は送った人のアドレスです。
大抵、これらは一度設定しておけば、送信メールに自動的に付けてくれるでしょう。また、管理者が設定してくれるのでユーザは何もしなくてよい場合もあります。
普通はFrom:とSender:が同じなので、Sender:の方を省略すべきとされます。Sender:を付けるのは、次のような場合です。
From:に社長、Sender:に秘書のアドレスを書くべきだ。From:に共著した人のアドレスをカンマ「,」で区切って書き、必ずSender:を付けて送信した人のアドレスを1つだけ書かねばならない。
From:は必須のフィールドですが、万が一無い場合、エンベロープのMAIL FROM:の情報を使って、From:を作り出すメールサーバもあります。これは本来は正しい動作ではありません。
また、ユーザが勝手にFrom:を書き換えたとき、管理者が設定した本来のアドレスをSender:に付けるソフトも実在します。
MSAと呼ばれるサーバは、From:に異常を発見したとき、正しいメールアドレスをSender:に付ける事になっているのです。この動作についてはRFC2476に載っています。
Reply-To: yamada@example.org
RFC2822で定義されています。
Reply-To:は返信先のアドレスであり、From:とは別のアドレスに返信して欲しいときに使います。
Reply-To:は送信者が自分で付けるのが普通の使い方ですが、メーリングリストの中には、自動でメーリングリスト用のアドレスをここに付けるものがあります。このような場合、問題が出ることがあるのでメーリングリスト管理者に聞いてみてね。
なお、Reply-To:とIn-Reply-To:とは別物です。
From hanako@example.net Wed May 7 02:28:53 2003
「From」の直後に「:」が付いていない事に注目してください。これは本当はヘッダフィールドではありません。ヘッダにこれが付いていたとしたら、非標準という事になります。標準のFrom:フィールドと区別するために、UNIX Fromなどと呼びます。
UNIXでは、届いたメールをひとつのファイルにまとめて保存しておく形式があります。非常に古くからあるファイル形式で、mailboxとかmboxと呼ばれています。
この形式では、それぞれのメールの区切りとしてヘッダの上にこの「From 」ではじまる行を付けます。ここに付いているメールアドレスはエンベロープのMAIL FROM:の内容です。次に付いてる日時は、受信した日時です。Date:フィールドとかで使っている日時の表記法とは違います。
メールサーバがUNIXで動いている場合、この形式でメールを保管しているかもしれません。メールソフトに取り込む前に、サーバはこの行を消す筈です。Return-Path:フィールドにここのアドレスを書き写す場合もあります。
しかし、この行を残したままにしておくサーバも実在します。また、
>From hanako@example.net Wed May 7 02:28:53 2003
という風に、頭に「>」を付けるサーバもあります。どちらにしろ非標準です。
あと、UUCPでメールを転送する場合も、このUNIX Fromの行を使います。
Unix Fromに関しては、RFC976やRFC2076に情報があります。
これら3つはRFC2822で定義されています。
To:は送り先です。
Cc:はコピー(Carbon Copy)の送り先です。メール自体はTo:宛だが、一応読んでおいて欲しい人に使うのですね。
Bcc:はちょっと複雑なので、後で説明します。
3つとも宛先のアドレスを示すものであり、使い方が違うだけで配送は同じように行なわれるはずです。
なお、簡易的なソフトだとCc:やBcc:が使えないものもあるので注意しましょう。
複数のアドレス宛に送る場合は、カンマ「,」で区切ります。マシンやソフトによっては別な区切り方をするかも知れませんが、送信時に正しい形式に変換している筈です。
古い方法では次のようにフィールド自体を沢山付ける事も出来ました。もしそういうメールを受信した場合もソフトはちゃんと処理しなければなりません。
To: hanako@example.net
To: taro@example.net
Cc: ichiro@example.net
Cc: jiro@example.org
Bcc: saburo@example.com
Bcc: shiro@example.net
To:とCc:はヘッダに残るので、受取人は自分以外に誰が受け取ったか確認出来ます。
Bcc:もコピー(Blind Carbon Copy)の送り先ですが、ここに書いたアドレスはヘッダから消え去るので、受取人は誰が受け取ったかわかりません。上の例だとsaburo@example.comとshiro@example.netがヘッダから消えているはずです。「お知らせメール」などで、互いに関係のない方々に送るときに便利かもしれません。ただし、使い方が悪いと隠した筈のアドレスがバレバレになるので要注意です。予防のために、Bcc:を使う場合に限って、次のようにする事をお勧めします。
To:を付けて、見えてもよいアドレス(例えば自分のアドレス)を入れておく。Bcc:に入れる。(To:やCc:には入れない。)
理由は複雑ですが、大雑把に書くと、次のようになります。
そもそも最初にBcc:の使い方を決めた文書(RFC822)の書き方が曖昧だったので、動作の違うソフトが沢山出てきました。新しい文書(RFC2822)には、3つのタイプがあると書かれています。
Bcc:行をまるごと消してからまとめて送信する (配送自体はBcc:宛にも送られるので大丈夫)To:やCc:の人にはBcc:行をまるごと消してまとめて送信し、Bcc:の人には個別に送信するBcc:というフィールドだけは残し、その中身のアドレスだけを全部消してから送信する (配送自体はBcc:宛にも送られるので大丈夫)
なお、私が調べたところ、稀にBcc:を全部付けっぱなしにして送信してしまうソフトもあります。これはメールサーバが消してくれるだろうという考えでしょう。しかし、メールサーバにそんな義務はありませんから、そのまんま届いてしまう可能性があります。十分に送信実験してください。
あと、一部の古いメールサーバは、To:もCc:もBcc:も全くないメールを受け取った時に、Apparently-To:という非標準のフィールドを付けて、エンベロープのRCPT TO:の中身を見せてしまうものがあります。Bcc:だけの場合、これが消されて結局宛先フィールドがなくなってしまう可能性があるわけです。ほんの一部のソフトはRFC934という文書に従ってBcc:宛だけは特別の書式(カプセル化)にして送ります。このときにも宛先フィールドが全部消えてしまう事があります。これを防ぐために必ずTo:を付けて見えてもよいアドレスを入れると良いと思います。
それから、Bcc:で受け取った人が何も考えずに返信したときの事を考えて下さい。To:やCc:に書かれているアドレス全部に返信するかもしれません。すると、それらの人に「あ、こいつも受け取ってたのか」という事がバレバレです。これを防ぐためにTo:には自分のアドレスだけを入れておくとよいと思います。
このとき、To:フィールドを空欄にしたり、To: (My Friends)の様に括弧でコメントの文字を書くだけの人がいますが、この使い方は間違いです。To:には1つ以上のアドレスを書かなければなりません。
そうでないと隠したはずのBcc:のアドレスが見えてしまうことがあります。To:には取り敢えず自分のアドレスを書くのが、常套手段かもしれません。
でも、受け取った人は自分のアドレスがヘッダにないので、不審に思うかもしれません。本文中で「XXXの皆様へ。これはbccのメールです」と書いておくと、安心だと思います。
この3つのフィールドは、RFC2822で定義されています。
メールに情報を付け加えるもので、人が読む事だけを目的としています(機械が処理に使うものではない)。
Subject:は、メールの主題や要旨といったものを書くフィールドです。
Comments:は、本文に対するちょっとした付け加えのコメントを書くフィールドです。
Keywords:は、受信者にとって便利なようにキーワードを書くフィールドであり、カンマ「,」で区切って複数書けます。
実際は、Comments:とKeywords:はあまり使われていません。Subject:はどのソフトもまず間違いなくサポートしているでしょう。
3つともオプション扱いなので付けなくても良いのですが、Subject:に関してはネチケットガイドライン (RFC1855)で内容を反映したSubject:を付けるべきだ
とされています。
ここで、「内容を反映した」というのが重要です。例えば、「Subject: 教えてください」よりは「Subject: 問題3の解き方を教えてください」の方がわかりやすいでしょう。「教えて下さい」だけでは、何を教えて欲しいのかわかりません。
なお、返信のときには元のメールのSubject:に「Re: 」をつけるという習慣が古くからあります。
自動で付けてくれるソフトが多いです。
例えば、「Subject: Re: 問題3の解き方を教えてください」という感じですね。「Re:」の直後にスペースが一つ入っている事に注意しましょう。
ところで、この「Re: 」の習慣については、メール関連のRFCには長らく記載がありませんでした(ニュース関連のRFC1036には説明がありますが、誤植があるので注意)。
ずっと後に公開されたRFC2822に、初めて次のような説明が付きました。
Subject:の内容の頭に「Re: 」を付けてもよい。Re: 」は一つだけ付けるべきだ。沢山付けたり別の文字列を付けると好ましくない結果になるからだ。
たまに、「Re:」の直後にスペースを付けてないソフトがあります。
「RE: 」という大文字を付けるソフトもあります。
「Re: Re:」のように重なっていく場合もあります。これはASCIIのSubject:では問題ないのに、日本語のSubject:のときに発生する場合があります。だとすると原因は"B" encodingの仕組みが難しいからです。
何度もやり取りしたとき、Re^2:だとかRe[2]:という風に数字を付けるものもありますが、3人以上でやり取りするとこの数字が意味をなさなくなるのは明らかです。
日本語用メールソフトで「返信：」、イタリア語用メールソフトで「Rif: 」、ドイツ語用メールソフトで「AW: 」を付けるものもあります。
また、一部のメーリングリストでは、メールの通し番号をSubject:に付けます。
Subject: [idobata-ML: 0135] 問題3の解き方を教えてください
という感じです。
こういったバラバラの付け方があるので、やり取りを何度も繰り返すと、
Subject: RE:Re^2 [idobata-ML: 0135] Re: 問題3の解き方を教えてください
のようになってしまうかもしれません。
メールソフトによっては、Subject:の内容を使ってメール一覧を並べ変えて見やすくします。しかし、「Re: 」の使われ方がバラバラだとうまく並ばないかもしれません。
返信する前には、Subject:をチェックするとよいでしょう。
Date: Sun, 02 Nov 2003 06:07:00 +0800
RFC2822で定義されています。
メールを送信した時間を表しています。例えば、「送信」ボタンを押す瞬間です。
必須のフィールドなので、サーバに渡すときにメールソフトが付けなければいけません。
2000年問題に対応するため、西暦は4桁以上で書かないとだめになりました。ただし、かつては2桁も認められていたので、00年とか01年とかを受け取った場合はちゃんと2000年、2001年という風に換算しなければなりません。
曜日と秒は省略出来るし、日にちは1桁でも良いので、
Date: 2 Nov 2003 06:07 +0800
と書いてもオッケーです。
+0300という数字は時間帯(time zone)であり、協定世界時(UTC)との時差です。
UTCはグリニッジ平均時(GMT)とほとんど同じですが、うるう秒を考慮しています。つまり「59分60秒」という時間もあり得るのです。
時間帯は通常、書いた人の地域に合わせます。日本からだと+0900で、緯度ゼロの地域からだと+0000です。地域に関係なく世界時(UT)のままで表したいときは-0000にします。
かつては、この時間帯にアルファベットを使う事が出来ました。もしアルファベットになってるメールを受け取った場合は、次のように数字に換算します。
GMT, UT+0000EDT-0400EST, CDT-0500CST, MDT-0600MST, PDT-0700PST-0800
この表には日本標準時(JST)がありません。JSTで送信するメールソフトが結構ありますが、そもそも昔から間違いだったのです。日本製のソフトは+0900に換算してくれるものが多いですが、日本国外製は心配です。
なお、括弧を付けて「(JST)」としているのは問題ありません。括弧はコメントなので、ソフトは読み飛ばす筈です。
Date: Sun, 02 Nov 2003 07:07:00 JST← 間違い
Date: Sun, 02 Nov 2003 07:07:00 +0900← 正しい
Date: Sun, 02 Nov 2003 07:07:00 +0900 (JST)← 正しい
あと、軍事用の時間帯でAとかBの様にアルファベット1文字で示す方法がありましたが、これは非標準です。更に元々の規格書に書き間違いがあったので、-0000に換算すべきという事になってます。
ところで、Date:フィールドを付けないメールソフトも結構ありますが、これは間違いです。サーバが代わりにDate:フィールドを付けるのも禁止なので、結局Date:フィールドがないまま受信者に届いて問題が起きる事があります。実際には付けてくれるサーバもありますが、本来は間違いです。ただし、MSAと呼ばれるサーバは、認証を行なってから付けてもよい事になっています。この動作についてはRFC2476に載っています。
非標準フィールドです。RFCのどこにも定義がありません。
一部のメーリングリスト用のソフトは、オリジナルのDate:フィールドの内容をPosted:フィールドに移し、新たにDate:フィールドを付け直します。ただし、フィールドは勝手に書き換えるなというのが本来の決まりなので、正しい動作とはいえません。
Message-Id: <0123456789.AA12345@example.com>
RFC2822で定義されています。
Message-Id:は、メールを1通1通区別するための文字列です。
インターネットは世界レベルですから、世界で唯一のMessage-Id:でなければいけませんが、これが十分に守られていないケースは非常に多いです。偶然に同じMessage-Id:が付いたメールが届いた場合、区別が出来なくなって配送されなかったり、読めなくなる可能性があります
このフィールドは付けなくても間違いではありませんが、付けるべきだとされています。通常はメールソフトが自動的に付ける筈ですが、何も付けずに送信するソフトもあります。このとき、代わりにサーバが付けることもありますが、本来は正しい動作ではありません。ただし、MSAと呼ばれるサーバに限って、認証を行なってから付けてもよい事になっています。この動作についてはRFC2476に載っています。
In-Reply-To: <123443210.BB12345@example.net>
References: <19960902101520.AA0F@example.net>
<AbCdEfGh%saburo@example.org> <123443210.BB12345@example.net>
RFC2822で定義されています。
この2つは返信のときに付けるべきだとされます。元のメールのMessage-Id:を引用することで、どのメールへの返信かを表すわけです。
普通、メールソフトで返信メールを書けば自動的に付くでしょう。
メールソフトによっては、この情報を使ってメール一覧を並べ変えて見やすくします。メールを沢山受け取るようになると、沢山の話題が入り乱れるので重宝するかもしれません。特にメーリングリストがそうでしょう。
しかし、In-Reply-To:もReferences:も付けないメールソフトが実在します。受け取った人はどのメールへの返信なのか分らなくなり、困るかもしれません。
元々これらのフィールドの使い方は結構自由で、以前届いたメールの日付とか名前とかメールアドレス等、色んなフレーズを書くことが出来ました。例えば、
In-Reply-To: Ichiro's mail of "Thu, 19 Sep 1996 22:11:05 +0200"
<123443210.BB12345@example.net>
References: Two messages - <19960902101520.AA0F@example.net>
<123443210.BB12345@example.net>
のような感じです。
しかし、2001年4月にルールが変わって、Message-Id:の中身だけを書くことになり、どのように引用するかも厳密に決まりました。
In-Reply-To:は、直接の元メールのMessage-Id:を付けます。複数の元メールに返信するときは、それらのMessage-Id:を全部付けます。
References:は、元メールのReferences:とMessage-Id:の中身を全部つけます。
元メールにReferences:がなかったら、In-Reply-To:とMessage-Id:の中身を全部付けます。
だから、何度もメールをやり取りするとどんどん増えていきます。この数に制限はありません。1000通やりとりすると999個になる計算ですが、実際のメールソフトでは10個とか16個とか、それなりの数に制限しているものもあります。
なお、In-Reply-To:とReply-To:は別なので、お間違えのないように。
非標準フィールドです。RFCのどこにも定義がありません。
POPサーバがメール毎に自動で付けることがあるようです。
POPでは、届いたメールを区別する為に、unique-idという番号を付けます。この番号が示されているようですが、普通気にする必要はないと思います。
極一部のSMTPサーバもこのフィールドを付けることを確認しています。
Resent-Date: Sat, 05 May 2001 11:22:33 +0400
Resent-From: yamada@example.net
Resent-Sender: yoshida@example.net
Resent-To: hanako@example.net
Resent-Cc: ichiro@example.net
Resent-Bcc: jiro@example.org
Resent-Message-ID: <abcde.1234.yamada@example.net>
かつてこれらは、RFC822で転送(forward)のためのフィールドとして定義されていました。
しかし、現在のRFC2822では再送(resent)のためのフィールドとして定義されています。
ユーザが一度受け取ったメールを、そのまんま他に送った事を示すために使われます。
この場合、元メールのヘッダも本文も変更を加えてはいけません。元々のDate:、From:、Sender:、To:、Cc:、Bcc:、Message-ID:はそのまんまにしておき、代わりにメールヘッダの一番上にRecent-で始まるフィールドを付けるわけです。
この目的は、最終的な受信者に元の送信者から直接送られたように見せることです。
実際には、これらのフィールドはあまり使われていません。
多くのソフトは転送(forward)の機能を持っていますが、ヘッダフィールドは新しく作るでしょう。Subject:に「Fw: 」とか「転送：」とかの文字を付け加えるだろうし、本文も書き加えられるようになっているでしょう。
なお、RFC822ではResent-Reply-To:というフィールドもありましたが、RFC2822では廃止されています。
Return-Path: <taro@example.com>
Received: from mail01.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: from subserver.example.com
by mail01.example.com (Original Mail Server 1.2)
with ESMTP id EAA09615;
Fri, 24 Aug 2001 05:48:10 +0900
Received: by local.example.com; Thu, 23 Aug 2001 20:48:00 -0000
Received:とReturn-Path:は、RFC2822で定義されていますが、細かい事はRFC2821で定義されています。
メールを受け取ったサーバが付ける情報です。
Received:フィールドは、ヘッダの一番上に付ける事になってます。だから、何台も経由した場合、下から上にReceived:フィールドがどんどん増えていきます。
RFC2822では、様々な転送方法を想定してか、「;」の後に日時を書くことだけが決まっています。その前に何を書くかは、細かくは決まっていません。
ただし、SMTPで受け取った場合はRFC2821の決まりで次のような書き方になります。
fromのドメインからbyのドメインがviaの接続方法を使ってwithの転送方法で受け取り、そのときの区別する番号がidで、forのアドレス宛です。「;」以降は受け取った日時です。
このとき必須になるのは、「from」、「by」、「;日時」の3つです。
ここの日時を調べると、遅れて届いたメールがどこで停滞していたかわかるかも。
Return-Path:フィールドは、一番最後にメールを受け取ったSMTPサーバが、Received:フィールドの更に上に付けます。ただし、必須フィールドではないので付けないサーバもあります。
送信側で付けるものではありません。
エンベロープのMAIL FROM:の内容を一番最後のサーバがReturn-Path:に書き写すのです。つまり、もしこのメールが配送段階で問題が出ていたとしたら、ここに書いてあるアドレスに通知が返っていった筈です。
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のようにスラッシュで区切られているものは、MIMEで拡張されたフィールドであり、RFC2045で定義されています。
この形式のフィールドが付いている場合は、Mime-Version:フィールドも付いている筈です。
本文やMIMEによって分割した部分の形式を示します。
text/plainとは「ただのテキスト」ですね。
charset=というパラメータは、本文の文字コードを表しています。charset=が書いてない場合はUS-ASCIIです。
もともと日本国内のネットワークでは、本文中のエスケープシーケンスを見て「日本語だな」という事を判断していました。
しかし、世界中が繋がった現在のインターネットでは、このエスケープシーケンスで判断するルールは定着していません。ISO-8859-1等の文字コードはエスケープシーケンスを使ってないので、何の文字コードなのか判別出来ないのです。そこで考えられたのがcharset=パラメータなわけです。
このcharset=パラメータがないとISO-2022-JPであることに気付かず文字化けするものも実在します。特に日本国外製ソフト。
この場合「htmlのテキスト」ですね。これはwebブラウザ等で使われているものです。
この場合「エンリッチド テキスト」ですね。ワープロの様に文字を装飾出来る方式です。
この場合「マルチなパートがミックス」つまり「複数の部分が一緒」ですね。
これを使うと、メールの本文を複数に分割できます。
例えば、MIMEを使って普通の文章にファイル等を添付したとき等に使われます。boundary=でそれぞれの部分の区切りを示します。詳しくは[10.2.3]を見てください。
この場合、「マルチなパートから選択できる」ということです。
つまり、複数の形式がboundary=で区切られているけれど、実は同じ内容なのでどれかを選んで読めばいいという事です。
例えば、普通のテキスト(text/plain)とhtmlのテキスト(text/html)なのだが文章は同じ場合とか、英語と日本語なのだが内容は同じ場合だとか。
WebブラウザのFORM機能を使って送られてきたメールに自動的に付いています。
メールの本文がboundary=で示した文字列で区切られ、それぞれのデータが付いている事でしょう。
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-Dispatcher: Super Mail Ver 1.2
本来、インターネットメールではソフト名を知らせる決まりはありません。だからそういう用途のヘッダフィールドもありません。しかし、非標準ながらも多くのソフトはフィールドに名前やバージョン番号を入れます。
User-Agent:は、その名の通りUser Agent (UA)が自分の名前を付けているようです。このフィールドは本来はWeb用のもので、ブラウザからHTTPサーバへ自分のソフト名やバージョン等の情報を知らせるときに使うものです。RFC2616で定義されていますがメールとは何の関係もない筈です。
X-Mailer:もUser Agent (UA)の名前を付けているケースが多いのですが、サーバ (MTA,MSA)が自分の名前を付けているケースもある事を確認しています。この場合、UAからMTAへ独自の方式でメールを受渡していたので、ひっくるめてメーラだという考え方なのでしょう。非標準フィールドながらも、RFC2076に情報があります。
X-Dispatcher:は、送信に使ったソフトの名前が付いているようです。メールを読む/書く/送信する/受信するといった機能をそれぞれ別のソフトに分割してるケースがあり、敢えて送信ソフトだけ名前を別にしているのでしょう。こいつはRFCには出てきません。
Return-Receipt-To: taro@example.com
非標準フィールドですが、RFC2076に情報があります。
一部のメールサーバは、ちゃんと配送出来たかどうか、開封されたかどうかを知らせるメールをここに書いてあるアドレスに送ります。
しかし、このフィールドは非標準なので最近のメールサーバはサポートしません。これについては、[12.4.6]も読んでください。
Disposition-Notification-To: taro@example.com
RFC2298で定義されています。
MDNという方式の開封通知を要求するフィールドです。このフィールドを付けて送信すると、受け取った側のMDN対応メールソフトは「開封しました」という通知をここに書いてあるアドレスに送ります。
ただし、これに対応してないソフトは何も通知しません。対応してるソフトでも「通知を送りますか？(Yes/No)」という事を確認してくるものも多いです。人間に確認もせず勝手に通知すべきではないとされるからです。悪意のある相手に勝手に通知されたりしたら困るわけです。
これについては、[12.4.6]も読んでください。
Errors-To: taro@example.com
非標準フィールドですが、RFC2076に情報があります。
一部のメールサーバは、配送に失敗した場合、エラー通知をここに書いてあるアドレスに送ります。
しかし、このフィールドは非標準なので最近のメールサーバはサポートしません。エラー通知はエンベロープのMAIL FROM:に送るのが正しい動作だからです。
ただし、SMTPではない独自形式のネットワークに転送されたとき、エンベロープの情報が失われる事があるので、代わりにこのフィールドの情報を使う場合があります。
これについては、[12.4.6]も読んでください。
X-MIME-Autoconverted: from 8bit to base64
by mailgw.example.org id HAA123456
非標準フィールドです。RFCのどこにも定義がありません。
一部のメールサーバは、8ビットのメールを受け取って次のサーバに渡す前に7ビットに変換します。そのときの情報をサーバが付けているようです。
逆に、最後に受け取ったサーバがbase64やquoted-printableを8bitに戻すものもあります。
byのところに、実際に変換を行なったサーバの名前が付いているようです。idのところは、そのサーバが付けたReceived:フィールドと同じになっているようです。
特に韓国では、8ビットのEUC-KRが一般的に使われているので、サーバ側に細工をしてこの変換を行なっているケースがあります。
X-Authentication-Warning: mailgw.example.org:
user@server.example.com [192.168.1.3] didn't use HELO protocol
非標準フィールドです。RFCのどこにも定義がありません。
SMTPの手順では、送り側がHELOという手続きを行なう事になっています(ESMTPの場合はEHLO)。この手続きを省略するソフトがあり、このとき受け側のサーバが警告としてこのフィールドを付けるものがあります。
Encoding: 43 Text, 21 uuencode
MIMEでは本文を複数の部分に分割する事が出来ます。このEncoding:フィールドは、MIMEとは別に考えられた分割方法です。
本文を空行で分割するだけの単純な方法です。この例の場合、普通のテキスト(text)が43行あり、1行空けてからuuencodeが21行あるという意味です。
これは実験的に公開されたRFC1505で定義されたフィールドであり、以前はちょっと見かけました。最近はMIMEが有名になったので、あまりみかけないと思います。