迷惑メールとメールヘッダ情報の確認（メッセージのソースの見方）

今回届いた詐欺メール

迷惑メールというか詐欺メールですが、差出人が自分のドメインになっており、「ご覧いただけますように、このメールはあなたご自身のアカウントから送信されています」とか書いてあります。

これまで色々な迷惑メールを見たので慣れたつもりですが、それでも久しぶりにこういったメールが来ると、ちょっとドキッとします。

自分のドメインからの送信になっていますが、ドメインを所有している方の多くはメールアドレスも設定されている場合が多いので、適当なドメインのアカウント宛に送信すれば所有者に届くという具合です。

今回は「sakue@sakue.com」のように「ユーザー名」と「ドメイン」が同じだったので特に届きやすくなっていましたが、よく使われるような「webmaster」「admin」「support」などの推測されやすいユーザー名にしていると迷惑メールや詐欺メールが結構来たりします。

という事で、メールヘッダの読み方についてまとめてみます。

メールソースの確認方法と意味

メールヘッダ/メールソースの確認

メールヘッダはメールソース前半にあるメールの情報を示す各種文字列で、メールソースは生のメール全体です。

Thunderbirdの場合

メール一覧からの場合はメールをクリックして選択状態にし、メニューの「表示」から「メッセージのソース」をクリックします。

ダブルクリックでメールを開いた状態でも同じように「表示」から「メッセージのソース」で開けます。

Gmail（Web版）の場合

ダブルクリックでメールを開き、「・・・」から「メッセージのソースを表示」で確認できます。

From:

「From」は送信者ですが、詐称することもできてしまうので迷惑メールではあまり参考になりません。

From: <sakue@sakue.com>

単にメールアドレスだけが指定されていると以下のようになり、

From: webmaster@sakue.com

送信者の「名前」もセットされていると以下のようになります。

From: "Sakue" <webmaster@sakue.com>

To:

「To:」は宛先ですが、これも迷惑メールでは簡単に詐称できてしまいます。

To: <sakue@sakue.com>

Delivered-To:

メールが転送されたものの場合、転送先が入ります。

「To:」も存在し、「To:」は本来の宛先、「Delivered-To:」は転送後の宛先です。

Delivered-To: sakue@sakue.com

Subject:

メールの題名です。

英語の場合はそのまま記載されますが、日本語の場合は以下のようにエンコードされた文字がセットされます（例は「テスト」という文字の場合です）

Subject: =?UTF-8?B?44OG44K544OI?=

Date:

メーラーでのメール送信日時を示しており、「Received」行の方が信頼性が高いですが、「標準時」や「UTCとの時差」で特徴が出ている事があります。

以前はDateを未来の日付にすることで、常に受信トレイのトップに表示されるというスパムがありましたが、最近ではこういったメールは迷惑メールに分別されるので見なくなりました。

日本の場合はJSTで、UTC+9時間なので以下のようになっています。

Date: Thu, 11 Feb 2021 14:25:27 +0900 (JST)

末尾の（JST）は無い場合がありますが、それ以外の書式は同じみたいですね。

Date: Wed, 27 Jan 2021 11:31:39 +0900

中国の場合は中国標準時でUTC+8時間です。

Date: Sat, 23 Jan 2021 08:54:59 +0800 (CST)

ニンテンドーアカウントからのメールは、メール本文は（JST）と記載されていましたが、ヘッダのDateは協定世界時（UTC）でした。

Date: Sun, 24 Jan 2021 10:29:33 +0000

Received:

Received行は中継したサーバを示すもので、送信サーバが付加していくため複数出現します。

メールヘッダの最下部にあるReceivedが一番最初のもので、上に行くに従って新しく付加された、受取人に近い情報です。

今回の詐欺メールにあった最下部のReceived行が以下です。

Received: from [124.51.132.32] ([124.51.132.32])
    by www2209.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 11IA84Gk025206
    for <sakue@sakue.com>; Thu, 18 Feb 2021 19:08:05 +0900 (JST)
    (envelope-from sakue@sakue.com)

