Network Working Group G. Vaudreuil
Request for Comments: 3462 Lucent Technologies
Obsoletes: 1892 January 2003
Category: Standards Track
The Multipart/Report Content Type
for the Reporting of
Mail System Administrative Messages
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-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 content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.
マルチパート/レポートMIME（Multipurpose Internet Mail Extensions）コンテンツタイプは、あらゆる種類の電子メールレポートのための一般的な「家族」や「コンテナ」タイプです。このメモは、配送状態レポートに関して、マルチパート/レポートのコンテンツタイプの使用のみを定義していますが、単一のコンテンツ・タイプは、レポートのすべての種類のために使用されている場合、メール処理プログラムが利益になります。
This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure.
この文書では、配信ステータスレポートサービスを記述した4つのドキュメントセットの一部です。このコレクションは、簡易メール転送プロトコル（SMTP）配送状態レポート、配信レポートの報告、拡張ステータスコードの列挙、および配信レポートのためのマルチパートの容器、オリジナルメッセージのMIMEコンテンツを要求するための拡張機能、および含み故障の人に優しい要約。
Table of Contents
目次
Document Conventions................................................2
1. The Multipart/Report Content Type................................2
2. The Text/RFC822-Headers..........................................4
3. Security Considerations..........................................4
4. Normative References.............................................5
Appendix A - Changes from RFC 1893..................................6
Author's Address....................................................6
Full Copyright Statement............................................7
Document Conventions
ドキュメントの表記規則
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
The Multipart/Report MIME content-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 content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.
マルチパート/レポートMIMEコンテンツタイプは、あらゆる種類の電子メールレポートのための一般的な「家族」や「コンテナ」タイプです。このメモは、配送状態レポートに関して、マルチパート/レポートのコンテンツタイプの使用のみを定義していますが、単一のコンテンツ・タイプは、レポートのすべての種類のために使用されている場合、メール処理プログラムが利益になります。
The Multipart/Report content-type is defined as follows:
次のようにマルチパート/レポートのコンテンツタイプが定義されます。
MIME type name: multipart MIME subtype name: report Required parameters: boundary, report-type Optional parameters: none Encoding considerations: 7bit should always be adequate Security considerations: see section 3 of this memo
MIMEタイプ名：マルチパートMIMEサブタイプ名：レポート必須パラメータ：境界、レポート型オプションのパラメータ：なしエンコードの考慮事項：7ビットは、常に十分なセキュリティ上の考慮事項次のようになります。このメモのセクション3を参照してください
The syntax of Multipart/Report is identical to the Multipart/Mixed content type defined in [MIME]. When used to send a report, the Multipart/Report content-type must be the top-level MIME content type for any report message. The report-type parameter identifies the type of report. The parameter is the MIME content sub-type of the second body part of the Multipart/Report.
マルチパート/レポートの構文は、[MIME]で定義されたマルチパート/混合コンテンツ・タイプと同じです。レポートを送信するために使用される場合は、マルチパート/レポートコンテンツタイプは、任意のレポートメッセージのトップレベルMIMEコンテンツタイプでなければなりません。レポートタイプのパラメータは、レポートの種類を識別します。パラメータは、マルチパート/レポートの第2のボディ部分のMIMEコンテンツサブタイプです。
User agents and gateways must be able to automatically determine that a message is a mail system report and should be processed as such. Placing the Multipart/Report as the outermost content provides a mechanism whereby an auto-processor may detect through parsing the RFC 822 headers that the message is a report.
ユーザーエージェントやゲートウェイは、自動的にメッセージがメールシステムレポートであり、そのように処理されるべきであると決定することができる必要があります。最も外側のコンテンツとしてマルチパート/レポートを配置する自動プロセッサは、メッセージがレポートであるRFC 822ヘッダを解析を通じて検出できる機構を提供します。
The Multipart/Report content-type contains either two or three sub-parts, in the following order:
マルチパート/レポートコンテンツタイプは、次の順序で二、三のサブパーツ、のいずれかが含まれています。
1) [Required] The first body part contains 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 may not have a user agent capable of interpreting the second section of the Multipart/Report.
1）[必須]第1の本体部分は、人間が読み取り可能なメッセージを含みます。このメッセージの目的は、マルチパート/レポートの第2の部分を解釈することが可能なユーザエージェントを持っていない可能性が人間の読者のために、レポートが生成される原因となった条件（複数可）の容易に理解される説明を提供することです。
The text in the first section may be in any MIME standards-track content-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.
最初のセクション内のテキストは、任意のMIME標準トラックのコンテンツ・タイプ、文字セットまたは言語であってもよいです。エラーの説明は、いくつかの言語または複数のメディアに所望される場合、マルチパート/代替構築物を使用することができます。
This body part may also be used to send detailed information that cannot be easily formatted into a Message/Report body part.
この身体の部分にも簡単にメッセージ/レポート身体の部分にフォーマットすることができない詳細な情報を送信するために使用することができます。
(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 may be useful to human experts. An initial body part, Message/delivery-status is defined in [DSN].
（2）[必須]イベントを処理する報告メッセージのアカウントを含む機械解析可能な身体の部分を。この本文部分の目的は、人間の専門家に有用であり得る第1のボディ部分に存在しない詳細と共に、レポートが生成される原因となった条件（複数可）の機械読み取り可能な説明を提供することです。最初のボディ部、メッセージ/配送ステータスが[DSN]で定義されています。
(3) [Optional] A body part containing the returned message or a portion thereof. This information may be useful to aid human experts in diagnosing problems. (Although it may also be useful to allow the sender to identify the message 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 may be wasteful of network bandwidth and a variety of implementation strategies can be used. Generally the sender should 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 [DRPT], the agent that generated the delivery service report should return the full message content.
コンテンツの戻り値は、ネットワーク帯域幅の浪費することができ、実装戦略の様々な使用することができます。一般的に、送信者は、適切な戦略を選択し、必要な返されたコンテンツの必要なレベルの受信者に通知する必要があります。このような【DRPT]で提供されるようなコンテンツのリターンのレベルの明示的な要求が存在しない場合に、配信サービスレポートを生成エージェントは、完全なメッセージの内容を返すべきです。
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 content-type MAY be used to return only the original message headers.
8ビットまたはバイナリデータ7ビット形式でエンコードされていない場合に返される、リターンパスが8ビットまたはバイナリ可能であることが保証されていない、2つのオプションが利用可能です。元のメッセージは、法的7ビットのMIMEメッセージに再エンコードしてもよく、またはテキスト/ RFC822-ヘッダのコンテンツタイプは、元のメッセージヘッダを返すために使用されるかもしれません。
The Text/RFC822-Headers MIME content-type provides a mechanism to label and return only the RFC 822 headers of a failed message. These headers are not the complete message and should not be returned as a Message/RFC822. The returned headers are useful for identifying the failed message and for diagnostics based on the received lines.
テキスト/ RFC822-ヘッダMIMEコンテンツタイプは、失敗したメッセージの唯一のRFC 822ヘッダを標識し、返すための機構を提供します。これらのヘッダは完全なメッセージではなく、メッセージ/ RFC822として返されるべきではありません。返されたヘッダーは失敗したメッセージを識別するため、受信した行に基づいて診断するのに有用です。
The Text/RFC822-Headers content-type is defined as follows:
次のようにテキスト/ RFC822-ヘッダのコンテンツタイプが定義されます。
MIME type name: Text MIME subtype name: RFC822-Headers Required parameters: None Optional parameters: None Encoding considerations: 7 bit is sufficient for normal RFC822 headers, however, if the headers are broken and require encoding to make them legal 7 bit content, they may be encoded in quoted-printable. Security considerations: See section 3 of this memo.
MIMEタイプ名：テキストMIMEサブタイプ名：RFC822-ヘッダ必須パラメータ：なしオプションのパラメータ：なしエンコードの考慮事項：ヘッダが壊れて、それらに法的な7ビットのコンテンツを作るための符号化を必要としている場合は7ビットは、しかし、通常のRFC822ヘッダのために十分です、彼らはquoted-printable形式でエンコードすることができます。セキュリティの考慮事項：このメモのセクション3を参照してください。
The Text/RFC822-Headers body part should contain all the RFC822 header lines from the message which caused the report. The RFC822 headers include all lines prior to the blank line in the message. They include the MIME-Version and MIME Content-Headers.
テキスト/ RFC822-ヘッダー本体部は、レポートを発生させたメッセージからすべてのRFC822ヘッダ行を含むべきです。 RFC822ヘッダはメッセージに空白行の前にすべての行を含みます。彼らは、MIME-バージョンとMIMEのContent-ヘッダが含まれます。
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 may 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.
全体のマルチパート/レポート構造を覆う署名は、偽造を防止するために使用することができます。そのような署名方式は、この文書の範囲を超えて、しかし、です。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN]ムーア、K.、およびG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME] Borenstein、N.とN.フリード、 "多目的インターネットメール拡張（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[DRPT] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 3461, January 2003.
[DRPT]ムーア、K.、 "配送状態通知のためのSMTPサービス拡張"、RFC 3461、2003年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Appendix A - Changes from RFC 1892
付録A - RFC 1892からの変更点
Changed Authors contact information
変更された著者は、連絡先情報
Updated required standards boilerplate
更新に必要な基準定型
Edited the text to make it spell-checker and grammar checker compliant
それはスペルチェッカーおよび文法チェッカーを準拠させるために、テキストを編集しました
Author's Address
著者のアドレス
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas Tx, 75214
グレゴリーM.ヴォードルイユルーセント・テクノロジーズ7291ウィリアムソンRdのテキサス州ダラス、75214
Phone: +1 214 823 9325 EMail: GregV@ieee.org
電話：+1 214 823 9325 Eメール：GregV@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。