安全情報確保支援の勉強中に出てきた「Recievedヘッダ」についての解説です。
ただ、あくまでも試験対策のための暗記メモだと思ってください。
実践に即した技術的な視点ではなく、どう暗記すれば点に結び付きそうかという覚え方をしています。
（ちゃんと応用が利くように勉強するべきだとは思うのですが中々。。。。）
目次
メールについている情報
まずメールはヘッダとエンベロープに分けて考えます。
※ここでは本文（ボディ）部分は無視します。
メールヘッダ
メールヘッダは私たちが良く目にする部分で『誰が誰にいつ送信したか』がわかる部分です。
メールヘッダで覚えておくべきなのは、
私たち（ユーザー）が目にする情報
ということです。
でもこの部分は改ざんが容易らしいので当てにはできません。
エンベロープ
エンベロープがメールヘッダと違うのは、
メールサーバが送信に使う情報
である点です。
送信者情報がのっていたりメールヘッダと似た情報になってくるので一見意味がなさそうですが、実際にメールサーバが使っているのはエンベロープ側の情報です。
つまり、ユーザーが見る必要のない詳細情報までエンベロープにはあると考えられます。
また改ざんなどにより、
『メールヘッダとエンベロープで宛先が異なる場合はエンベロープの宛先に届く』ことになりますね。
なぜならメールサーバはエンベロープを元にメールを送信しているからです。
メールヘッダの情報はあくまでもユーザー向けのお飾り情報です。
Recievedヘッダ
ここで今回のテーマになっているRecievedヘッダです。
Recievedヘッダでは『メールが送られてきた経路』を確認することができます。
経路を確認する必要があるのはメールサーバですね。
つまり、Recievedヘッダはエンベロープ内にある情報になります。
『受信したサーバー』が追加していきます。
Recievedヘッダは読み方にコツがありますので例を挙げます。
田中さんから佐藤さん経由で鈴木さんにメールを送った場合を想定します。
【Recievedヘッダの例】
Recieved:from satou.mail.co.jp (satou.mail.co.jp [80.X.X.X]) by suzuki.mail.co.jp (JST)
Recieved:from tanaka-smtp.mail.co.jp (unknown[80.X.X.X]) by satou.mail.co.jp (UTC) Recieved:from tanaka.mail.co.jp (localhost[127.0.0.1]) by tanaka-smtp.mail.co.jp (JST)
まずは受信の順番を確認
Recievedヘッダは『メールが送られてきた経路』を確認するためのものです。
試験でRecievedヘッダが出てきたら、『誰によるメールなのか』『偽装はされていないか』を問われる可能性が高いです。
そうなるとまずはどういう順番で送られてきたのかを確認するのですが、Recievedヘッダは『経路を上に積み上げていく』仕様になっています。
上述のRecievedヘッダの例であれば、一番下にあるものが『送信者が送ったときの経路』で、一番上にあるものが『受信者が受け取ったときの経路』になります。
時系列で言うと、下に行くほど過去の経路になりますね。
送信者を確認
Recievedヘッダの公式っぽいものを覚えておきましょう。
【Recievedヘッダ公式】
Recieved:from 自称送信者 (確認済送信者 [送信者のIPアドレス]) by 受信者 (タイムゾーン)
とりあえず、fromの所が送信者、byの所が受信者ということは覚えましょう。
ここでまたポイントですが、fromに『自称』とか『確認済』いう文言を付けていますが、これにもちゃんと意味はあります。
『自称送信者』になっている箇所は送信者が自主的に名乗っている名前になります。
つまり詐称可能な名前ということです。
一方、『確認済送信者』の部分については、受信者側（byの後の人）が確認した名前になるので、詐称はできない、つまり信頼できる名前になります。
でも、詐称されていない通常の状態であれば、自称送信者と確認済み送信者の名前は当然一致するはずです。
ここの名前が違っているという事は『送信者がウソをついている』又は『受信者の確認する情報に誤り』があることになります。
その他の確認ポイント
Recieveヘッダの例の２行目が実は詐称してきたときのレコードの例になります。
ここでのポイントは２つです。
unknown
2行目の『確認済送信者』のところが『unknown（わからない）』という表記になっています。
この確認済送信者のところは受信サーバが確認すると説明しましたね。
そこがunknownになっているということは『ドメイン名が取得できなかった』ということです。
なのに送信者は『田中』だと自称しているので、これは田中を装った別人だと考えることができます。
タイムゾーンが１つだけJSTじゃない
タイムゾーンは受信側のサーバがメールを受けとった時間です。
もちろんサーバが海外にあることも想定されるので、一概に怪しいポイントということはできませんが、他の経路が日本(JST)の中、１つの経路だけが海外だった場合は設問で問われる可能性が高いと考えるべきです。
実際にRecivedヘッダを確認する方法
Recievedヘッダの読み方がわかったところで実物を確認しておきましょう。
多くの方が持っているGmailで確認できます。
残念ながらスマホのアプリからでは確認できなかったので、インターネットのGmailを開いてください。
受信メールを開くと右側に「・・・」があります。
これをクリックしてから「メッセージのソースを表示」をクリックすると受信メールの詳細が表示されます。
今回私も始めてみましたが、これがメールの中身か！という感想です。
やっぱり知らないところでパソコンは頑張ってくれていたんですね。
ソース内をRecieveで検索するといくつかひっかかりますが、中にちゃんとRecivedヘッダの公式に当てはまる記述がありました。
『Recieved:from ○○○(○○○[x.x.x.x]) by ▼▼▼』になっており、送信者の表記「自称」と「確認済」が○○○で一致していたので、詐称はされていないようでした。
やっぱり勉強したことが実際に目で確認できると嬉しいですね。
送信ドメイン認証 – SPF認証
Recievedヘッダに関連した用語を紹介しておきます。
SPF(Sender Policy Framework)認証は送信ドメイン認証の１つです。
SPF認証により、ドメイン名を詐称されていても送信者が正規のものか確認がとれます。
『SPFレコード内のIPアドレスとSMTP送信元IPアドレスが一致するか』を確認することで認証します。
メールを受信したサーバがSMTP『MAIL FROMコマンド』で指定されたドメイン（@以降）を基にDNSサーバに問い合わせを行います。
このDNSサーバがSPFレコード(TXTレコード)を返してくれるので、受信サーバはSPFレコードを受け取り、そこに記述のあるIPアドレスを手に入れます。
最後に『受信メール（エンベロープ内）にある送信元のIPアドレス』と『SPFにあるIPアドレス』を比較します。
もし一致していれば正規のIPアドレスからメールが送られていることになるので問題ありませんが、一致していなければドメインを詐称したメールとなります。
上述の『unknown』となっていたのはDNS内にドメインが登録されていないということになり、詐称されたメールであると判断できます。
SMTP：送信側のプロトコル
POP3：受信側のプロトコル
コメント