海外からの迷惑メールの場合は、中継するサーバも海外なので中継サーバのホスト名や、標準時（上記だと日本標準時でJST）などに注目すると特徴があったりします。

from XXXX（送信端末/サーバ）

Receivedの「from XXXX」は送った端末もしくはサーバの情報です。

Thunderbirdなどのメーラーから送信した場合は自分のPCのIPが記録され、CGIなどから送信すると実行したサーバのIPが記録されます。

以下の例では「124.51.132.32」から送信されており、このIPをWhoisで検索すると日本国外の端末から送信された事がわかりましたので、海外のPCもしくはサーバから送信されたと判断できます。

from [124.51.132.32] ([124.51.132.32])

cronやCGIなどから送信された場合、最下部Received行のfromは「@localhost」になります。

以下の場合は「sakue」というユーザーの権限で実行された場合ですが、WebサーバのApacheの場合は「apache@localhost」root権限の場合は「root@localhost」のようになります。

(from sakue@localhost)

by XXXX（受信サーバ）

Received行にある「by XXXX」は受け取ったサーバです。

by www2209.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 11IA84Gk025206

CGIから送信した場合は、CGIから送信サーバへ渡されるので「from」が「@localhost」、「by」は送信サーバが記録されます。

Received: (from sakue@localhost)
    by www2209.sakura.ne.jp (8.15.2/8.15.2/Submit) id 064ALp45062451;
    Sat, 4 Jul 2020 19:21:51 +0900 (JST)
    (envelope-from sakue)

標準時

以下の例では末尾に (JST) とあるので日本標準時です。

例えば中国の場合は (CST) になってたりしますが、最近のスパムは結構かしこいのでJSTになってるものが多いです。

Sat, 4 Jul 2020 19:21:51 +0900 (JST)

メーラーから送信した場合

Thunderbirdから送信場合の最初のReceived行付近です。

メーラーからの送信では最初のReceivedに送信者のIPが記録されているのがわかります。

Received: from www2209.sakura.ne.jp (182.48.49.149)
    by fsav109.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav109.sakura.ne.jp);
    Fri, 19 Feb 2021 15:59:53 +0900 (JST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav109.sakura.ne.jp)
Received: from [192.168.2.2] (ntaich025221.aich.nt.ngn.ppp.infoweb.ne.jp [175.129.5.220])
    (authenticated bits=0)
    by www2209.sakura.ne.jp (8.15.2/8.15.2) with ESMTPA id 11J6xcGo072234
    for <test@sakue.com>; Fri, 19 Feb 2021 15:59:53 +0900 (JST)
    (envelope-from webmaster@sakue.com)

「192.168.2.2」というのはLANのプライベートIPで、その後のカッコ内がグローバルIPとホスト名です。

from [192.168.2.2] (ntaich025221.aich.nt.ngn.ppp.infoweb.ne.jp [175.129.5.220])

CGIなどから送信された場合

CGIなどからの送信ではReceivedの最初のfromは「@localhost」になっていますが、サーバの設定によってはサーバのホスト名が表示されます。

実際にCGIから送信されたメールの最初2つのReceived行抜粋です。

「from」が「@localhost」で、「by」が「www2209.sakura.ne.jp」なので、同サーバのMTAにメールが渡されたという意味です。

ブラウザで操作できるWebメールや、Linuxのmailコマンドで送信した場合も同様です。

「差出人」が自分のドメインで、最初の「Received」が「@localhost」、サーバのIPなども一致している場合の迷惑メールは設置しているスクリプトの穴を突かれている可能性があるのでチェックした方が良いです。

Received: from www2209.sakura.ne.jp (localhost [127.0.0.1])
    by www2209.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 064ALpSc062452
    for <webmaster@sakue.com>; Sat, 4 Jul 2020 19:21:51 +0900 (JST)
    (envelope-from sakue@www2209.sakura.ne.jp)
