Internet Engineering Task Force (IETF) M. Kucherawy, Ed.
Request for Comments: 6522 Cloudmark
STD: 73 January 2012
Obsoletes: 3462
Category: Standards Track
ISSN: 2070-1721
The Multipart/Report Media Type for
the Reporting of Mail System Administrative Messages
Abstract
抽象
The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.
マルチパート/レポートMIME（Multipurpose Internet Mail Extensions）のメディアタイプは、あらゆる種類の電子メールレポートのための一般的な「家族」や「コンテナ」タイプです。このメモは、配送状態レポートに関して、マルチパート/レポートのメディアタイプの使用のみを定義していますが、単一のメディアタイプは、レポートのすべての種類のために使用されている場合、メール処理プログラムが利益になります。
This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic".
このメモは、RFC 3462、およびマークRFC 3462および「歴史」としてその前身の「メールシステム管理メッセージの報告のための複合/レポートのコンテンツタイプ」を廃止します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6522.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6522で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Document Conventions ............................................3
3. The Multipart/Report Media Type .................................3
4. The text/rfc822-headers Media Type ..............................5
5. Registering New Report Types ....................................7
6. IANA Considerations .............................................7
7. Security Considerations .........................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. Acknowledgements ......................................9
[OLD-REPORT] and its antecedent declared the multipart/report media type for use within the [MIME] construct to create a container for mail system administrative reports of various kinds.
[OLD-REPORT]とその先行詞は、[MIME]内で使用する各種のメールシステム管理レポートのコンテナを作成するために構築するためのマルチパート/レポートのメディアタイプを宣言しました。
Practical experience has shown that the general requirement of having that media type constrained to be used only as the outermost MIME type of a message is overly restrictive and limits such things as the transmission of multiple administrative reports within a single overall message container. In particular, it prevents one from forwarding a report as part of another multipart MIME message.
実際の経験は、メッセージの最も外側のMIMEタイプとして使用することに制約そのメディアタイプを有する一般的な要件は過度に制限的であり、単一の全体的なメッセージコンテナ内の複数の管理レポートの送信のようなものを制限することが示されています。特に、別のマルチパートMIMEメッセージの一部としてレポートを転送から1を防止します。
This memo removes that constraint. No other changes apart from some editorial ones are made. Other memos might update other documents to establish or clarify the constraints on use of multipart/report in contexts where such are needed.
このメモはその制約を削除します。いくつかの社説のものから離れて他の変更は行われません。その他のメモには、が必要とされている状況でマルチパート/レポートの使用上の制約を確立するか、明確にするために他の文書を更新する可能性があります。
This memo obsoletes RFC 3462. RFC 3462 and its predecessor, RFC 1892, have been marked as "Historic".
このメモはRFC 3462. RFC 3462およびその前身、RFC 1892を廃止、「歴史」としてマークされています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
The multipart/report MIME media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.
マルチパート/レポートMIMEメディアタイプは、あらゆる種類の電子メールレポートのための一般的な「家族」や「コンテナ」タイプです。このメモは、配送状態レポートに関して、マルチパート/レポートのメディアタイプの使用のみを定義していますが、単一のメディアタイプは、レポートのすべての種類のために使用されている場合、メール処理プログラムが利益になります。
Per [MIME-REG], the multipart/report media type is defined as follows:
以下のようにMIME-REG]あたり、マルチパート/レポートメディアタイプが定義されています。
Type name: multipart
型名：マルチパート
Subtype name: report
サブタイプ名：レポート
Required parameters: boundary, report-type
必須パラメータ：境界、レポートタイプ
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: 7bit should always be adequate
エンコードの考慮事項：7ビットは常に十分なはずです
Security considerations: see Section 7 of [RFC6522]
セキュリティの考慮事項：[RFC6522]のセクション7を参照してください
Interoperability considerations: see Section 1 of [RFC6522]
相互運用性に関する注意事項：[RFC6522]のセクション1を参照してください
Published specification: [RFC6522]
公開された仕様：[RFC6522]
Applications that use this media type: Mail Transfer Agents, Mail User Agents, spam detection and reporting modules, virus detection modules, and message authentication modules.
メール転送エージェント、メールユーザエージェント、スパム検出および報告モジュール、ウイルス検出モジュール、およびメッセージ認証モジュール：このメディアタイプを使用するアプリケーション。
Additional information:
追加情報：
Magic number(s): N/A
マジックナンバー（S）：N / A
File extension(s): N/A
ファイルの拡張子（秒）：N / A
Macintosh file type code(s): N/A
Macintoshのファイルタイプコード（S）：N / A
Person and email address to contact for further information: Murray S. Kucherawy <msk@cloudmark.com>
Personと詳細のために連絡する電子メールアドレス：マレーS. Kucherawy <msk@cloudmark.com>
Intended usage: common
意図している用法：共通
Restrictions on usage: none; however, other applications that register report types may establish such restrictions.
使用に関する制限事項：なし。ただし、レポートタイプを登録し、他のアプリケーションでは、このような制限を確立することができます。
Author: Murray S. Kucherawy <msk@cloudmark.com>
著者：マレーS. Kucherawy <msk@cloudmark.com>
Change controller: IESG
変更コントローラ：IESG
The syntax of multipart/report is identical to the multipart/mixed content type defined in [MIME]. The report-type parameter identifies the type of report. The parameter is the MIME subtype of the second body part of the multipart/report. (See Section 5.)
マルチパート/レポートの構文は、[MIME]で定義される混合/マルチパートコンテンツタイプと同一です。レポートタイプのパラメータは、レポートの種類を識別します。パラメータは、マルチパート/レポートの第2の本体部分のMIMEサブタイプです。 （第5節を参照してください）
The multipart/report media type contains either two or three sub-parts, in the following order:
マルチパート/レポートのメディアタイプは、次の順序で、二、三のサブ部品のいずれかが含まれています。
1. (REQUIRED) The first body part contains a human-readable message. The purpose of this message is to provide an easily understood description of the condition(s) that caused the report to be generated, for a human reader who might not have a user agent capable of interpreting the second section of the multipart/ report. The text in the first section can use any IANA-registered MIME media type, charset, or language. Where a description of the error is desired in several languages or several media, a multipart/alternative construct MAY be used. This body part MAY also be used to send detailed information that cannot be easily formatted into the second body part.
1.（必須）第1のボディ部分は、人間が読めるメッセージを含みます。このメッセージの目的は、マルチパート/レポートの第2のセクションを解釈することが可能なユーザエージェントを持っていないかもしれない人間の読者のために、レポートが生成される原因となった条件（複数可）の容易に理解される説明を提供することです。最初のセクション内のテキストは、任意のIANAに登録MIMEメディアタイプ、文字セットまたは言語を使用することができます。エラーの説明は、いくつかの言語または複数のメディアに所望される場合、マルチパート/代替構成物を使用することができます。この本体部分は、また、容易に第2のボディ部分にフォーマットすることができない詳細な情報を送信するために使用され得ます。
2. (REQUIRED) A machine-parsable body part containing an account of the reported message handling event. The purpose of this body part is to provide a machine-readable description of the condition(s) that caused the report to be generated, along with details not present in the first body part that might be useful to human experts. An initial body part, message/delivery-status, is defined in [DSN-FORMAT].
2.（必須）イベントを処理する報告メッセージのアカウントを含む機械解析可能な身体の部分。この本文部分の目的は、人間の専門家に有用であるかもしれない第1の本体部分には存在しない詳細と共に、レポートが生成される原因となった条件（複数可）の機械読み取り可能な説明を提供することです。最初の身体の部分、メッセージ/配送状況は、[DSN-FORMAT]で定義されています。
3. (OPTIONAL) A body part containing the returned message or a portion thereof. This information could be useful to aid human experts in diagnosing problems. (Although it might also be useful to allow the sender to identify the message about which the report was issued, it is hoped that the envelope-id and original-recipient-address returned in the message/report body part will replace the traditional use of the returned content for this purpose.)
3.（オプション）返されたメッセージまたはその一部を含む身体の部分は。この情報は、問題の診断に人間の専門家を支援するために有用である可能性があります。それはまた、送信者が報告書が発行されたかについてのメッセージを識別することを可能にするのに便利かもしれませんが（メッセージ/レポート身体の部分に返さ封筒-idと、元の受信者アドレスは、伝統的な使用を置き換えることが期待されますこの目的のために返されるコンテンツ。）
Return of content can be wasteful of network bandwidth and a variety of implementation strategies can be used. Generally, the sender needs to choose the appropriate strategy and inform the recipient of the required level of returned content required. In the absence of an explicit request for level of return of content such as that provided in [DSN-SMTP], the agent that generated the delivery service report SHOULD return the full message content.
コンテンツの戻り値は、ネットワーク帯域幅の浪費することができ、実装戦略の様々な使用することができます。一般的に、送信者は、適切な戦略を選択し、必要な返されたコンテンツの必要なレベルの受信者に通知する必要があります。このような[DSN-SMTP]で提供されるようなコンテンツのリターンのレベルの明示的な要求が存在しない場合に、配信サービスレポートを生成エージェントは、完全なメッセージの内容を返すべきです。
When 8-bit or binary data not encoded in a 7-bit form is to be returned, and the return path is not guaranteed to be 8-bit or binary capable, two options are available. The original message MAY be re-encoded into a legal 7-bit MIME message or the text/rfc822-headers media type MAY be used to return only the original message headers.
8ビットまたはバイナリデータ7ビット形式でエンコードされていない場合に返される、リターンパスが8ビットまたはバイナリ可能であることが保証されていない、2つのオプションが利用可能です。元のメッセージは、法的7ビットのMIMEメッセージに再エンコードしてもよく、またはテキスト/ RFC822-ヘッダメディアタイプは、元のメッセージヘッダを返すために使用されるかもしれません。
The text/rfc822-headers media type provides a mechanism to label and return only the [MAIL] header of a failed message. The header is not the complete message and SHOULD NOT be returned using the message/ rfc822 media type defined in [MIME-TYPES]. The returned header is useful for identifying the failed message and for diagnostics based on the Received header fields.
テキスト/ RFC822-ヘッダメディアタイプは、ラベル及び失敗したメッセージの唯一[MAIL]ヘッダを返すための機構を提供します。ヘッダは、完全なメッセージではなく、[MIMEタイプ]で定義されたメッセージ/ RFC822メディアタイプを使用して返されるべきではありません。返されたヘッダは、失敗したメッセージを識別するためと受信ヘッダフィールドに基づいて診断するのに有用です。
The text/rfc822-headers media type is defined as follows:
次のようにテキスト/ RFC822-ヘッダのメディアタイプが定義されます。
Type name: text
型名：テキスト
Subtype name: rfc822-headers
サブタイプ名：RFC822-ヘッダ
Required parameters: None
必須パラメータ：なし
Optional parameters: None
オプションのパラメータ：なし
Encoding considerations: 7-bit is sufficient for normal mail headers, however, if the headers are broken or extended and require encoding to make them legal 7-bit content, they MAY be encoded with quoted-printable as defined in [MIME].
符号の考慮：ヘッダが破損したり拡張し、それらに法的7ビットのコンテンツを作るために符号化を必要としている場合[MIME]で定義されるように7ビットが通常のメールヘッダには十分であるが、しかし、それらは引用-印刷可能で符号化することができます。
Security considerations: See Section 7 of [RFC6522].
セキュリティの考慮事項：[RFC6522]のセクション7を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: [RFC6522]
公開された仕様：[RFC6522]
Applications that use this media type: Mail Transfer Agents, Mail User Agents, spam detection and reporting modules, virus detection modules, and message authentication modules.
メール転送エージェント、メールユーザエージェント、スパム検出および報告モジュール、ウイルス検出モジュール、およびメッセージ認証モジュール：このメディアタイプを使用するアプリケーション。
Additional information:
追加情報：
Magic number(s): N/A
マジックナンバー（S）：N / A
File extension(s): N/A
ファイルの拡張子（秒）：N / A
Macintosh file type code(s): N/A
Macintoshのファイルタイプコード（S）：N / A
Person and email address to contact for further information: Murray S. Kucherawy <msk@cloudmark.com>
Personと詳細のために連絡する電子メールアドレス：マレーS. Kucherawy <msk@cloudmark.com>
Intended usage: common
意図している用法：共通
Restrictions on usage: none
使用に関する制限事項：なし
Author: Murray S. Kucherawy <msk@cloudmark.com>
著者：マレーS. Kucherawy <msk@cloudmark.com>
Change controller: IESG
変更コントローラ：IESG
The text/rfc822-headers body part SHOULD contain all the mail header fields from the message that caused the report. The header includes all header fields prior to the first blank line in the message. They include the MIME-Version and MIME content description fields.
テキスト/ RFC822-ヘッダー本体部は、レポートを発生させたメッセージからすべてのメールヘッダフィールドを含むべきです。ヘッダは、メッセージの最初の空白行の前にあるすべてのヘッダフィールドを含んでいます。彼らは、MIME-バージョンとMIMEコンテンツの説明フィールドを含みます。
Registration of new media types for the purpose of creating a new report format SHOULD note in the Intended Usage section of the media type registration that the type being registered is suitable for use as a report-type (i.e., the second body part) in the context of this specification.
タイプが登録されるメディアタイプ登録の意図された使用法セクションに注意するべき新たなレポートフォーマットを作成するために新しいメディアタイプの登録は（すなわち、第2のボディ部分）レポート・タイプとして使用するのに適しています本明細書の文脈。
IANA has updated the Media Type Registry to indicate that this memo contains the current definition of the multipart/report and text/ rfc822-headers media types, obsoleting [OLD-REPORT].
IANAは[OLD-REPORT]を時代遅れに、このメモは、マルチパート/レポートおよびテキスト/ RFC822-ヘッダのメディアタイプの現在の定義が含まれていることを示すために、メディアタイプのレジストリを更新しました。
Automated use of report types without authentication presents several security issues. Forging negative reports presents the opportunity for denial-of-service attacks when the reports are used for automated maintenance of directories or mailing lists. Forging positive reports can cause the sender to incorrectly believe a message was delivered when it was not.
認証なしレポートタイプの自動使用は、いくつかのセキュリティ問題を提示します。レポートはディレクトリやメーリングリストの自動化、メンテナンスのために使用されたときに否定的な報告を鍛造することは、サービス拒否攻撃の機会を提供します。ポジティブレポートを鍛造することは、送信者が誤ってそれがなかったときにメッセージが配信されたと信じさせることができます。
A signature covering the entire multipart/report structure could be used to prevent such forgeries; such a signature scheme is, however, beyond the scope of this document.
全体のマルチパート/レポート構造を覆う署名は、偽造を防止するために使用することができます。そのような署名方式は、この文書の範囲を超えて、しかし、です。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[MAIL]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[MIME-REG] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[MIME-REG]フリード、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME-TYPES]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[DSN-FORMAT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN-FORMAT]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。
[DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN-SMTP]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[OLD-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[OLD-REPORT]ヴォードルイユ、G.、RFC 3462、2003年1月、 "メールシステムの管理メッセージの報告のための複合/レポートのコンテンツタイプ"。
Appendix A. Acknowledgements
付録A.謝辞
The author would like to thank Dave Crocker, Frank Ellermann, Ned Freed, Randall Gellens, Alexey Melnikov, and Keith Moore for their input to this update.
著者はこの更新への入力のためにデーブクロッカー、フランクEllermann、ネッドフリード、ランドールGellens、アレクセイ・メルニコフ、およびキースムーアに感謝したいと思います。
Thanks also go to Gregory M. Vaudreuil, the original creator of this media type.
おかげでまたグレゴリーM.ヴォードルイユ、このメディアタイプの原作者に行きます。
Author's Address
著者のアドレス
Murray S. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US
マレーS. Kucherawy（エディタ）Cloudmarkの128キングセント、2階サンフランシスコ、CA 94107米国
Phone: +1 415 946 3800 EMail: msk@cloudmark.com
電話：+1 415 946 3800 Eメール：msk@cloudmark.com