EMLメールビューアー
EMLメールファイルの内容を表示・解析します。
概要
.eml ファイルは、メッセージが流通したときの形式そのままで保存されたものです。
ヘッダ、空行、本文。メールクライアントはその大半を隠しますが、メッセージが
実際に何を含んでいたか（クライアントが表示しないヘッダ、文字化けして届いた件名、
おかしく描画されるメッセージの構造）を知る必要が出たときには足りません。
このビューアはヘッダ境界でファイルを分割し、ヘッダの折り返しを結合し、 MIME の encoded-word を宣言された文字セットで復号して、主要な項目と生の本文の 両方を表示します。
使い方
- メッセージを
.emlとして保存するか、生ソースをコピーします。Thunderbird なら メッセージをデスクトップへドラッグ、Apple Mail なら 表示 → メッセージ → 生のソース、Outlook なら 名前を付けて保存 です。 - 中身を貼ります。ヘッダ、空行、本文。これが形式のすべてです。
- 要約項目を読み、続いて生の本文で構造を確認します。
encoded-word と、件名が壊れて届く理由
ヘッダは仕様上 ASCII のみです。非 ASCII のテキストは encoded-word として運ばれます。
=?文字セット?エンコード?データ?= の形で、エンコードは base64 なら B、
quoted-printable の変種なら Q です。
真ん中の文字セットが重要で、多くのツールが間違えるのはここです。日本語の件名は
今も日常的に ISO-2022-JP で送られます。Unicode より古いエスケープシーケンス方式の
エンコードで、いくつかのメールクライアントでは今も既定です。西欧のメールは
ISO-8859-1 や windows-1252 を使い続けています。UTF-8 だと決めつけた復号は
それらすべてを文字化けにし、その結果は「復号の間違い」ではなく「壊れたファイル」に
見えます。
このビューアは宣言された文字セットを読んでそれに従って復号するので、
=?ISO-2022-JP?B?…?= は読める日本語になり、=?windows-1252?Q?it=92s?= は
正しい約物のアポストロフィを持つ it's になります。未知の、あるいは綴りを
誤った文字セットは、失敗するのではなく UTF-8 として扱います。
ヘッダの折り返し
長いヘッダは複数行に分割され、継続行は空白で始まります。Received ヘッダや
アドレスが 20 個並ぶ To は、ファイル内では何行にもわたり、その折り返しに
意味はありません。転送の規則であって値の一部ではないのです。
解析の前に折り返しは結合するので、折り返された値は 1 つの文字列として読まれます。
生のテキストを自分で読むときに知っておく価値のある点です。ヘッダの値を grep
すると、たまたま折り返された箇所を取りこぼします。
本文の表示について
本文はファイル内の見た目のまま表示します。これは意図的です。
実際のメッセージはほとんどが multipart/alternative（同じ内容のプレーンテキスト版と
HTML 版）か multipart/mixed（本文と添付）です。各パートは自分の
Content-Type・文字セット・Content-Transfer-Encoding を持ち、パートは
最上位ヘッダで宣言された境界文字列で区切られます。
復号した 1 つのパートを「メッセージ本体」として見せると、その構造が隠れます。 そして通常、見に来た理由はその構造です。クライアントがどのパートを描画して いるのか、プレーンテキスト版が HTML 版と一致しているのか、添付が期待した場所に あるのか。だから生の本文は生のままにしています。
その結果、quoted-printable の本文では = が =3D として、ソフト改行が行末の
= として見え、base64 のパートは base64 のまま見えます。どれかを復号したい
場合は、そのパートをコピーして Base64 デコード または
URL エンコード / デコード にかけてください。
クライアントが見せないヘッダ
要約には通常必要な 7 項目を並べます。貼ったテキストには残りが入っており、 その中のいくつかはクライアントが隠している問いに答えます。
Return-Pathは封筒の送信者、つまりバウンスの宛先です。送信サーバーが 設定するもので、人が目にするFrom:ヘッダとは異なることが頻繁にあります。 SPF が通過して DMARC が失敗するとき、この不一致が原因です。List-UnsubscribeとList-Unsubscribe-Postは、Gmail でワンクリックの 配信停止ボタンを出させるものです。これを持たない大量配信は、迷惑メール判定を 受けやすくなります。Auto-Submittedは機械生成のメールを示します。自動メッセージでこれが無いと、 不在通知の応答やメールループを引き起こします。In-Reply-ToとReferencesは、クライアントがスレッドを組み立てる 手掛かりです。返信が新しい会話として現れるなら、どちらかが欠けています。Content-Languageは、多言語の送信元がどの版を選んだかを説明します。X-*ヘッダ は送信インフラが付けたものです。スパムスコア・キャンペーン ID・ 内部のキュー名などが出てきて、どのシステムが実際に送ったかを特定する最短の 手掛かりになります。
使用例
- 件名が意味不明の文字列で届く — ここにメッセージを貼ります。件名が読めるなら 送信側は正常で、受信側のクライアントが文字セットを誤って扱っています。
- 「Outlook では表示が違う」 — 境界の構造を見ます。
multipart/alternativeの 2 つのパートが食い違っている、で説明がつく報告がほとんどです。 - ヘッダが見つからない — クライアントは一部だけを選んで表示します。
List-Unsubscribe・Auto-Submitted・X-Failed-Recipientsなどは、何も 表示されていないときでもファイルには入っています。 - 自分が実際に何を送ったかの確認 — 送信済みフォルダのメッセージを保存して 読み返します。エンコードの意外な挙動は、生の形の方がはるかに見つけやすいです。
注意事項
ヘッダと本文の境界は、形式どおり最初の空行です。空行が 1 つも無いファイルは ヘッダのみとして扱います。ヘッダブロックだけを貼られたときに望ましい挙動です。
ここでは何も検証しません。Date が不正な、Message-ID が無い、本文に一度も
現れない境界を宣言している .eml も、そのまま表示します。「そうあるべきだった
もの」ではなく「そのファイルが何を含んでいるか」を見るのが目的だからです。
配送経路・ホップごとの遅延・SPF / DKIM / DMARC の判定は、 メールヘッダ解析 を使ってください。同じヘッダを別の問いで読みます。