エンベロープFromとは｜ネットミリしら

エンベロープFromとは

エンベロープFromは、SMTP配送で実際の返送先として使う差出人情報で、表示上のFromとは異なる場合があります。SMTPのMAIL FROM命令で渡すreverse-path（リバース・パス／逆経路）を指す通称です。

紙の手紙にたとえると、メッセージ本文に印刷された差出人ではなく、配送用封筒の外側にある「配達できなかったときの返送先」です。通常のメールアプリはこの値を大きく表示しません。

エンベロープFromはエラー返送とSPF認証に使われます。受信者が見るヘッダーFrom、返信ボタンのReply-To、実際の投稿利用者とは別の役割です。

SMTP命令、受信側の記録、エラー通知、最終配送後のヘッダーという別の場所に現れる値をつなぐ同じ文字列に見えても、配送中の状態と保存後の記録を区別する

図2Return-Pathは受信後に見える記録です。送信者がメッセージ内へ自由に書いた既存値を、そのまま信頼するものではありません。

SMTPクライアントはMAIL FROMで逆方向経路を設定し、続くRCPT TOで一人以上の配送先を指定します。この二つはメッセージ本文のFrom・To・Ccとは独立した配送用封筒です。

Bccが本文のTo・Ccへ現れなくても配送できるのは、SMTPのRCPT TOに宛先があるからです。同様に、エンベロープFromが本文ヘッダーに直接見えなくても、サーバーは返送経路として保持します。

受信側が宛先不存在などをSMTPトランザクション中に拒否すれば、接続中の送信サーバーが失敗を知ります。いったん受理した後で最終配送に失敗した場合は、受け取ったサーバーが逆方向経路宛にDSNやバウンスメールを作ります。

ヘッダーFromへ自動返送すると、表示差出人を偽った第三者へ誤通知を送り、後方散乱を増やします。配送層で引き継いだ逆方向経路を使うことが重要です。

配送状態通知など、それ自体が配送失敗したときにさらに通知を返すべきでないメールは、MAIL FROM:<>という空の逆方向経路を使います。これは送信者不明という意味ではなく、エラー返送を重ねないための特別な値です。

空の逆方向経路ではSPFがMAIL FROMドメインを得られないため、HELOの識別子を評価します。空文字を一般のメールアドレスとして保存せず、プロトコル上の状態として扱います。

メッセージが最終配送されると、受信MTAは逆方向経路をReturn-Path（リターン・パス）ヘッダーとして先頭付近へ記録します。これにより、保存後の診断で配送時の返送先を確認できます。

中継途中の送信者が用意したReturn-Pathを信頼してはいけません。最終配送側は既存の不正な値を除去し、自分が受け取ったSMTP情報から生成します。Receivedと合わせ、どのサーバーが付けたかを確認します。

SPFは、直接接続した送信元IPがMAIL FROMドメインを使うことを許可されているかを調べます。エンベロープFromを外部配信サービスのドメインにすると、そのサービスのSPFは通過しても、表示Fromとは異なる場合があります。

DMARCでSPF経路を通過させるには、SPF通過に使ったドメインとヘッダーFromのAuthor Domainが整合する必要があります。SPF通過だけを見て表示差出人を認証済みとしません。

単純転送で元の逆方向経路を保つと、最終受信者が観測する接続元は転送サーバーですが、検査ドメインは元送信者のままです。元ドメインが転送サーバーを許可していないためSPF失敗になり得ます。

SRS（Sender Rewriting Scheme／センダー・リライティング・スキーム）は、転送側が自分のドメインへ逆方向経路を書き換え、元の返送情報を復元可能な形で符号化する考え方です。DKIM・DMARCとの組み合わせも確認します。

配信システムは受信者ごとに異なるローカルパートを逆方向経路へ設定し、どの宛先で恒久失敗や一時失敗が起きたかを対応させることがあります。VERPなどの方式です。

返送アドレスへ顧客IDやメールアドレスをそのまま埋め込むと、ヘッダーやログから個人情報が漏れます。推測しにくい短期トークン、署名、保持期限、アクセス制御を使います。

エンベロープFrom、Return-Path、ヘッダーFromを並べ、SPF・DKIM・DMARCの各結果と対応させます。投稿時のアカウント、Sender、Reply-Toが別ならそれも分離します。

MAIL FROMのドメイン、接続元IP、SMTP応答、Return-Pathを記録し、個別受信者を表すトークンや内部配送名は共有前に伏せることが安全です。