要約

  • RFC 3461 は、宛先ごとに成功・失敗・遅延の通知を要求し、トランザクション識別子と元の宛先を中継先へ渡せるようにした。RFC 3464 は、その返答を宛先別の機械可読な報告にした。
  • delivered は既読を意味せず、relayed は成功通知の責任が途切れる境界を示す。構造化された DSN も偽造や喪失、機密転送による打ち切りを免れない。

従来のバウンスメールは、一通の自由形式メールに多くの役割を背負わせていた。利用者へ失敗を知らせ、運用者へ診断材料を渡し、ソフトウェアには元の送信との対応を推測させる。製品ごとに文章も添付範囲も異なり、大規模なメーリングリストでは、どのホスト、どの宛先、どの投入トランザクションに関する通知かさえ判別しにくかった。

SMTP では RCPT に肯定応答したサーバーが、通常は配達するか、後で失敗を通知する責任を引き受ける。しかし「通知」には複数の問いが隠れていた。成功も知りたいのか、失敗だけでよいのか、長い遅延を知りたいのか。転送で実際の宛先が書き換わっても、送信者が指定した宛先をどう残すのか。同じ本文を複数回投入したとき、どの取引への返答なのか。

2003 年 1 月の RFC 3461、3463、3464 は、それぞれ要求、報告形式、拡張状態コードを分担した。目的は「必ず届く」という受領証ではない。要求者、受諾した MTA、報告 MTA、異種環境のゲートウェイが、それぞれ何を知り、何を決められるかを分離することだった。

四つのパラメーターが希望と結果を分けた

サーバーは EHLO 応答の DSN で対応を示す。新しい SMTP 動詞はなく、MAIL に RET と ENVID、RCPT に NOTIFY と ORCPT が加わる。

NOTIFY は宛先単位で、SUCCESS、FAILURE、DELAY を組み合わせられる。NEVER は単独で使う。省略時は、従来どおり失敗のみ、または失敗と遅延を通知してよい。送信者が選ぶのは受け取りたい証拠の種類であり、配達結果ではない。

DELAY は時間を指定する機能でもない。保留している MTA が「異常に長い」と判断し、その時点では成功か失敗か未確定である。同じ 4.x.x の一時的状態でも、再試行中なら delayed、最終的に諦めれば failed になる。

RET=FULL は失敗 DSN に元メッセージ全体を、RET=HDRS はヘッダーだけを求める。失敗した宛先がない報告では、ヘッダーだけを返す。本文を戻せば診断しやすい一方、別経路と別保管先に内容を複製することになる。

二種類の識別子は別の問いに答える

ENVID は封筒トランザクションの識別子で、DSN では Original-Envelope-Id として戻る。メールシステムは値を解釈せず、意味を持たせるのは送信者側だけである。本文ヘッダーの Message-Id とは異なる。後者は内容、前者は一回の投入を識別する。同じ内容を再送でき、一回の投入に結果の異なる複数宛先を含められるからだ。

ORCPT は送信者が最初に指定した宛先を保持する。初回投入では RCPT TO と同じでなければならない。転送後は現在の配送先が変わっても、元の宛先が並行して残る。現在値は次の試行先を示し、ORCPT は報告が送信者のどの宛先に属するかを示す。

これにより、まず ENVID で投入を照合し、次に元の宛先で結果を照合できる。ただし、いずれも認証ではない。トークンは報告者を証明せず、アドレスは人の所有を証明しない。中継が値を保ち、受信側が通常のメールと同じ警戒を行って初めて役立つ。

Action と Status は重複しない

RFC 3464 の DSN は multipart/report である。第一部は人向け説明、第二部の message/delivery-status はメッセージ全体のフィールドと宛先別フィールド群、第三部は任意で元メッセージまたはヘッダーを収める。

宛先ごとの Action は failed、delayed、delivered、relayed、expanded の五つである。Status は RFC 3463 の三部コードを使い、2.x.x は成功、4.x.x は持続的な一時失敗、5.x.x は恒久失敗を表す。

状態は原因の分類、Action は運用上の判断である。DNS タイムアウトが同じ 4.x.x でも、再試行中は delayed、キューが断念した後は failed になる。

failed は終端、delayed は継続中である。delivered はその宛先について終端だが、メーリングリスト配信器への受け渡しも含み、読まれたことは示さない。expanded は複数宛先エイリアスが受け取り、さらに配送先を生成した状態なので、その後の遅延や失敗があり得る。

relayed は観測可能性の端を明示する。成功 DSN の責任を負わない環境へ渡したことまでは分かるが、最終メールボックスの結果は分からない。標準は、引き渡しを架空の成功へ変換せず、証拠が途切れる場所を名前で残した。

通知失敗の通知を作らない

DSN 自身もメールなので失敗する。そこから別の DSN を生成すれば、到達不能なシステム同士が通知の通知を増殖させる。そこで SMTP で送る DSN は空のリバースパス MAIL FROM:<> を使い、その失敗から新しいネットワーク DSN を生じさせない。

これは安定性のために再帰的な可視性を捨てる設計である。送信者は報告の喪失を知らないかもしれない。それでも無限ループより安全だ。信頼性とは、すべての失敗を知ることではなく、明示された境界内で意味を壊さないことである。

異種環境へのゲートウェイも境界になる。DSN 対応 SMTP 間では要求と識別子を継承するが、別のメール体系では最善努力の変換しかできない。さらに、秘密の転送先を守るため、遠隔フィールドを省略したり、下流の成功通知を止めたり、境界で relayed と報告したりできる。完全な追跡と受信者のプライバシーは常に両立しない。

機械可読性は真正性ではない

RFC 3464 は、DSN が通常のインターネットメールと同程度に偽造できると警告する。偽の成功は追跡を止め、偽の失敗は再送、リスト削除、誤ったサポート対応を誘発する。ENVID は照合に役立つが、署名にはならない。

返却内容にも危険がある。FULL は機密本文を別の経路、ログ、メールボックスへ複製する。ヘッダーだけでも通信相手、件名、経路を漏らす。送信者は範囲を選べても、その後の全保管を支配できない。

DSN の歴史的価値は、限定された権限の文法にある。送信者は要求と相関値を決める。MTA は受諾、再試行、断念を決め、自らの Action を報告する。ゲートウェイは翻訳できる範囲を決め、秘密転送は開示を止める。人が読む行為は SMTP の外に残る。

IANA の SMTP 登録簿は現在も DSN を RFC 3461 に結び付けている。どの投入、どの元宛先、どの報告者、どの動作、どの条件かを機械が区別できる。その精度は、受信箱到達や人の注意まで約束しないからこそ保たれている。

出典