[要約] RFC 6522は、メールシステムの管理メッセージの報告のためのMultipart/Reportメディアタイプについての規格です。このRFCの目的は、メールシステムのエラーや警告などの管理メッセージを効果的に報告するための標準化を提供することです。
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.
MultiPart/Report Multipurpose Internet Mail Extensions（MIME）メディアタイプは、あらゆる種類の電子メールレポートの一般的な「ファミリー」または「コンテナ」タイプです。このメモは、配信ステータスレポートに関してマルチパート/レポートメディアタイプの使用のみを定義していますが、あらゆる種類のレポートに単一のメディアタイプが使用される場合、メール処理プログラムはメリットがあります。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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メッセージの一部としてレポートを転送することを防ぎます。
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を廃止します。RFC3462とその前身である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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されているように解釈されます。
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
タイプ名：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
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: Murray
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>
Change controller: IESG
Change Controller：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.)
MultiPart/レポートの構文は、[MIME]で定義されているマルチパート/混合コンテンツタイプと同一です。レポートタイプのパラメーターは、レポートのタイプを識別します。パラメーターは、MultiPart/Reportの2番目のボディ部分のMIMEサブタイプです。（セクション5を参照）
The multipart/report media type contains either two or three sub-parts, in the following order:
マルチパート/レポートメディアタイプには、次の順序で2つまたは3つのサブパートが含まれています。
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
1. （必須）最初のボディパーツには、人間が読めるメッセージが含まれています。このメッセージの目的は、マルチパート/レポートの2番目のセクションを解釈できないユーザーエージェントを持たない人間の読者に、レポートを生成した条件の簡単に理解できる説明を提供することです。最初のセクションのテキストでは、IANA登録されたMIMEメディアタイプ、CharSet、または言語を使用できます。エラーの説明がいくつかの言語で望まれている場合、または
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.
いくつかのメディア、マルチパート/代替構造を使用できます。この本体部分は、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. （必須）報告されたメッセージ処理イベントのアカウントを含む機械型のボディパーツ。この身体部分の目的は、レポートを生成した条件の機械読み取り可能な説明と、人間の専門家にとって有用な最初の身体部分に存在しない詳細を提供することです。最初のボディ部分、メッセージ/配信ステータスは、[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.
7ビット形式でエンコードされていない8ビットまたはバイナリデータが返され、リターンパスが8ビットまたはバイナリの有能であることが保証されていない場合、2つのオプションが利用可能です。元のメッセージは、合法的な7ビットMIMEメッセージに再エンコードされる場合があります。または、テキスト/RFC822-Headersメディアタイプを使用して、元のメッセージヘッダーのみを返すことができます。
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.
Text/RFC822-Headersメディアタイプは、失敗したメッセージの[メール]ヘッダーのみにラベルを付けて返すメカニズムを提供します。ヘッダーは完全なメッセージではなく、[mime-types]で定義されたメッセージ/ rfc822メディアタイプを使用して返されるべきではありません。返されたヘッダーは、失敗したメッセージを識別し、受信したヘッダーフィールドに基づいた診断に役立ちます。
The text/rfc822-headers media type is defined as follows:
テキスト/RFC822-Headersメディアタイプは、次のように定義されています。
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ビットは通常のメールヘッダーに十分ですが、ヘッダーが破損または拡張され、合法的な7ビットコンテンツを作成するためにエンコードが必要な場合は、[MIME]で定義されていると引用されたプリント可能でエンコードされる場合があります。
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
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: Murray
S. Kucherawy <msk@cloudmark.com>
Intended usage: common
意図された使用法：共通
Restrictions on usage: none
使用に関する制限：なし
Author: Murray S. Kucherawy <msk@cloudmark.com>
Change controller: IESG
Change Controller：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.
Text/RFC822-Headersボディの部分には、レポートを引き起こしたメッセージからすべてのメールヘッダーフィールドを含める必要があります。ヘッダーには、メッセージの最初の空白行の前にすべてのヘッダーフィールドが含まれます。それらには、mime-versionおよび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は、メディアタイプのレジストリを更新して、このメモにマルチパート/レポートとテキスト/ 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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P.、ed。、「インターネットメッセージ形式」、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] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[MIME-REG] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[Mime-Types] Freed、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-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN-SMTP] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、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] Vaudreuil、G。、「メールシステム管理メッセージのレポートのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。
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.
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
Murray S. Kucherawy（編集者）Cloudmark 128 King St.、2階サンフランシスコ、CA 94107 US
Phone: +1 415 946 3800
EMail: msk@cloudmark.com