要約

  • 通常のSMTPメールは後日の配送報告先をreverse-pathで示す。配送通知は MAIL FROM:<> を使い、通知自身の失敗から新たな通知が生まれないようにする。
  • null reverse-pathは有効なエンベロープ値であり、ヘッダーの From: 欠落、正当性、匿名性を意味しない。受け付けと終端の意味を認識したうえで、HELOやSPFを含む別の統制を行う必要がある。
  • 構造化DSNは受信者ごとの結果や照合情報を増やしたが、終端規則は維持した。遠隔通知が不可能になった時点で、処理責任はローカル運用へ収束する。

成功応答の後に、二通目のメールが必要になる

SMTP接続中に受信者を拒否できるなら、失敗はその場の否定応答で返せる。送信クライアントはまだ接続しており、メッセージを保持したまま次の判断を行える。配送失敗を伝える別のメールは要らない。

難しいのは、受信側がDATAの後に成功を返して責任を引き受けた後で、次のホストに届かない、メールボックスが消えた、リスト展開が失敗した、と判明する場合だ。元のクライアントとのセッションは終わっている。失敗という事実そのものを、新しいメールとして元のreverse-pathへ送らなければならない。

その通知にも普通の差出人メールボックスを与えると、暗黙の約束がもう一つ生まれる。通知が配送不能なら、その差出人へ配送不能通知を出す。次の通知も届かなければ同じ動作を繰り返す。信頼性のための仕組みが、無限のエラートラフィックを作り得る。

RFC 821 は1982年の時点でこの危険を記述し、通知メッセージの問題について通知を作らないよう求めた。そこで使われた短い表現が MAIL FROM:<> である。

山括弧の中は、空文字を名前にしたメールボックスではない。「このトランザクションの失敗を遠隔へ返す先はない」という文法上のnull reverse-pathだ。生成したMTA、接続元、RCPT TO、トレースは存在する。消えるのは、さらに一段後ろへ失敗を送る権利だけである。

「受け入れる」と「そこで止める」は一組の要件

初期SMTPではループ回避の方法として説明された空の経路を、RFC 1123 は相互運用上の義務へ強めた。実装は空のreverse-pathをサポートしなければならない。通常のメールアドレスがないという理由だけで MAIL FROM:<> を不正構文として拒否してはならない。

同時に、受付後に生じた失敗通知はnull reverse-pathを使い、報告先となる元の経路がすでにnullなら通知を生成してはならないとした。正当な終端メッセージを受け入れる能力と、終端メッセージへ返信しない判断は切り離せない。

受け入れだけ実装すれば、自動応答が再帰を復活させる。停止だけを重視して空の送信者を一律拒否すれば、正規の配送報告が失われる。明示的な「無」は、単なる未入力と違って、相手に意味を伝えるプロトコル値なのである。

Fromは人に、reverse-pathは配送機械に向く

エンベロープの MAIL FROM と本文ヘッダーの From: は別物だ。Reply-To: もまた、人間が返事をする方向を示すための別の面である。表示上はいずれもメールアドレスに見えるが、制御する会話が異なる。

自動生成された配送通知は、読者に発行主体を理解させるため、可視のFromに運用サービス名を置ける。それでも配送エンベロープは MAIL FROM:<> にできる。人へ説明する入口を残しながら、機械には「このメッセージの失敗を報告するな」と指示している。

汎用ワークフローが空欄を嫌い、ヘッダーFromをエンベロープへコピーすると、消したはずの辺を再接続する。Reply-Toから自動応答先を推測する実装も同様だ。nullを正しく保存することは、値を埋めることより難しい場合がある。

受付境界が責任の形を決める

RFC 5321 では、DATA後の肯定応答が責任の引き渡しとなる。その前に受信側が受信者不存在や方針違反を確実に判断できるなら、接続中に拒否するのが最も明確だ。実際のクライアントへ直接結果を返せるため、偽造されたreverse-pathへ後発のバウンスを送る危険も減る。

ただし、後からしか分からない障害は残る。DNSの一時障害、下流ゲートウェイ、非同期処理、メーリングリストの展開では、受付後の通知が必要になる。null senderは、その新しい枝がもう一度枝分かれしないようにする。

これだけでbackscatterがなくなるわけではない。攻撃メールの通常reverse-pathに第三者のアドレスが偽装され、サーバーがいったん受け入れて後から拒否すれば、最初の通知は第三者へ飛ぶ。nullは通知の通知を止めるが、最初の誤配送を直さない。早期拒否、送信ホストの評価、レート制御は別の境界を守る。

最後の障害はローカルで引き受ける

正規のDSNそのものが配送不能になったとき、外部への通知系列は終了する。しかし、運用上の故障まで存在しなかったことにはできない。RFC 5321はnullアドレスの失敗をローカルで記録したり同一環境内で通知したりできるとし、メールシステムを修復できるpostmasterへ伝える運用にも触れている。

ここで重要なのは境界だ。ローカルのアラートが再び外部DSNを生むなら、終端は形だけになる。キューID、元のエンベロープ、受信者別結果、最終診断、試行時刻を保管し、当該システムの管理者が処理する必要がある。