Received: (from sakue@localhost)
    by www2209.sakura.ne.jp (8.15.2/8.15.2/Submit) id 064ALp45062451;
    Sat, 4 Jul 2020 19:21:51 +0900 (JST)
    (envelope-from sakue)

Return-Path:

メール中継などでエラーがあった時の戻り先です。

Return-Path: <sakue@sakue.com>

Reply-To:

返信先です。

メーラーで「返信」ボタンを押したときに「宛先」にセットされる送信先になります。
設定されていない場合は「差出人」が「宛先」にセットされます。

Thunderbirdだとメールのアカウント設定に「返信先（Reply-to）」という項目があり、指定しておくとこのヘッダが出ます。

User-Agent:

ユーザーエージェントはOS名やブラウザ名などが確認できます。

今回来たスパムメールではユーザーエージェントが「Windows NT 5.1」となっており、「Windows XP」を示すものですが、2021年にXPから送信っていうのは踏み台になってしまってるPCからなんでしょうか？

言語も「en-US」になっているのと、Thunderbirdは2021年2月時点でバージョンが78.7.1なので、3.0.3っていうのも古いです。

このヘッダは偽装も可能なので本当に合ってるのかは不明ですが。

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100408 Thunderbird/3.0.3

WindowsPCのユーザーエージェントに含まれる文字列は以下のとおりです。

添付ファイル

メールの添付ファイルも文字列に変換されてメールソース内に存在します。

以下の例では「base64」でエンコードされているので、同じくbase64でデコードすると元のファイルが取り出せます。

Content-Type: application/octet-stream;
name="=?UTF-8?B?44OG44K544OILjd6?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*=UTF-8''%E3%83%86%E3%82%B9%E3%83%88%2E%37%7A

N3q8ryccAAQiEg/2CAAAAAAAAABaAAAAAAAAAK1Tej8BAANURVNUAAEEBgABCQgABwsBAAEh
IQEADAQACAoBuJPq7gAABQEZDAAAAAAAAAAAAAAAABERAMYwuTDIMC4AdAB4AHQAAAAZAgAA
FAoBAGaXRfBiBtcBFQYBACAgAAAAAA==

「filename=」は「URLエンコード」された「添付ファイル名」で、以下の「%E3%83%86%E3%82%B9%E3%83%88%2E%37%7A」をデコードすると「テスト.7z」になります。

filename*=UTF-8''%E3%83%86%E3%82%B9%E3%83%88%2E%37%7A

以下の行は「base64」でエンコードしましたよという意味です。

Content-Transfer-Encoding: base64

最後の以下の文字列が添付ファイルそのものです。

「base64」で「エンコード」されているので、同じくbase64で「デコード」すると元のファイルになります。

以下のをデコードすると「.7z」で圧縮された「テスト.txt」になります。

この文字列だけでは元のファイルが何なのか不明なので、「filename=」の行を見てデコード後にファイル名を戻してやる必要があります。

N3q8ryccAAQiEg/2CAAAAAAAAABaAAAAAAAAAK1Tej8BAANURVNUAAEEBgABCQgABwsBAAEh
IQEADAQACAoBuJPq7gAABQEZDAAAAAAAAAAAAAAAABERAMYwuTDIMC4AdAB4AHQAAAAZAgAA
FAoBAGaXRfBiBtcBFQYBACAgAAAAAA==

Content-Type:

メールの形式を示します。
完全な英語メールの場合は出力されない場合があります。

マルチパートの場合は複数のContent-Type:行がありますが、その直下の行のコンテンツタイプを示しています。

text/plain

テキストメールの場合

Content-Type: text/plain;

text/html

HTMLメールの場合

Content-Type: text/html;

テキストやHTMLを組み合わせたマルチパートの場合、メール本文より上に全体を示すContent-Type:行があります。

multipart/mixed

