← RFC Reference

RFC 6522: Multipart/Report メディアタイプ (更新版)

この存在する理由

メールは多くの種類の自動化されたレポートを生成します：バウンス通知（RFC 3464）、スパム苦情（RFC 5965）、認証失敗レポート（RFC 6591）、TLS失敗レポート（RFC 8460）。これらすべては、人間が読める概要とマシンが解析可能なレポートの両方を含められる共通のコンテナフォーマットが必要です。

multipart/reportがそのコンテナです。元々はRFC 3462で定義されており、RFC 1892を更新しました。RFC 6522は現在のバージョンで、仕様を最新のMIME登録手順に合わせ、以前のドラフトの曖昧さを明確にしています。

RFC 3462からRFC 6522への主な変更：

• MIME タイプ登録を現在の IANA テンプレートフォーマットに準拠するように更新
• report-type パラメータが必須であることを明確化（オプションではなく）
• 仕様言語を厳密化し、パート順序の曖昧さを除去
• RFC 6838 の更新された MIME フレームワークに対応

動作方法

multipart/report メッセージは、内部のレポートの種類を識別する必須の report-type パラメータを持つ MIME マルチパートメッセージです。特定の順序で 2 つまたは 3 つの MIME パートを含みます：

1. 人間が読める部分（text/plain または text/html）— メールクライアントでメッセージを開いた人間向けの概要。
2. マシンが読める レポート — 構造化されたデータ。コンテントタイプは report-type によって異なります：
   • delivery-status → message/delivery-status（RFC 3464）
   • feedback-report → message/feedback-report（RFC 5965）
   • tlsrpt → application/tlsrpt+json（RFC 8460）
3. 元のメッセージ（オプション）— レポートをトリガーしたメッセージの message/rfc822（完全なメッセージ）または text/rfc822-headers（ヘッダーのみ）。

構造例：DSNバウンス

From: mailer-daemon@mail.example.org
To: sender@example.com
Subject: Delivery Status Notification (Failure)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY-001"

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

Your message to user@example.org could not be delivered.
The mailbox does not exist.

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

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue, 10 Mar 2026 14:22:00 -0500

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 Mailbox not found

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

From: sender@example.com
To: user@example.org
Subject: Invoice #1234
Message-ID: <inv-1234@example.com>

--REPORT-BOUNDARY-001--

構造例：ARF苦情

Content-Type: multipart/report; report-type=feedback-report;
    boundary="ARF-BOUNDARY-001"

--ARF-BOUNDARY-001
Content-Type: text/plain

This is a spam complaint for a message from 203.0.113.10.

--ARF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: FBL/1.0
Version: 1
Source-IP: 203.0.113.10

--ARF-BOUNDARY-001
Content-Type: message/rfc822

[original message]

--ARF-BOUNDARY-001--

主要な技術詳細

report-type パラメータ

Content-Type ヘッダーの report-type パラメータは必須で、2 番目の MIME パートで予想されるマシンが読めるデータの種類をパーサーに伝えます：

パート順序のルール

• 最初のパートは常に人間が読める形式である必要があります（text/plain など）。
• 2 番目のパートは、report-type に対応するコンテントタイプを持つマシンが読めるレポートである必要があります。
• オプションの 3 番目のパートには元のメッセージまたはそのヘッダーが含まれます。message/rfc822、text/rfc822-headers、または message/global（国際化されたメッセージ用）を使用する必要があります。

国際化

RFC 6522 は、3 番目のパートの代替として message/global および message/global-headers のサポートを追加し、RFC 6531/6532 に従って国際化されたメールアドレスとヘッダーに対応します。

一般的な間違い

• report-type パラメータの省略。 report-type がないと、パーサーは 2 番目の MIME パートに何が含まれているかを判定できません。RFC 6522 はこのパラメータを必須にしています。常に含めてください。
• パート順序が間違っている。 いくつかの実装では、マシンが読める部分を最初に配置しています。メールクライアントがレポートタイプを理解していなくても何か有用なものが表示されるように、人間が読める部分が最初に来る必要があります。
• Content-Type のみでの解析。 2 番目のパートの Content-Type をスキャンしてレポートタイプを検出しようとしないでください。外側の multipart/report Content-Type の report-type パラメータを使用してください。それがその目的です。
• multipart/report を multipart/mixed として扱う。 構造的には似ていますが、multipart/report には厳密なパート順序とセマンティクスがあります。汎用 MIME パーサーはそれを表示できますが、レポートプロセッサは定義された構造を尊重する必要があります。
• RFC 3462 と RFC 6522 の混同。 両者は同じコンテントタイプを定義しています。RFC 6522 は RFC 3462 を廃止します。既存のコードで RFC 3462 への参照が見られる場合、動作は同等です。ただし、新しい実装では RFC 6522 を引用してください。

配信可能性への影響

• すべてのメールレポートの基盤。 すべての DSN、ARF 苦情、DMARC 集計レポート、TLS 失敗レポートは multipart/report を使用します。このコンテナを処理できるパーサーがない場合、自動メールフィードバックを処理することはできません。
• バウンス処理は正しい解析に依存します。 バウンスプロセッサは最初に multipart/report を認識し、次に report-type=delivery-status をチェックし、次に message/delivery-status パートを抽出する必要があります。ステップを間違えると、バウンスを見落とし、リスト品質を低下させます。
• 苦情ループ処理。 メールボックスプロバイダーからのフィードバックループレポートは report-type=feedback-report を使用します。コンテナを正しく解析することは、苦情データを抽出し、受信者を抑制するための最初のステップです。
• TLS レポート。 SMTP TLS レポートは、report-type=tlsrpt を使用して multipart/report 内で JSON ペイロードを配信します。これらのレポートは、メールが安全に配信されるのを静かに防める TLS ネゴシエーション失敗を明らかにします。

Related RFCs