nullは責任放棄ではない。誰にメールを送ってはいけないかを限定し、最後に残った責任者を明確にする。遠隔報告の終了と観測記録の削除を同一視すると、障害分析も責任追跡もできなくなる。

DSNは自然文を受信者別の証拠へ分解した

RFC 3461 のDSN拡張は、報告要求をより明示的にした。ENVID は送信側が選んだエンベロープ識別子、RET は原文の返却範囲、ORCPT は書き換え前の受信者を保持する。NOTIFY は SUCCESS、FAILURE、DELAYを選べる一方、NEVER は単独で使い、通知不要を示す。

これらは受付可否を決める追加の資格ではない。有効なパラメータがあるからMAILやRCPTを受け付けたり拒否したりするものではなく、後の報告方法を指定する。null reverse-pathを持つメッセージについては、ヘッダーにもっともらしい送信者がいてもDSNを作ってはならない。

DSNを送る側もnullの送信者を使う。DSN自身のトランザクションに RET は使わず、NOTIFY を添えるなら NEVER だけである。内容を詳しくすることと、次の報告を要求しないことが同時に成立する。

RFC 3464 はDSNを multipart/report とし、人向け説明、機械可読な message/delivery-status、条件に応じた原メッセージ素材を組み合わせた。一つのDSNは一つの原メッセージを扱うが、複数の受信者について別々のブロックを持てる。Action は failed、delayed、delivered、relayed、expandedなどを区別し、Status は構造化コードを運ぶ。

この分割により、一部成功を全体失敗と誤認せずに済む。リスト管理者は失敗した購読者だけを扱え、送信者は遅延中の相手を待機状態に保てる。一方で、転送先や受信者、元本文が漏れる危険があるため、秘密の転送境界では情報を省略できる。

DSNは運用証拠であって、改ざん不能な証明ではない。報告形式は偽造でき、SPFに通るホストでも誤った結果を生成し得る。構造化によって問いは精密になるが、真正性が自動的に得られるわけではない。

休暇応答にも同じ停止規則が要る

配送通知以外にも、自動メール同士が会話を始める場面がある。休暇応答、グループサービス、問い合わせボット、コンテンツ処理系は、相手の応答を新しい依頼と誤認できる。RFC 3834 は、宛先がnullになる自動応答を生成せず、通常は人向けヘッダーから推測せずエンベロープReturn-Pathを使うよう求める。

応答自体にさらに応答される必要がなければ MAIL FROM:<> を使え、DSN拡張があれば NOTIFY=NEVER が適切だ。ただしループ防止は同意や権限の代替にならない。偽造された返信先へ巨大な応答や副作用を送るサービスは、ループしなくても増幅器になる。

RFC 6409 は投稿段階でもnull return pathだけを理由に拒否してはならないとする。正規のMUAが処置通知などを生成するからだ。認証、利用者権限、レート、内容検査は続けられる。「nullだから悪意」という単一条件が不適切なのである。

空のメールボックスにもホスト評価面は残る

SPFは通常MAIL FROMドメインを評価する。RFC 7208 はreverse-pathがnullのとき、HELOアイデンティティのドメインにある postmaster をMAIL FROMアイデンティティとして構成する。メールボックス送信者がなくても、送信ホストとドメインの認可関係を評価できる。

その結果が証明する範囲は狭い。SPFはDSN本文の真実、配送障害の発生、人の身元を証明しない。null senderも無審査ではなく、審査対象がセッション側へ移るという意味である。

なお、null MXとは役割が異なる。null MXはDNSで「このドメインはメールを受け取らない」と示す。null reverse-pathは現に送信中の一通について「失敗時に報告メールを作らない」と示す。ドメインへの入口を閉じる仕組みと、通知系列の末端を示す仕組みを混同してはならない。

情報源と証拠の限界

初期の配送不能通知と MAIL FROM:<> によるループ防止はRFC 821：https://www.rfc-editor.org/rfc/rfc821.html

空経路の必須サポートとnull宛て通知禁止はRFC 1123：https://www.rfc-editor.org/rfc/rfc1123.html

DSNエンベロープパラメータ、null sender処理、NOTIFY=NEVER はRFC 3461：https://www.rfc-editor.org/rfc/rfc3461.html

構造化DSN、受信者別フィールド、プライバシーとセキュリティ上の限界はRFC 3464：https://www.rfc-editor.org/rfc/rfc3464.html

休暇・グループ・サービス自動応答の規律はRFC 3834：https://www.rfc-editor.org/rfc/rfc3834.html

現行SMTPの責任移行、null senderの用途、転送とローカルpostmaster処理はRFC 5321：https://www.rfc-editor.org/rfc/rfc5321.html

投稿時の正当なnull sender受け入れはRFC 6409：https://www.rfc-editor.org/rfc/rfc6409.html

null reverse-path時のHELOベースSPFアイデンティティはRFC 7208：https://www.rfc-editor.org/rfc/rfc7208.html

これらはプロトコル上の要件を示すもので、個別DSNの真正性や現在のサービス実装率を証明しない。本稿は現在のバウンス量、スパム率、拒否率を推計しない。