3 Minutes NetWorking
No.80

3Minutes NetWorking

第80回SMTP(3) メールヘッダ

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

インター博士

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

ネット助手

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

インター博士

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

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

[Figure79-04:エンベロープとメッセージ]

ネット助手

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

インター博士

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

ネット助手

中のメール本文ですね?

インター博士

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

ネット助手

え? 手紙の内容ですよ?

インター博士

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

ネット助手

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

インター博士

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

ネット助手

やっほ〜

インター博士

……。

ネット助手

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

インター博士

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

ネット助手

えへへ。

インター博士

褒めてねぇ

ネット助手

はぅっ。

インター博士

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

手紙

[Figure80-01:手紙]

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

手紙の「前書き」

[Figure80-02:手紙の「前書き」]

ネット助手

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

インター博士

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

ネット助手

めーるへっだ?

インター博士

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

メールメッセージ

[Figure80-03:メールメッセージ]

インター博士

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

ネット助手

ははぁ。

■ 代表的なメールヘッダ

インター博士

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

ヘッダフィールド

[Figure80-04:ヘッダフィールド]

インター博士

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

  • フィールド名:フィールド値<CR><LF>
ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

フィールド名フィールド値役割
Date曜日,日 月 年 時間 +タイムゾーンメッセージ作成日時
From送信者名<メールアドレス>送信者の氏名とメールアドレス
Reply-To返信者メールアドレスメールの返信先メールアドレス
To宛先<メールアドレス>宛先の氏名とメールアドレス
Cc宛先<メールアドレス>カーボンコピー先の氏名とメールアドレス
Message-ID<文字列@ドメイン名>メールを一意に識別するID
Subject文字列メールのタイトル
Received後述メールのトレース情報

[Table80-01:代表的なメールフィールド]

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

え? そうなんですか?

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

2つ目は?

インター博士

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

ネット助手

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

インター博士

どこがだ? 何がまずい?

ネット助手

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

インター博士

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

ネット助手

そうですか、えへへ。

インター博士

褒めてねぇと言っている

ネット助手

はぅぅ。

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

メールヘッダの設定

[Figure80-05:メールヘッダの設定]

ネット助手

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

■ Received

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

  • Received:from 送信MTA by 受信MTA with SMTP/ESMTP for 宛先メールアドレス; 時間<CR><LF>
インター博士

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

ネット助手

消印?
送信MTA? 受信MTA?

インター博士

動作的にはこうなる。

[Figure80-06:Receivedフィールド]

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

ごまかしが効かない?

インター博士

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

ネット助手

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

インター博士

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

ネット助手

なるほどです。

インター博士

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

ネット助手

はいな。

インター博士

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

ネット助手

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

ネット助手ネット君の今日のポイント
  • メール受信者が受け取る情報としてメールヘッダがある
    • メールヘッダはメールメッセージの先頭に記述される。
    • メールヘッダは複数のヘッダフィールドからなる。
    • メールヘッダの情報はメールの転送には影響しない。
  • Receivedフィールドはメールのトレース情報である。
    • メールを受信したMTAは送信MTA、受信MTAなどの情報をReceivedフィールドとして記述する。

3 Minutes NetWorking No.80

管理人:aji-ssz(at)selene.is.dream.jp