VPN経由で送ったメール：返信は実際どこへ届くのか

トンネルを通してメッセージを送り、切断し、翌朝には返信が届く。そのために古いVPNアドレスが必要になることはなく、壊れるものもない。メールは返信を「送信元アドレス」へ届けるのではなく、メールボックスへ届ける。ここでは三つの経路が一つの疑問に混ぜられているが、切り分ければ不安の大半は解ける。

人が一つに混ぜてしまう三つの経路

送信、配送、閲覧は三つの別々の接続であり、そのうち自分の端末が関わるのは二つだけだ。

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

VPNが影響しうるのは一つ目と三つ目で、どちらも自分の端末が張る接続だからだ。二つ目には影響できない。その経路は自分が管理していない二つのメールサーバーの間を流れるからだ。返信は、送信元アドレスへ戻ってくるパケットではない。相手側のメールサービスが自分のメールボックスサービスへ配送する、新しいメッセージである。

この三つを切り分けておけば、「返信は自分に届くのか」という疑問は謎ではなくなる。

Reply-To は経路ではなくアドレスだ

RFC 5322 は Reply-To を、返信を送るべきメールボックス（複数の場合もある）と定義している。これがなければ通常の既定値は From のメールボックスで、返信する人が別のものを打ち込めばそれに従う。どちらもヘッダーに書かれたメールアドレスにすぎない。どちらも、元のメッセージを送信したネットワーク接続を開き直せという指示ではない。

だからVPNの出口アドレスが返信の経路に現れることはない。送信サーバーがその出口アドレスをどこかに記録していたとしても、返信の宛先はメールボックスであり、送信側サーバーは古いソケットではなくドメインのメール交換サーバーを引く。

返信が思いがけない場所へ行ったなら、トンネルを疑う前に Reply-To と送信者自身のクライアント設定を読んでほしい。

トレースヘッダーが実際に記録しているもの

SMTP の各ホップは、扱った接続を説明する Received ヘッダーを先頭に追加し、いちばん上が配送前の最後のホップになる。したがって送信したメッセージには、確認する価値のあるネットワーク情報が載りうる。そしてその情報を書くのはサーバーであり、自分が選んだものではない。何が載るかはプロバイダーの送信アーキテクチャとヘッダーの扱い方によって変わる。

推測せずに、保存したメッセージから読むこと：

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

役に立つ習慣は、どの項目をどの信頼できるサービスが追加したのかを特定することだ。ヘッダーブロックの前方にある任意のテキストは信頼できる証拠ではなく、製品名は「自宅のアドレスが常にある／常にない」という永久の約束でもない。

後からメールを読むのは新しい接続

返信を開くとき、クライアントは今いるネットワーク越しにメールボックスサービスへ接続する。これは独自の送信元アドレスを持つ新しい接続であり、昨日の送信用ソケットの続きではない。その時点で使っているネットワークの現在のポリシーに従う。

リモートコンテンツはさらに別の問題だ。遠隔の画像を読み込んだりリンクをたどったりするメールクライアントは、その時点の設定のもとで別のリクエストを出し、そのリクエストにはメッセージが埋め込んだ識別子が載りうる。それは古いアドレスに届く SMTP の返信ではなく、そう扱うと本当の露出が見えなくなる。

開いたことを知らせずに読みたいなら、リモートコンテンツを切っておく。

漏えいと言う前に確認すること

まず元のメッセージの表示と Reply-To を見る。次に、気になる Received の項目をどのサービスが追加したのかを特定し、古いフォーラムの回答ではなくプロバイダーの現在の文書と突き合わせる。

最後に、問いを分ける。送信サーバーは何を観測したのか、配送の連鎖は何を追加したのか、そしてメッセージを開いたとき自分のクライアントは何を要求したのか。

この三つを別々に答えるのは、IP のページを確認するより手間がかかる。だが、自分で説明できる結論が出るのはそのやり方だけだ。メールアドレスに返信しても自宅のアドレスは明かされず、古いトンネルを開けたままにする必要もない。