メールヘッダーアナライザー

概要

メッセージを扱ったすべてのメールサーバーは、自分の Received ヘッダを先頭に 足します。順に読めばそれが配送経路で、どのホストがどのホストに渡し、それが いつだったかが分かります。認証結果と併せて読めば、そのメッセージが本当に 主張どおりの場所から来たのかが分かります。

このツールはヘッダの折り返しを結合し、経路をホップごとの遅延付きの番号付き 一覧として組み立て、認証ヘッダを別に取り出します。ノイズの中から自分で 探す必要がありません。

使い方

1. メールクライアントでメッセージの原文（生ソース）を開きます。Gmail なら メッセージのソースを表示、Outlook なら プロパティ → インターネット ヘッダー、Apple Mail なら 表示 → メッセージ → 生のソース です。
2. メッセージの先頭から最初の空行までを貼ります。本文は不要です。
3. ホップ一覧を上から下へ読みます。ホップ 1 が発信元です。
4. その下の認証結果を読みます。

ホップ一覧の読み方

各行は送信ホスト（from）・受信ホスト（by）・前のホップからの遅延を表示します。 通常の配送は 2〜5 ホップで、全体が数秒で完了します。

向きが重要です。中継は末尾ではなく先頭に足すので生ヘッダは新しい順に並びます。 ここでの一覧はメッセージが通った向きに読めるよう反転しています。生ソースと 見比べるときは、両者が上下逆であることを覚えておいてください。

遅延は各 Received ヘッダの日時から計算しており、それらは独立に設定された時計を 持つ別々の機械が書いたものです。1〜2 秒の食い違い（負値を含む）はずれであって 何かの証拠ではありません。分や時間の単位の空きは実在するもので、ほぼ常に 受信サーバーがメッセージをキューに入れたという意味です。初回の送信者を意図的に 遅延させるグレイリスティングが、最も一般的な原因です。

認証結果の読み方

重要なヘッダは 4 つで、それぞれ別の問いに答えます。

• Received-SPF — 接続してきた IP は、封筒の送信者のドメインとして送信を 許可されていたか。SPF は封筒（MAIL FROM）を検査するもので、受信者が目にする From: ヘッダとは別です。SPF を通過しながら偽の送信者を表示することは できます。
• DKIM-Signature — 選択したヘッダと本文に対する暗号署名で、署名ドメインの DNS にある公開鍵で検証できます。d= が署名ドメイン、s= がセレクタで、 両者を合わせると鍵の場所が <selector>._domainkey.<domain> に決まります。
• Authentication-Results — 受信サーバー自身の判定で、SPF・DKIM・DMARC を まとめたものです。最初に読むべき行です。連鎖の中で、信用する理由がある唯一の 機械が書いたものだからです。
• ARC-Authentication-Results — 中継者がメッセージを改変する前に記録した 判定です。メーリングリストは仕様上ヘッダを書き換えて DKIM を壊すので、 元の結果を生き残らせるために ARC があります。

受信側が実際に何をするかを決めるのは DMARC です。DMARC は SPF か DKIM の通過に 加えてアライメントを要求します。通過したドメインが、表示される From: ヘッダのドメインと一致していなければなりません。spf=pass と dkim=pass が 出ていながら DMARC が失敗し得るのはこのためです。どちらも通過していますが、 違うドメインで通過しているのです。

使用例

• 「自社のメールが迷惑メールに入る」 — 別の事業者の自分宛に送ったメッセージの Authentication-Results を読みます。DKIM が通過して DMARC が失敗しているなら、 問題は署名ではなくアライメントです。
• 説得力のあるフィッシング — ホップ 1 の from を、表示される From: ヘッダの ドメインと比べます。表示名の偽造は容易ですが、主張するドメインの実インフラと 一致する第 1 ホップの偽造は容易ではありません。
• 配送に 20 分かかる — 遅延の大きいホップを探します。受信側の最初の インバウンドサーバーなら、グレイリスティングが有力で、再送で自然に解決します。
• DNS 変更後にメールが届かなくなった — 結果の SPF を確認します。1 つの ドメインに SPF レコードが 2 つある、あるいは 10 回のルックアップ上限を超えて いる場合、どちらも恒久的な失敗になり、原因不明の障害のように見えます。
• メーリングリストが署名を壊す — ARC ヘッダを探します。存在していれば、 中継者がメッセージを改変し、以前の判定を記録したという意味です。

注意事項

解析の前に折り返しを結合します。長いヘッダは先頭に空白を置いた複数行に 折り返されており、それを結合せずに行単位で読むパーサは、最も重要なヘッダを まさに途中で切ってしまいます。

from と by の値は節の先頭からのみ読み取ります。from 節を持たない Received ヘッダでも、コメント内に envelope-from という文字列を含むことが よくあり、それを接続元ホストとして扱うと、攻撃者が入れたアドレスを メッセージの発信元として表示してしまいます。ここで確認しようとしている、 まさにその事実についてです。

ここに書かれるのはすべて「ヘッダが何と言っているか」です。自分が管理する最初の 機械より前に書かれたヘッダは丸ごと偽造できるので、連鎖は自社インフラについては 証拠であり、それより上流についてはすべて主張です。

ヘッダではなく保存されたメッセージ自体を調べるなら、 EML ビューア を使ってください。