メールヘッダ情報の読み方

迷惑メールや嫌がらせメールの送信元を調べる際に重要なのは、Fromのメールアドレスではなく、ヘッダ情報である。ヘッダ情報の読み方を説明しよう。

ヘッダ情報に書かれている内容

Return-Path: <Aさんのメールアドレス>
Received: from rcpt-impgw.biglobe.ne.jp by biglobe.ne.jp (RCPT_GW); Tue, 14 Jun 2016 15:16:53 +0900 (JST)
Received: example2.ne.jp by rcpt-impgw.biglobe.ne.jp (shby/1714221009) with SMTP ; Tue, 14 Jun 2016 15:16:51 +0900
Authentication-Results: ***; spf=pass smtp.mailfrom=****; dkim=none
Received: from example1.ne.jp by example2.ne.jp ; Tue, 14 Jun 2016 15:16:38 JST
Received: from [203.0.113.1] by example1.ne.jp ; Tue, 14 Jun 2016 15:16:37 JST
Message-ID: <*****>
Date: Tue, 14 Jun 2016 15:16:37 +0900 (JST)
From: Aさん
To: Bさん
Subject: こんにちは
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
X-Mailer: Microsoft Windows Live Mail ***
X-Biglobe-VirusCheck: Tue, 14 Jun 2016 15:16:40 +0900 (JST)
X-Brightmail-Tracker: *****
X-Biglobe-spamcheck: 0.00%

 

項目の意味は下記参照。

From 差出人のメールアドレス。迷惑メールの場合、大半が詐称されている。
To 宛先
Date 相手が送信した日時
Return-Path エラーメールの返信先。From同様、詐称することが可能。
また、Return-Pathを「迷惑メールブロックサービス」の「受信拒否設定」に登録しても拒否されない。
Received メールが届くまでの経路。Receivedの数は、経由したサーバの数によって変わる。
Authentication-Results 送信ドメイン認証の結果。

 

また、以下のように「X-」で始まる項目は、メール送信者やサーバ側で任意に設定できる。そのため、使用しているメールソフトやメール関連サービスによって、記載されている項目名が異る。

X-Mailer 相手が使っているメールソフトの種類
X-Biglobe-VirusCheck 「メールウイルスチェックプラス」でウイルスチェックされた場合に付加される。
X-Brightmail-Tracker
X-Biglobe-spamcheck
「迷惑メールブロックサービス」の迷惑メール判定エンジンで、判定が行われた場合に付加される。

 

ヘッダ情報の「Received」から、メールの送信元を探す

Received: from ×× by ○○

これは「××」と言うサーバーから送信されたメールを〇〇と言うサーバーが受信した、と言う意味になる。

また、Receivedは下から順に読むので3つあれば、経路は3⇒2⇒1の順とたどる事が出来る。

これを、先に例として挙げた「こんにちは」という件名のメールで考えてみよう。

  1. Received: from rcpt-impgw.biglobe.ne.jp by biglobe.ne.jp (RCPT_GW); Tue, 14 Jun 2016 15:16:53 +0900 (JST)
  2. Received: example2.ne.jp by rcpt-impgw.biglobe.ne.jp (shby/1714221009) with SMTP ; Tue, 14 Jun 2016 15:16:51 +0900
  3. Received: from example1.ne.jp by example2.ne.jp ; Tue, 14 Jun 2016 15:16:38 JST
  4. Received: from [203.0.113.1] by example1.ne.jp ; Tue, 14 Jun 2016 15:16:37 JST

「こんにちは」という件名のメールのReceivedだけを抜き出して、下から番号をつけてみた。
書かれている内容を翻訳して、時系列で並べ替えると..

  1. [203.0.113.1]から送信されたメールをexample1.ne.jpがTue, 14 Jun 2016 15:16:37 JSTに受信した
  2. example1.ne.jpから送信されたメールをexample2.ne.jpがTue, 14 Jun 2016 15:16:38 JSTに受信した
  3. example2.ne.jp から送信されたメールをBIGLOBEのサーバがTue, 14 Jun 2016 15:16:51 +0900に受信した
  4. BIGLOBEのサーバで受信したメールが、BIGLOBE内の別のサーバへTue, 14 Jun 2016 15:16:53 +0900 (JST)に送信された

それぞれのReceivedをたどっていくと、「こんにちは」というメールは、[203.0.113.1]から送信された後に、example1.ne.jpやexample2.ne.jpを経由してBIGLOBEのメールサーバまで届いたことがわかる。

送信元が偽造されている場合

迷惑メールのヘッダ情報は、送信元の特定を困難にするために一部が偽装されていることも少ない。
例えば、以下のような場合。

  1. Received: from rcpt-impgw.biglobe.ne.jp by biglobe.ne.jp (RCPT_GW); Tue, 14 Jun 2016 15:16:53 +0900 (JST)
  2. Received: from example1.ne.jp(example3.ne.jp[192.0.2.2]) by rcpt-impgw.biglobe.ne.jp (shby/1714221009) with SMTP ; Tue, 14 Jun 2016 15:16:51 +0900
  3. Received: from [203.0.113.1] by example1.ne.jp ; Tue, 14 Jun 2016 15:16:37 JST

2でBIGLOBEのサーバへメールが届いたが、送信元がかっこの外側と内側とで違っている。こんなときはどう読めばよいのだろう。

括弧の外側は、迷惑メールを送信する側で好きなように設定できる=偽装することができる部分である。
逆に、括弧の内側は「メールを受信したサーバが調べた送信元」なので、送信する側で偽装することができない。

これを踏まえて、Receivedを時系列で並び替え、内容を翻訳して詳しく見てみると..

  1. [203.0.113.1]から送信されたメールをexample1.ne.jpがTue, 14 Jun 2016 15:16:37 JSTに受信した
  2. 「example1.ne.jp」と名乗ったexample3.ne.jp[192.0.2.2]から送信されたメールを、BIGLOBEのサーバがTue, 14 Jun 2016 15:16:51 +0900に受信した
  3. BIGLOBEのサーバで受信したメールが、BIGLOBE内の別のサーバへTue, 14 Jun 2016 15:16:53 +0900 (JST)に送信された

3は、BIGLOBEのサーバ同士でのやりとりなので、迷惑メールとは関係ない。
問題は2のような、「外部から自分のプロバイダへ送信された」際の記録。
送信した側は「example1.ne.jp」と名乗っているが、受信した側が調べた送信元は「example3.ne.jp[192.0.2.2]」なので、送信元は偽装されていたことになる。
また、「example1.ne.jp」という名前が偽装されたものであれば、「[203.0.113.1]からのメールをexample1.ne.jpが受信した」と言っている1も怪しいということになる。

この時点で、信頼性の高い情報は、「example3.ne.jp[192.0.2.2]からBIGLOBEのサーバへメールが送信された」の部分だけなので、送信元は「example3.ne.jp[192.0.2.2]」と考えて良い。

迷惑メールのFromは気にしなくてよい

メールの送信元はヘッダ情報から調べる。
ご存知の方も多いと思いますが、迷惑メールのFromは詐称されていることがほとんどなので、Fromに記載されたメールアドレスだけでは判断できない。

大半はfromが詐称されているだけで、メールアドレスが不正に使われているケースはごく稀である。