← RFC Reference

RFC 3462: Multipart/Report コンテンツタイプ

このセットアップが存在する理由

1990年代半ばにDSN（配信状態通知）フレームワークが作成されたとき、作成者は人間が読める形式と機械が読める形式の両方を同じメッセージで処理できるMIMEコンテナが必要でした。通常のmultipart/mixedは構造的には機能しますが、メッセージが自動レポートで特定の内部形式であることを示すセマンティック信号がありません。

multipart/reportは次の方法で解決します：

• メッセージが自動レポートであることをメールクライアントに通知し、特別なUI処理を有効にします（多くのクライアントはバウンスを通常のメールと異なる方法で表示します）
• report-typeパラメータを含むため、パーサーは内部で何の機械可読形式を期待すればよいかを知ることができます
• 厳密なパート順序を定義します：人間が読める形式優先、機械が読める形式次点、元のメッセージ3番目

RFC 3462はこの仕様の2番目の改訂版です（RFC 1892の後）。後にRFC 6522により廃止されました。RFC 6522は言語を厳密にしてIANA登録を更新しました。実際のワイヤ形式は変わりません。RFC 3462に準拠するメッセージはRFC 6522にも準拠しています。

仕組み

multipart/reportコンテンツタイプは、追加の制約があるあらゆるMIMEマルチパートのように機能します：

Content-Type宣言

Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY"

report-typeパラメータは受信者にどの種類のレポートかを伝えます。boundaryパラメータは、あらゆるマルチパートメッセージのようにMIMEパートを分離します。

3パート構造

--REPORT-BOUNDARY
Content-Type: text/plain

; パート1：人間が読める要約
user@example.orgへの配信が永続的に失敗しました。
受信者のメールボックスが存在しません。

--REPORT-BOUNDARY
Content-Type: message/delivery-status

; パート2：機械が読めるレポート
Reporting-MTA: dns; mx.example.com

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1

--REPORT-BOUNDARY
Content-Type: text/rfc822-headers

; パート3：元のメッセージヘッダー（オプション）
From: sender@example.com
To: user@example.org
Subject: Hello
Message-ID: <msg-001@example.com>

--REPORT-BOUNDARY--

主要な技術仕様

経時的に定義されたレポートタイプ

RFC 3462が公開されたとき、delivery-statusのみが存在していました。後のRFCは同じmultipart/reportコンテナを使用するより多くのレポートタイプを追加しました：

必須パートの最小数

RFC 3462は最低2つのパートを必須にしています：人間が読める要約と機械が読めるレポートです。3番目のパート（元のメッセージ）はオプションですが、DSNの場合は強く推奨されます。これにより、送信者はどのメッセージがバウンスしたかを特定できます。

RFC 6522との関係

RFC 6522はこのドキュメントを廃止します。変更は編集的で、動作ではありません：

• report-typeパラメータは必須として明示的にマークされます（3462は曖昧でした）
• IANA登録テンプレートが現在の標準に更新されました
• 国際化メッセージタイプ（message/global）のサポートが追加されました

コードがすでにRFC 3462を正しく処理している場合、RFC 6522も処理しています。ワイヤ形式は変わりません。

よくある間違い

• 人間が読める部分を信頼できる情報として扱う。最初のパートは表示専用です。自動化されたシステムは2番目の（機械が読める）パートを解析する必要があります。人間が読めるテキストは構造化データと一致しない可能性があります。
• 3つのパートのみと仮定する。ほとんどのレポートは正確に3つのパートを持ちますが、仕様では2つ（元のメッセージなし）を許可します。パーサーは3番目のパートがない場合に失敗してはいけません。
• multipart/reportを完全に無視する。いくつかのバウンスプロセッサは、すべてのバウンスメッセージを自由形式テキストとして解析しようとします。これはうまく機能しません。常に最初にmultipart/reportをチェックし、利用可能な場合は構造化データを使用します。
• report-typeをチェックしない。report-type=feedback-reportのmultipart/reportはバウンスではなく、スパム報告です。これをバウンスとして扱う（リストからアドレスを削除する）のは間違っています。アドレスは有効で、受信者がメールを希望していないだけです。
• 3番目のパートなしでレポートを生成する。技術的には有効ですが、元のメッセージヘッダーを省略すると、送信者はどのメッセージがレポートをトリガーしたかを特定するのが非常に難しくなります。常に最低限ヘッダーを含めます。

配信性への影響

• すべての自動メールフィードバックフローはこの形式を通じて流れます。バウンス、スパム報告、開封確認、またはTLSレポートであるかどうかに関わらず、外側のコンテナはmultipart/reportです。この形式を理解することはそれらのいずれかを処理する前提条件です。
• 正しいバウンス分類がここから始まります。report-typeを最初にチェックすることで、システムはdelivery-statusメッセージをバウンスプロセッサにルーティングし、feedback-reportメッセージを報告ハンドラーにルーティングできます。これは根本的に異なる2つのワークフローです。
• メールクライアント表示。多くのメールクライアントはmultipart/reportを認識し、特別に表示します（例えば、「配信失敗」バナーを表示）。適切に形成されたレポートを生成すると、サーバーがバウンスを送信するときのユーザー体験が向上します。
• Message-ID相関。3番目のパート（元のメッセージまたはヘッダー）は、バウンスをそれを引き起こしたメッセージに照合する方法です。これなしに、受信者のアドレスのみに基づいて推測しており、転送とエイリアスで信頼性がありません。

Related RFCs