■ エンベロープとメッセージ

さてさて、ネット君。前回、エンベロープとメッセージという話をしたな。

はいはい、封筒と便箋でしたよね。
封筒がエンベロープ、便箋がメッセージ。

そうだな、前回出てきた図だとこうだったな。

EHLOとか、MAIL FROMとか、RCPT TOの部分がエンベロープでしたよね。
封筒の表書き。

そうだ、宛先や送信元などを書く部分が「封筒」、エンベロープだった。
さて、今回は便箋の話だ。

中のメール本文ですね？

そうだ。「DATA」コマンドから始まって、「. <CR><LF>」で終わるまでの部分だ。
さてネット君、ここで質問だが、便箋には何が書かれているかね？

え？ 手紙の内容ですよ？

確かにそうだ。
では、便箋に書くことは、手紙の内容、つまり「伝えたいこと」だけかね？

ん？ ん〜、そうじゃないですか？
伝えたいこと以外、なんか書きますっけ？

書くだろう。ちゃんとした手紙を考えてみたまえ。
ネット君、手紙を書くときには、まず、何を書く？ 一番最初の行に書くことは？

やっほ〜。

……。

あ、まいど〜ってものアリですが？

なんというか、予想通りというか、予想外というか。
相変わらず人を飽きさせないな、君は。

えへへ。

褒めてねぇ

はぅっ。

あぁ、もう、話が進まん。
つまり、こうだ。

普通、「宛先」「送信元」「手紙を書いた日時」などを手紙の最初に書くだろう？

あ〜、確かにそういう文化がありますね。

文化……。
まぁ、いい。ともかく、手紙を読む側にとっての宛先・送信元などの情報がここにあるわけだ。

「手紙を読む側にとって」？ なんか含みのある言い方じゃないですか。

うむ。エンベロープ、封筒は「手紙を届ける側」、つまり郵便配達、SMTPサーバにとっての「宛先」「送信元」の情報だ。「手紙を読む側」ももちろんエンベロープ部分を見ることはあるが、基本的にはこの手紙の先頭部分が情報源じゃないか？

ん〜、確かに、封筒を開けて便箋を取り出したら、見るのはそこ、手紙の先頭部分ですよね。

そうだろう？ つまり、「伝えたいこと」である「本文」の前には普通そういう情報が書かれるわけだ。例えば、OutlookExpressでの画面なら、ココの部分だ。

あれ？ ここってエンベロープの「宛先」とか「送信元」を表示してるんじゃないんですか？

いや、エンベロープではなくて、メッセージの「前書き」部分だ。
この部分をメールヘッダと呼ぶ。

めーるへっだ？

そうだ、封筒のエンベロープではなく、便箋のメッセージにかかれる部分だな。
で、このメールヘッダの後に本文が続くことになる。つまり、メールメッセージとはこういう形になっている。

本文のところが「メールボディ」だな。
メールヘッダとボディの識別は、改行(<CR><LF>)のみの行で判別する。

ははぁ。

■ 代表的なメールヘッダ

メールヘッダに追加される情報はヘッダフィールドと呼ばれる。これを複数記述していく形になる。

ヘッダフィールドは必ず1行で、最後に改行(<CR><LF>)が入る。
この形だ。

名前、コロン、値で、改行ですね。

そうだ。で、最後に改行のみがはいると、メッセージヘッダ終了の意味になる、というわけだ。

あ〜、なんか、アレに似てますね。HTTPのメッセージヘッダ？ ▼ link

そうだな、HTTPのメッセージヘッダも基本的には同じ形だったな。
HTTPのメッセージヘッダも種類が多かったが、メッセージフィールドも負けず劣らず多い。代表的なものをいくつかあげよう。

まぁ、他にもいろいろある。

うわわわ、なんかもう、いっぱいありすぎて困りますよ？

困りはしないが。
基本的に、メールをやりとりする際に「手紙を読む側にとって」必要な情報、というわけだ。

