IIJ技術研究所 山本和彦
前回はテキスト・メールの歴史や書式について解説しました。 今回はヘッダ中のフィールドの意味や使用方法、 そしてよく見受けられる誤解などについて解説していこうと思います。 これはインターネット・マガジンに執筆した原稿を元にしています。 紙面の関係上削られた部分も残っていますので、 既に同誌を読んで下さった方にも役にたつかもしれません。:-)
インターネットはすべての人が活動できるオープンな世界です。 この特徴はインターネットのルールすべてが話し合いによって決定され、 公開されていることが根底となって支えられています。 インターネットでは、データの送受信方法やデータの書式などの取り決めも含む、 技術的なルールをプロトコルと呼びます。
プロトコルは、 RFC(Request For Comments)という通し番号のついた オンライン・テキストとして公開されています。 その名前が示すように、元々 RFC は議論をするための叩き台でした。 (もっと本当のことを言うと、RFC が書かれ始めた時代は、 国を代表するプロトコル設計のプロが仕様を定めていました。 インターネットを設計した人達は、彼らからすればアマチュアだったので、 プロの反感をかわないように RFC という名前を選びました。) しかし、RFC の権威が増すにつれ、 インターネットの技術者は RFC を仕様書として活用するようになりました。 議論のための叩き台の役割は、現在 Internet-Draft に譲っています。 綿密に議論され合意に達した Internet-Draft が RFC に昇格します。
今回は、メールの書式を定めている RFC2822 (旧 RFC 822)を技術的な根拠として、 メールのヘッダについて解説していきます。 インターネットでメールを利用するためには、 RFC 2822 で規定された書式を厳密に守らなければなりません。 これは、インターネットの秩序を保つ上で歓迎すべき制約です。
規格に従いさえすれば、どんなベンダーもメールリーダを作成できます。 複数のベンダーが参加すれば、 公平な市場原理が働くことに加えて、 市場も活性化されていきます。 いくらでも代替品は存在するおかげで、 ユーザは 1 つの企業が独占している技術や製品に頼る必要はありません。
理解して頂きたいことは、 インターネットでは「大手ベンダーがそう実装しているから正しい」 とはいえないことです。 逆に大手ベンダーの方が RFC を遵守することに無頓着なきらいがあります。 ユーザは公開されている技術的な内容をできる限り理解し、 それをベンダーに守ってもらうよう働きかける必要があります。 このような日頃からの少しばかりの努力があれば、 インターネットはいつまでも健全な状態に保たれるのですから。
それでは、メールを眺めてみましょう。
Received: from mailgate.beech.tree.uk (robin.beech.tree.uk [10.1.2.3])
by mx.100acre.woodwest.uk;
Sat, 1 Aug 1998 14:30:25 +0900
Received: from hunny.beech.tree.uk (hunny.beech.tree.uk [192.168.0.1])
by mailgate.beech.tree.uk;
Sat, 1 Aug 1998 14:24:01 +0900
Sender: pooh@100acre.woodwest.uk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
X-Mailer: Mew 1.93
Message-ID: <237820.pooh@100acre.woodwest.uk>
From: Winnie-the-Pooh (プー) <pooh@100acre.woodwest.uk>
To: "P.P.Piglet" <piglet@beech.tree.uk>
Date: Sat, 1 Aug 1998 14:23:33 +0900
Subject: 遊びましょう
明日 Roo に会いに行きませんか？
// Winnie
メールは、ヘッダと本文が空行で区切られた形をしています。 ヘッダはフィールドの集合です。 フィールドはフィールド名とフィールド値を「:」で区切った形をしています。 以下の例を考えてみましょう。
Subject: 遊びましょう
フィールド名は「Subject」、フィールド値は「遊びましょう」です。 フィールド名は大文字小文字を区別しないので、 「Subject」、「SUBJECT」、 「SuBJeCT」は同じフィールド名になります。 「:」の後の空白は仕様としては不要ですが、 慣習的に入れることが多いです。
上の例を厳密に表現すると、 「フィールド名は Subject でフィールド値には『遊びましょう』が 格納されています」となります。 しかし、日頃はこういうふうに言うのは面倒なので、 単に「Subject: は『遊びましょう』です」と表現します。 また、このフィールド全体を示すために 「Subject: フィールド」と言うこともあります。
フィールド名は比較的短いので問題ありませんが、 フィールド値は長くなる可能性があります。 長い行を取り扱えないメールの配送プログラムが存在した歴史的経緯から、 一行は ASCII キャラクタ 76 文字以下に押えることが慣習になっています。 そこで、77 文字以上のフィールド値は、適宜改行を入れて折り返します。 改行した行には継続を示すために行頭にタブが空白を入れます。
以下の例は 3 行に渡っていますが、実際は 1 つのフィールドです。
Received: from mailgate.beech.tree.uk (robin.beech.tree.uk [10.1.2.3])
by mx.100acre.woodwest.uk;
Sat, 1 Aug 1998 14:30:25 +0900
送信時の折り返しや受信時の連結はメールリーダが自動で処理するので、 通常ユーザが気にする必要はありません。
重要なフィールドを説明していきましょう。 まず、メールの内容の要約を書くために 「Subject: フィールド」が 用意されています。 このフィールド値は単なるテキストとして扱われます。
昔も今もネットワーク上を配送されている際のヘッダには ASCII 文字しか格納できません。 上記の例で日本語が使えているのは、 配送の際に ASCII 文字へ符号化されているためです。 上記の例は実際には
Subject: =?iso-2022-jp?B?GyRCTTckUyReJDckZyQmGyhC?=
のようになっています。 受信側はこの呪文を自動的に復号化するので、 日本語として表示されているのです。
この符号化は RFC2047 で規定されています。 RFC2047 は RFC2045、RFC2046、RFC2048、RFC2049 と共に、 マルチメディア・メール(MIME)を定めています。 マルチメディア・メールを使えば、 さまざまなデータの配送が可能になります。 RFC2047 の符号化は(涙が出るぐらい)難しいので今回は解説しません。
RFC2047 が策定される前までは、 よく「Subject: に日本語を入れてはいけません」 と言われていました。 最近のメールリーダでは RFC2047 を実装しているので、 ユーザは気にせずに日本語を利用できます。 ただし、RFC2047 を実装していないメールリーダを使っているなら、 やはり日本語を使用してはいけません。
メールが送信された時刻を表すのが Date: です。 Date: フィールドは、
Date: 曜日, 日 月 年 時刻 ゾーン
という書式に従います。たとえば、
Date: Sat, 1 Aug 1998 14:23:33 +0900 (JST)
のようになります。
曜日は省略可能で、日曜から土曜までを Sun、Mon、Tue、Wed、Thu、Fri、Sat で表します。
月は 1 月から 12 月までを Jan、Feb、Mar、Apr、May、Jun、Jul、Aug、Sep、 Oct、Nov、Dec で表します。
上記の例は、日本時間を表しています。 日本は標準時から 9 時間進んでいるので、+0900 と表現します。
メール・アドレスに関するフィールドで最も重要なのは、 To:、Cc:、および、From: です。 To: は宛先、From: が送信者、そして、Cc: は宛先ではないけれ ど一応内容を知らせておきたい人を意味します。 これらのフィールド値に複数のメール・アドレスを書く場合は「,」で区切ります。
To: pooh@100acre.woodwest.uk, piglet@beech.tree.uk
たくさんメール・アドレスを書く場合は適宜折り返します。 仕様としては意味を壊さないところならどこで折り返しても構いませんが、 「,」の後で折り返すことが推奨されています。
Cc: はカーボンコピー(carbon copy)の略語です。 私の世代でさえカーボンコピーにはあまり縁がありませんが、 コピー機がなかった昔は、 コピーを取るためにあらかじめカーボン紙を挟んで押えるようにして 文字を書きました。 こうすれば、カーボン紙の下の紙に文字が複製されます。 これを他の必要な人に配ったのです。
メールの初心者には、Cc: の使い方がよく分からないかもしれませんので、 1 つ例を挙げてみましょう。 たとえば、上司のスケジュールを押える際に、 秘書にも同じ内容を伝えたいことがあります。 この場合、上司を To: に秘書を Cc: に指定すればよいのです。
Cc: には「あなた宛ではありません」というニュアンスが含まれていますので、 To: に自分のメール・アドレスが入っていない限り読まない人がいます。 ですから、To: と Cc: はなるべく使い分けるように心がけましょう。 一通目のメールでは気をつける人が多いのですが、 返事を書くときはメールリーダが自動的に指定した To: や Cc: を盲目 的に使ってしまいがちです。 どんな場合にも To: や Cc: には気を配るべきでしょう。
さて、From: に複数のメール・アドレスを入れられるのかと 疑問に思った人もいるでしょう。 あまり使われていませんが、これも仕様では可能になっています。 複数の人が連名でメールを送信したいときに利用します。 僕は結婚式の案内のメールで、 2 人のアドレスが入っている From: を見たことがあります。:-)
メール・アドレスは、 自分のフルネームとは違う場合が多いので、 実際の名前を添えたくなることがあります。 この場合はメール・アドレスを 「<」と「>」 で囲み、その前にテキストを挿入できます。 たとえば、
From: Winnie-the-Pooh <pooh@100acre.woodwest.uk>
となります。 さらに、「(」と「)」で囲まれた文字列はコメントとして 無視されますので、 意味が変わらないところならどこでも挿入できます。 たとえば、
From: Winnie-the-Pooh <(winnie-the-)pooh@100acre.woodwest.uk>
としても間違いではありません。 ただし、コメントはこのような複雑な技術に溺れることなく、 テキストに添えて書くのが無難でしょう。 たとえば以下のようにします。
From: Winnie-the-Pooh (プー) <pooh@100acre.woodwest.uk>
ASCII 以外の文字列は RFC2047 に従って符号化されます。 以下に上記を符号化した例を示します。
From: Winnie-the-Pooh (=?iso-2022-jp?B?GyRCJVchPBsoQg==?=) <pooh@100acre.woodwest.uk>
あるメールリーダで日本語を符号化し、 他のメールリーダで復号化すると、 元々の文字列と異なってしまうという相互接続性の問題が 起こることがあります。 理解と実装が難しいことを除けば RFC2047 の仕様自体には問題はありません。 相互接続性の問題が起こるのは、 厳密に RFC2047 に従っていないメールリーダが存在するからです。 相互接続性の問題の端的な例を紹介しましょう。
RFC2047 では To: や Cc: などアドレスを記述するフィールドにおける 「"」で囲まれた文字列は、 いかに RFC2047 で定められた符号化の書式をしていても 復号化してはいけないと規定されています。 元々 RFC2822 で 「"」で囲まれた文字列は、 そのままの形で取り扱うよう定められているからです。よって、
From: "=?iso-2022-jp?B?GyRCJC8kXiROJVchPCQ1JHMbKEI=?=" <pooh@100acre.woodwest.uk>
という From: フィールドは、厳密に RFC2047 に従ったメールリーダなら
From: "くまのプーさん" <pooh@100acre.woodwest.uk>
のようには復号化されません。 「"」で囲まれているので、呪文がそのまま表示されます。 残念ながら、「"」で囲まれた文字列の中に呪文を埋め込んでしまう間違った メールリーダはたくさんあります。
「,」はメール・アドレスの区切りであるのでテキスト部分に「,」がある場合 は「"」で囲む必要があります。 たとえばこんな風にです。
From: "Pooh, Winnie" <pooh@100acre.woodwest.uk>
「"」で囲まないと 2 つのメール・アドレスが 指定されていることになってしまいます。
逆にいうと、こういう特殊な文字がないかぎり「"」を使う必要はありません。 いくつかのメールリーダは、ユーザがそう指定していないにもかかわらず、 わざわざ「"」でテキスト部分を囲んでしまいます。 よって、たとえば以下のようなおかしな From: ができあがります。
From: "Winnie-the-Pooh (=?iso-2022-jp?B?GyRCJVchPBsoQg==?=)" <pooh@100acre.woodwest.uk>
くどいようですが、 厳密なメールリーダではこの呪文が「プー」に変換されることはありません。 このように 「,」のような特殊な文字を使わない限り、 「"」で囲む必要はまったくありません。
「:;」 で終る宛先が書いていない不思議なメールをもらったことがある 人がいるかもしれません。たとえばこんな感じです。
To: Pooh Lovers:;
RFC 2822 では、 これは ":" と ";" の間に指定された アドレス群をグループ化するために定義されています。 アドレス群は省略してもいいので、 メールリーダによっては返答を防止するための宛先として使っています。
ここでは、そいうメールリーダに限った話をします。 たとえば、複数の人に送信したいが、 その人達のメール・アドレスは伏せたい場合にこの書式は有効です。 例を挙げるなら、会議の参加者に主催者がプログラムを送る場合です。 このように To: が匿名になっていれば、 このメールに返答しても間違って多くの人に配送されることはありません。 確実にこのメールの From: だけに返答を返すことになるでしょう。
この機能を利用するためには、 まず自分のメールリーダがこのグループ送信機能を 実現していることを確かめないといけません。 サポートされているメールリーダで、この機能を利用するには、
To: Pooh Lovers:pooh@100acre.woodwest.uk,piglet@beech.tree.uk;
のようにグループを表現する文字列に続いて「:」と「;」の 間に実際に届けたいメール・アドレスを「,」で区切って羅列します。 メールリーダは、実際に配送するメールから「:」と「;」の間を削り 送り届けるのです。
Subject: や To: などは RFC 2822 で規定されているフィールドですが、 ユーザも自由にフィールドを定義する方法が提供されています。 「X-」 で始まるフィールド名は、ユーザが自由に定義して構いません。
たとえば、X-Mailer: は使っているメールリーダを示すために使われています。 X-Mailer: は元々誰かが勝手に作ったフィールド名ですが、 多くの人がまねするうちに実質的な標準となった感があります。 以下に例を示します。
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
このフィールドを見れば相手がどんなメールリーダを使っているか 推測できます。 たとえば、Excel のデータを添付して送りたい場合を考えてみましょう。 相手が Windows や Mac のように Excel が動く OS を使っていないのでしたら、 Excel のデータを送り付けても迷惑がられるだけです。 よって、相手に Excel が使えるかメールで問い合わせるのが一番確実ですが、 以前その人から送られてきたメールがあるなら、 X-Mailer: を調べてみるのもよい考えです。
ユーザが定義したフィールドが広まった他の例としては X-Face: が挙げられます。 X-Face: に対応しているメールリーダでは、 小さな顔写真をヘッダ中に格納したり表示したりできます。
Message-ID: フィールドは、 メッセージを特定するための ID 情報です。 フィールド値の書式は、 メール・アドレスを「<」と「>」で囲んだ形を取ります。 ただし、 メール・アドレスだけでは、 同じ人が書いたメールを区別できないので、 ユーザ名の前に時間情報をくっつけます。 このとき、ユーザ名を省略することもあります。 以下に例を示します。
Message-ID: <237820.pooh@100acre.woodwest.uk>
返事を書く際には、 どのメールに返答したのかを明示するために In-Reply-To: フィールドが用いられます。 たとえば、上記のメールに返答した際には
In-Reply-To: <237820.pooh@100acre.woodwest.uk>
となります。 (In-Reply-To: は後述の Reply-To: と似ていて間違いやすいので注意して下さい。)
また、関連あるメールを複数記述できるフィールドとしては References: があります。
In-Reply-To: や Reference を活用すると対話関係を視覚的に表現するスレッ ドと呼ばれる機能が実現できます。 逆に言えば、Message-ID: がそのメールを一意に 特定するよう生成されないと、 スレッドの機能は利用できません。
たとえば、 あるメールリーダが送信するメールすべてに同じ Message-ID: を 付けているとしましょう。 すると、ある ID に対して複数のメールが存在す ることになりますので、スレッドが作れなくなります。
固定の文字列を Message-ID: に指定するおかしなメールリーダは 実際に存在するようです。
前述のように、From: フィールドはメールの発信者が示されています。 このフィールドは、ユーザの指示に従ってメールリーダが付けます。
From: がユーザの指定通りに記述されるということは、 だれもが簡単に他人になりすませることを意味しています。 どうやればできるか説明はしませんが、 実際いやがらせをしたい人のメール・アドレスを From: に 指定することはとても簡単です。 つまり、他人の名を語っていたずらすることは容易なのです。
もし、だれかから失礼なメールをもらったら、 他の誰かからのいたずらであるという可能性も考えないといけません。 本当に他人を認証したいのなら、電子署名を利用する他ありません。 電子署名については、またいつか解説したいと考えています。
From: と似たフィールドに Sender: があります。 From: が複数のメール・アドレスを書けるのに対し、 Sender: には 1 つしか書けません。 Sender: の役割としては、 From: に複数のメール・アドレスが指定してある場合に、 実際に送ったのは誰かを識別することが挙げられます。
Received: はメールが配送される際にどの 配送システムを通過したかという情報が保存されています。 Received: のフィールド値の書式は難しいですが、 簡単に言えば 「from」の後にどの配送システムから配送されたか、 「by」の後にどの配送システムが受け取ったかを記述します。 また、「;」に続けて中継した時間を Date: と同じ書式で記述します。
ヘッダ中のフィールドの順番にはなんら規則はありません。 しかし、新しい Received: は、 通常古い Received: の前に追加されていきます。 世界中の配送システムの時計が合っているとは限らないが、 あまりずれがないと仮定すると、 順番が狂っていても時刻上から並び直すことが可能です。
前記の例は、以下のようになっています。
Received: from mailgate.beech.tree.uk (robin.beech.tree.uk [10.1.2.3])
by mx.100acre.woodwest.uk;
Sat, 1 Aug 1998 14:30:25 +0900
Received: from hunny.beech.tree.uk (hunny.beech.tree.uk [192.168.0.1])
by mailgate.beech.tree.uk;
Sat, 1 Aug 1998 14:24:01 +0900
嘘を付かれていないと仮定すると、この例では
hunny.beech.tree.uk → mailgate.beech.tree.uk → mx.100acre.woodwest.uk
の順で配送システムを経由してきたことが分かります。
一番上の行では 「(」「) 」の中のホスト名が、mailgate.beech.tree.uk と robin.beech.tree.uk のように異なっています。 これは、1 つの IP アドレスに 対して複数のホスト名を付けているためです。
この例では、メールの配送プロトコル上では、malgate.beech.tree.uk と いう名前を名乗りました。 その通信は 10.1.2.3 から発信されていたので、 この IP アドレスを逆引きしたところ robin.beech.tree.uk という 名前が得られたのです。
このような知識を持っていれば、 スパムメールがどこを経由してきたかある程度推測できるようになります。 スパムメールは一般に管理の疎かな配送システムに無理矢 理中継させることで、たくさんの人に配送されます。 注意したい点は、スパムメールでは Received: フィールドに 嘘の情報が記述されることが多いことです。
配送システムは近くのもの程信用できます。 スパムメールに限っていえば、 中継に悪用された配送システムは嘘の情報は記述しないでしょう。 ですから、近くの配送システムから Received: フィールドを丹念にたどっていけば、 悪用された配送システムまでたどり着けます。 また、その悪用されたシステム A に対して、 スパムメールを送った配送システム B が、 嘘の IP アドレスを教えることは困難です。 よって、A は B の IP アドレスを逆引きしてB のホスト名を得ている 可能性があります。
そこで、スパムメールの発信基地である B を推測できるかもしれません。 ただし、B が PPP アカウントで常にはないホストだったり、 リクエスト・ベースでメール・アカウントを作成するホストだったりする 可能性は高いです。 結局ここまで推測しても犯人を特定することは困難かもしれませんが、 こう考えて来ると心に刻んでおくべきことが 2 つあります。
ここでは、メール・アドレスに関するフィールドの中でも 少し特殊なものを紹介しましょう。 ぜひ覚えて頂きたいルールは、 「よく分からないフィールドは使わない方がよい」ということです。 ここで説明するフィールドは普段使う必要はほとんどないはずです。 もし利用したいなら、フィールドの意味を完全に理解してからにしましょう。
Bcc: は、送り先に気づかれないよう他の人に Cc: するためのフィールドです。 このフィールド値に指定されたメール・アドレスにメールは届けられますが、 このフィールド自体は消えてしまいます。 よって、To: や Cc: に指定された人がこのメールを受け取っても、 Bcc: があったとは分かりません。 Bcc: に指定されたためメールが送られて来た人は、 To: や Cc: に自分のメール・アドレスがないので、 Bcc: されたのだろうと推測します。
この機能は暗いので、利用をさとられると気分を害してしまうことがあります。 私自身もこの機能は好きではないので、人には勧めていません。 どうしても受信者に気づかれずに A さんに届けたいなら、 まずその受信者だけにメールを送り、 保存しておいたメールを A さんに転送する方がいいでしょう。
From: とは違うメール・アドレスに返事をもらいたい場合のために Reply-To: フィールドが用意されています。 たとえば、出先からゲスト・アカウントを借りてメールを出す場合、 返事は通常の自分のメール・アドレスに返して欲しいでしょう。 また、旅行にいくので旅行先のメール・アドレスに 返答して欲しい場合があるかもしれません。
経験的にいえば特殊な場合を除いて Reply-To: は指定しない方がいいと思います。 そもそも Reply-To: があるメールに対し返事を書く場合、 どのような動作になるかはメールリーダによってまちまちです。
たとえば、
To: A From: B Reply-To: C
となっていた場合、あるメールリーダでは
To: C From: A
となるかもしれませんし、また他のメールリーダでは、
To: B,C From: A
となるかもしれません。 だから自分の望むように 相手のメールリーダが動作するとは期待しない方がよいでしょう。
また、Reply-To: を盲目的に付けていると メーリング・リストで嫌われることになります。 たとえば、A さんが自分が参加しているメーリング・リスト ML に A さんがメールを投稿した場合を考えましょう。 A さんはいつも自分向けに Reply-To: を指定しているとします。 投稿されるメールはこのようになるでしょう。
To: ML From: A Reply-To: A
ML はグループ・コミュニケーションであるので、 返答は ML に返すことを期待されている場合が多いです。 実際この場合に A さんも ML 宛に返事を返して欲しいのでしょう。 不用意に Reply-To: が付いてくるメールに対処するため、 Reply-To: をメーリング・リスト向けに 上書きしているメーリング・リストもあります。
旅行先で返事を受け取りたいなら、 通常のメール・アドレスで受け取り、 それを自動的に旅行先に転送するよう設定すればよいでしょう。
RFC822 で定められたメールは 本文に ASCII テキストのみしか配送できなかったので テキスト・メールと呼ばれています。 一方 RFC2045 からの 5 つの RFC で定められた MIME では、 テキスト以外にも画像や音声などのデータの添付が可能になっています。
MIME-Version: 1.0
というフィールドがあるメールが MIME メール、無いメールが テキスト・メールです。
MIME では、 さまざまなデータ型を明示的に指定するために Content-Type: というフィールドを用意しました。 Content-Type: のフィールド値は 「種類/具体的なデータ型」という書式をとります。 種類には、 Text, Image, Audio, Video, Application, Multipart, Message があります。
たとえば、Text/Plain は通常のテキスト、Image/Jpeg は JPEG のデータ型を 意味します。
Content-Type: では付加的な情報を追加するために 「;」で区切った パラメータを指定することが可能です。 パラメータは「パラメータ名=パラメータ値」の書式に従います。
たとえば、Text/Plain では文字コードを指定するための charset というパラ メータが用意されています。 日本語の場合は iso-2022-jp を指定します。 よって、本文に日本語を含んだ MIME メールには、
MIME-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp
というフィールドが存在します。
一般的にヘッダと本文(ペイロード)という構造をもつデータを 再配送するには、 「ヘッダ変換」と「カプセル化」という 2 つの方法があります。
ヘッダ変換は、元々のヘッダを加工して再利用し、 データを再送する技術です。
カプセル化とは、元々のデータ全体をを新たな データの本文中に埋め込んで(つまり、カプセル化して) 再配送する技術です。
メールにとって、カプセル化は分かりやすい概念であり、 一般的に「転送」と 呼ばれています。MIME 以前は、本文に
--- Forwarded Message --- 転送するメール --- End of Forwarded Message ---
のように転送するメールを格納して再配送していました。
MIME では、Content-Type: Message/Rfc822 というデータ型を指定して 再配送します。
ヘッダ変換を用いて再配送するためには、Resent- で始まるフィールドを 指定します。 前出のメールを再配送することを考えてみましょう。 このメールは、
From: Winnie-the-Pooh (プー) <pooh@100acre.woodwest.uk> To: "P.P.Piglet" <piglet@beech.tree.uk> Date: Sat, 1 Aug 1998 14:23:33 +0900
のように pooh から piglet に送られたものです。 piglet が kanga に再配送する場合は、例えば以下のようになります。
Resent-From: piglet@beech.tree.uk Resent-To: kanga@100acre.woodwest.uk Resent-Date: Sun, 2 Aug 1998 10:11:22 +0900 From: Winnie-the-Pooh (プー) <pooh@100acre.woodwest.uk> To: "P.P.Piglet" <piglet@beech.tree.uk> Date: Sat, 1 Aug 1998 14:23:33 +0900
このメールを Resent- の機能を知らない kanga が見れば、 どうして pooh から piglet に送られたメールが自分に届いたのだろうと 不思議に思うでしょう。 実際には Resent-From: に指定された piglet が Resent-To: に指定された kanga に再配送したのです。
このように Resent- を使ったヘッダ変換は相手を混乱させるので、 通常はカプセル化による転送を用いた方がよいと思います。 それでもなお、Resent- を利用すると便利な場合があります。
今回はこれでおしまいです。 だいたいのフィールドは網羅できたと思いますが、 もし洩れていて解説して欲しいフィールドがあれば 御一報下さい。