一般的なマルチパートでテキストに画像を添付した場合など。
alternativeのような構成にもできる。

multipart/alternative

テキストとHTMLを組み合わせたもので、HTML優先なもののテキストでも読めます。

multipart/parallel

含まれるパートを同時に表示するような場合（音声と画像など）

multipart/digest

ニュースやメールを複数含める場合で、例えばメーリングリストで複数メールをまとめて送る時などです。

charset=

Content-Typeに続けて文字コードが指定されます。

以前は国ごとに文字コードがバラバラだったので判断基準の1つに使えましたが、Unicodeが広がってからは大抵utf-8になったので推測できなくなりました。

Content-Type: text/plain; charset=utf-8;

ラテン文字のLatin-1の例ですが、こういった例ならある程度推測できます。

Content-Type: text/plain; charset="iso-8859-1"

Content-Language:

マルチパートのメールで出ている事があります。

Content-Language: en-US

Content-Transfer-Encoding:

これも完全な英文メールの場合は出力されない場合があります。

Content-Transfer-Encoding: 8bit

「8bit」はUnicodeなどの日本語も表示できる文字コードですが、Thunderbirdなどでソースを見ると文字化けすることがあります。

この場合は「表示」から「テキストエンコーディング」を「Unicode」にすると正しく表示されます。

「Content-Transfer-Encoding」行のあたりに「charset=”utf-8″」などと文字コードが指定されていますので、これに合わせればOKです（utf-8はUnicodeです）

Message-ID:

Message-IDはメール1通ごとに異なる文字列が付与されます。

「送信トレイ」に残る送信済みメールと、受信したメールのMessage-IDが同じであれば、自分が送信した同一のメールという判断ができます。

Message-ID: <4c24b614-7c4a-46f2-e7f3-732e969fec64@mbr.nifty.com>

References:

返信したメールで親のMessage-ID（メール1通ごとに異なるID）が付きます。

Message-IDは1通ごとに異なるため、お互いに返信を繰り返すと以下のようにReferencesに格納されるMessage-IDが増えていきます。

References: <ca584589-5059-da61-3fb8-39e3ee6d3485@example.com>
<6f545e83-2172-c09e-2d13-932961d7e2f2@sakue.com>
<ebb3ea18-4a81-2cab-7eaa-4e2c2dd1f2d4@example.com>
<c5070d42-b03b-a4bf-2572-e13d229bb41c@sakue.com>

Received-SPF:

送信元ドメインが正当なIPのサーバからかの判定です。

SPFレコードはDNSサーバ側で設定する項目ですが、ドメインとレンタルサーバが同じ提供元の場合は簡単に設定できます（さくらインターネットなど）

pass

全く問題なしのメール。

Received-SPF: pass (google.com: domain of webmaster@sakue.com designates 100.100.100.100 as permitted sender) client-ip=100.100.100.100;

neutral

SPFレコードが設定されていないと、これになったりします。

Received-SPF: neutral (google.com: 100.100.100.100 is neither permitted nor denied by best guess record for domain of sakue@www2205.sakura.ne.jp) client-ip=100.100.100.100;

softfail

fromにレンタルサーバのドメインと異なるドメインのメールアドレスを設定して送信した場合にこうなりました。

Received-SPF: softfail (google.com: domain of transitioning sakue@mbr.nifty.com does not designate 100.100.100.100 as permitted sender) client-ip=100.100.100.100;

fail

failは詐称されているという判定ですが、普通は意図的に詐称することは無いので設定ミスですね。

Received-SPF: fail (google.com: domain of webmaster@sakue.com does not designate 100.100.100.100 as permitted sender) client-ip=100.100.100.100;

X-から始まるヘッダ（X-Mailerなど）

X-から始まるものは標準的なヘッダでなく後から拡張されたもので、自分で好きなものを埋め込めます。

X-Authentication-Warning:

メールサーバの設定で「Trusted users」に含まれていないユーザーから送信すると出ますが、「trusted-users」に追加すればでなくなります。