ん〜、手紙の作成日、送信元、宛先、返信先…、たしかにそうですね。

さて、メールヘッダのポイントだが。
まず、メールヘッダはあってもなくてもよい。

え？ そうなんですか？

どのヘッダフィールドを使用するか、ということは任意だ。
MTA、MUAの仕様による。

ん〜、でもメールヘッダないと、情報が…。

ネット君、忘れたのか？
メールヘッダは「手紙を読む側にとって」の情報で、「手紙を届ける側」に必要な情報ではない。

そういえばそうでしたね。

メールヘッダの有無はメールの送受信に影響を及ぼさないわけだ。
そして、これに関連したポイントの2つ目は。

2つ目は？

メールヘッダの情報は必ずしも正確である必要はない。

うぇ？
いや、だって。博士？ 宛先とか送信元とか…、正確じゃないとまずいじゃないですか？

どこがだ？ 何がまずい？

宛先が違ったら届かないとか…。

ネット君。ひとつ言っておくが、鳥でももう少し記憶力はあるぞ？

そうですか、えへへ。

褒めてねぇと言っている。

はぅぅ。

さっきなんと言った？ 「メールヘッダの有無はメールの送受信に影響を及ぼさない」といったはずだな？
メールをやりとりするのに必要なのは、エンベロープの情報であって、メールヘッダではない。

あぁ!! でしたね。でしたね。

つまり、メールヘッダは「手紙を読む側にとって」必要な情報を付け加える、という役割しかない、ということを覚えておきたまえ。

でも博士？ メール出すときにそんな情報を付け加えた記憶はないですよ？

あぁ、メールヘッダは基本的にはMTAやMUAが自動でつけてくれる。
例えばそうだな。OutlookExpressだと、ここで設定した項目をメールヘッダに付け加えてくれるわけだ。

なるほど。自動でつけるわけですね。

■ Received

さきほど、ヘッダフィールドのあるなしは任意だ、と言ったが。
例外が存在する。「Received」だ。

ん〜っと、さっきの説明だと、「メールのトレース情報」だと。

うむ。この項目はMTA・MUAがメールを受信した時点で自動で追加する。
なので、このフィールドをなしにしたくてもできないのだよ。

へぇ、どんな情報なんです？

簡単に言うと、消印だな。
ちなみに、フィールドの値はこうなっている。

ただし、このフィールドの値は標準的なMTAがつける値で、一部省略しても問題ない。

消印？
送信MTA？ 受信MTA？

動作的にはこうなる。

ははぁ、中継するMTAがReceivedフィールドを追加していくんですね。

そうだ。追加していく際に、送信元MTA、受信MTA、宛先、日時などを明記するのだよ。

で、さらにメールサーバがあった場合、Receivedフィールドが上に追加されて増えていく、と。

そういうことだな。つまり、メールヘッダのReceivedフィールドを見ればメールの転送の流れを確認できるというわけだよ。
どうだ、郵便局が受け取った時押す「消印」のようなものだろう？

そうですねぇ、言われてみればその通りかも。
「転送の流れを確認」できるから、メールのトレース情報ってことですね。

うむ。このReceivedフィールドは送信側でつけるものではないので、送信側の設定とは関係なく付け加えられる。
なので、ごまかしの効かないフィールドだといえる。

ごまかしが効かない？

つまり、悪意のあるものがメールを送信したとしても、Receivedフィールドだけはいじれないので、トレースが可能、ということだ。

あぁ、なるほど。他のフィールドは任意に付加するんでしたよね。

そうだ。さらに任意な上に、正確でなくてもいいので嘘が書けるんだが。
Receivedだけはそうはいかない、となるわけだな。

なるほどです。

ま、今回はこんなところだな。

はいな。

とりあえず、SMTPはこのぐらいにしておこう。
次回からは「メールを取りにいく」手段について話そう。

了解です。 ３分間ネットワーキングでした〜♪