Reporting-

Reporting-

[2] 媒体型 multipart/report は、電子メイル・システムの各種の報告メッセージのための汎用的な包含子的書式です。 MIMEmultipart/* の構文を基本に、 DSNMDN など報告の種類に応じた具体的な形式が別途規定されています。

[3] 仕様書:

[4]

媒体型名
multipart/report
multipart/report
規定無し
素片識別子
規定無し
内容転送符号化
常に 7bit
引数
引数名引数値既定値説明状態出典
boundary(必須)多部分境界IETF 提案標準MIME
report-type媒体亜型(必須)報告の種類IETF 提案標準RFC 1892, RFC 3462

[5] この媒体型は 822 メッセージの一番外側 (multipart/* 内でないところ) で使用します RFC-REPORT 1.

[1] 引数 report-type の値は、 第2部分の媒体型の亜型 (斜線の後の部分) でなければなりません RFC-REPORT 1.

構文

[7] 基本的には multipart/* の構文をそのまま利用します。含まれる各実体の境界は boundary 引数を元に決定されます。

部分

[8] multipart/report 実体は、 中に2つか3つの実体を持ちます。

第1部分 —— 人間可読メッセージ

[9] 第1部分は人間可読なメッセージとします。 その内容は、報告する事項をわかりやすく解説したものとします。 第2部分を利用者エージェントが理解できなくてもこの部分から人間利用者が報告の意味を理解できます。 また、第2部分で形式的に記述できないことの説明にも使えます。 RFC-REPORT 1.

[10] 媒体型・言語: 記述の方法は任意の標準化過程媒体型charset言語を使って構いません。 multipart/alternative により複数種類を同梱することもできます。 RFC-REPORT 1.

[11] 省略: この部分は必須です。 RFC-REPORT 1.

第2部分 —— 機械可読報告

[12] 報告する内容についての詳しい情報を機械可読な形式で入れます。 第1部分で説明しなかった細かい内容も含めることができます。 RFC-REPORT 1.

[13] この部分が multipart/report メッセージ全体を特徴付けることになります。 multipart/report 媒体型report-type 引数には、 この第2部分の媒体型の亜型を指定します。 RFC-REPORT 1.

[22] 媒体型: この部分で使用する媒体型については特に制限はないようで、 >>12 の目的を果たせるなら何でも良いと思われます。 今のところ標準化されているものは全て message/* ですが、 そのような制限もないようです。

[14] 省略: この部分は必須です。 RFC-REPORT 1.

第3部分 —— 元のメッセージ

[15] 第3部分には報告の対象となった元のメッセージの一部又は全部を含めることができます。 この情報は人間の専門家が問題の分析のために使うことができます。 (報告を受け取った側で自動的に対応する元のメッセージを決定するために使うこともできますが、そのための情報は第2部分に含めることが想定されています。) RFC-REPORT 1.

[16] 元のメッセージを報告に含めるかどうか、 含めるとしたら全部含めるか、 どの部分を含めるかは報告の種類と報告の要求者の希望などによります。 詳しくは各報告種の説明をご覧下さい。

[17] multipart/report 媒体型自体は常に Content-Transfer-Encoding7bit とされています。第3部分に含めるメッセージは通常 message/* なので、 やはり規定により 7bit8bitbinary に制限されてしまいます。

第3部分に含めるメッセージ7bit で表現できない場合、合法的な 7bit MIME メッセージになるように再符号化しても構いませんし、 頭部だけを取り出して text/rfc822-headers 媒体型としても構いませんRFC-REPORT 1.

text/rfc822-headers だけなら任意の内容転送符号化が使えますし、 通常診断には頭部があれば十分ということなのでしょう。

[22] 媒体型: この部分に使用する媒体型は、 >>17 の通り text/rfc822-headers を使うことが特に提案されていることを除き、 特に制限されていないようです。 報告の種類によっては具体的に規定があるかもしれません。

[21] 省略: この部分は省略可能です。 RFC-REPORT 1.

応用

[20]

report-type媒体型説明状態出典
delivery-statusmessage/delivery-statusDSNIETF 原案標準[RFC]
disposition-notificationmessage/disposition-notificationMDNIETF 原案標準[RFC]
tracking-statusmessage/tracking-statusMTSNIETF 提案標準RFC 3886
feedback-reportmessage/feedback-report

利用者エージェント・関門

[6] 利用者エージェント関門は、 822 メッセージ最外 Content-Type を見て、メッセージがメッセージ・システムからの報告であることを決定しなければなりませんし、 そうであるとして処理するべきです RFC-REPORT 1.

安全性

[18] インターネット電子メイル・システムでは比較的簡単になりすましが行えてしまいます。 multipart/report の報告を捏造することも可能ですから、 報告を受信した側で自動処理を行う時は安全への配慮を怠ってはなりません。

[19] multipart/report 全体に署名するようなことも可能ですが、 RFC 3462 は適用範囲外であるとして特にその方法を定めてはいません。

メモ

[823] RFC 6591 - Authentication Failure Reporting Using the Abuse Reporting Format ( ( 版)) http://tools.ietf.org/html/rfc6591

[824] RFC 6650 - Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) ( ( 版)) http://tools.ietf.org/html/rfc6650

[23] RFC 8098 - Message Disposition Notification () https://tools.ietf.org/html/rfc8098#section-3

[24] RFC 4249: Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components, https://www.rfc-editor.org/rfc/rfc4249.html#section-3.1.2.2.6