X-Authentication-Warning: www2209.sakura.ne.jp: sakue set sender to sakue@sakue.com using -f

実際の /etc/mail/trusted-users です。

先頭に「T」をつけて記述するので「apache」を追加する場合は「Tapache」のように追記します。

# trusted-users - users that can send mail as others without a warning
# apache, mailman, majordomo, uucp, are good candidates
Ft/etc/mail/trusted-users
Troot
Tdaemon
Tuucp
Tapache

X-Mailer:

送信メーラーとバージョンなどです。

X-Mailer: Microsoft Windows Live Mail 15.4.3538.513

WordPressからの通知メールは以下のようになっていました。

X-Mailer: PHPMailer 6.2.0 (https://github.com/PHPMailer/PHPMailer)

X-Priority:

メールの重要度を示すもので、対応メーラーだと重要度によって表示方法が変わったりします（バッジ表示とか）

X-MSMail-Priority:

マイクロソフト製のメーラーで付く場合がある重要度を示すヘッダです。

Importance:

これも重要度で High/Normal/Low があります。

X-MimeOLE:

OLEとは何かの機能を持ったWindowsライブラリで、古くはActiveXなどがあります。

X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513

X-Nifty-SrcIP

プロバイダの@niftyの場合に送信元が記録されます。

その他

メールの送信履歴

レンタルサーバの場合

レンタルサーバなどによってはメールの送信履歴が確認できます。

さくらインターネットの場合は「コントロールパネル」の「メール」から「送信メール」とたどります。

「外部」へのメール送信履歴が確認できます。

ぼかしてありますが、「宛先」には送信先のメールアドレスが表示されます。

VPSや自前のサーバの場合

/var/log/maillog を確認します。

送信数が多い場合はログも結構な量になりますが、メールの送信処理は一瞬で終わるため、ほぼ同じ時刻で固まっているのでだいたい分かると思います。

Feb 20 09:40:04 sakue postfix/qmgr[2068]: 21BBF20697552: from=<sakue@mbr.nifty.com>, size=4702, nrcpt=1 (queue active)
Feb 20 09:40:04 sakue postfix/smtp[19806]: 21BBF20697552: to=<sakue@example.com>, relay=mbr.nifty.com[210.130.2.16]:587, delay=0.35, delays=0/0/0.14/0.2, dsn=2.0.0, status=sent (250 2.0.0 11K0e48t027999 Message accepted for delivery)

Thunderbird上のメールをヘッダで検索する

Thunderbirdのメッセージ検索は件名や差出人以外に、ヘッダの文字列を指定した「カスタムヘッダー」での検索ができます。

定義しておけば、次回以降はプルダウンから選択するだけで検索できます。

Thunderbirdのメニューから「編集」「検索」「メッセージを検索」と辿り、メッセージ検索ウィンドウを表示します。

ショートカットで開く場合は「Ctrl + Shift + F」です。

検索条件のプルダウンメニューをクリックし、最下部の「カスタムヘッダー」をクリックします。

既にいくつか登録されていますが、SPFレコードによる判定の「Received-SPF:」を追加してみます。

メールのソースから「Received-SPF」の文字をコピーして貼り付け、「追加ボタン」をクリックします。

ここでの指定は「Received-SPF:」の末尾の「:」はつけません（追加時にエラーになります）

「Received-SPF」がプルダウンから選択できるようになりました。

試しに「Received-SPF」が「fail」になっているメールを検索してみます。

「Received-SPF」は「fail」の文字列を含む「softfail」の場合もあるので「が次で始まる」で検索します。

それ以外のヘッダは「に次を含む」で検索すればだいたいOKです。

ヘッダの値は色々な文字列で構成されているため、「が次と一致する」や「が次で終わる」ではヒットしない事が多いです。

このため、実際のメールソースのヘッダの値を見て、うまくヒットするように検索方法を変えると良いですね。