[要約] RFC 5965は、電子メールフィードバックレポートのための拡張可能なフォーマットを提供しています。このRFCの目的は、電子メールの配信状況やスパムフィルタリングの結果などの情報を効果的に共有するための標準化を促進することです。
Internet Engineering Task Force (IETF) Y. Shafranovich
Request for Comments: 5965 ShafTek Enterprises
Category: Standards Track J. Levine
ISSN: 2070-1721 Taughannock Networks
M. Kucherawy
Cloudmark
August 2010
An Extensible Format for Email Feedback Reports
電子メールフィードバックレポートの拡張可能な形式
Abstract
概要
This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email.
このドキュメントでは、郵便物オペレーターが受け取った電子メールに関するフィードバックを他の関係者に報告するために使用できる拡張可能な形式とMIMEタイプを定義します。この形式は、インターネットメールで現在使用されているさまざまな既存のレポート形式の機械可読機関として意図されています。
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/rfc5965.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5965で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Purpose ....................................................3
1.2. Requirements ...............................................4
1.3. Definitions ................................................4
1.3.1. General .............................................4
1.3.2. Email Specific ......................................4
2. Format of Email Feedback Reports ................................4
3. The 'message/feedback-report' Content Type ......................5
3.1. Required Fields ............................................6
3.2. Optional Fields Appearing Once .............................6
3.3. Optional Fields Appearing Multiple Times ...................7
3.4. Notes about URIs ...........................................8
3.5. Formal Definition ..........................................8
4. Handling Malformed Reports .....................................10
5. Transport Considerations .......................................10
6. Extensibility ..................................................10
7. IANA Considerations ............................................11
7.1. MIME Type Registration of 'message/feedback-report' .......11
7.2. Feedback Report Header Fields .............................12
7.3. Feedback Report Type Values ...............................15
8. Security Considerations ........................................17
8.1. Inherited from RFC 3462 ...................................17
8.2. Interpretation ............................................17
8.3. Attacks against Authentication Methods ....................17
8.4. Intentionally Malformed Reports ...........................18
8.5. Omitting Data from ARF Reports ............................18
8.6. Automatically Generated ARF Reports .......................18
8.7. Attached Malware ..........................................18
8.8. The User-Agent Field ......................................18
8.9. Malformed Messages ........................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Acknowledgements .....................................22
Appendix B. Sample Feedback Reports ..............................22
B.1. Simple Report for Email Abuse without Optional Headers ...22
B.2. Full Report for Email Abuse with All Headers .............23
As the spam problem continues to expand and potential solutions evolve, mail operators are increasingly exchanging abuse reports among themselves and other parties. However, different operators have defined their own formats, and thus the receivers of these reports are forced to write custom software to interpret each of them. In addition, many operators use various other report formats to provide non-abuse-related feedback about processed email. This memo uses the "multipart/report" content type defined in [REPORT], and in that context defines a standard extensible format by creating the "message/feedback-report" [MIME] type for these reports.
スパムの問題が拡大し続け、潜在的なソリューションが進化するにつれて、メールオペレーターは、彼ら自身や他の当事者の間で虐待報告をますます交換しています。ただし、異なるオペレーターが独自のフォーマットを定義しているため、これらのレポートの受信機は、それぞれを解釈するためにカスタムソフトウェアを作成することを余儀なくされています。さらに、多くのオペレーターは、他のさまざまなレポート形式を使用して、処理された電子メールに関する虐待関連のフィードバックを提供します。このメモは、[レポート]で定義された「マルチパート/レポート」コンテンツタイプを使用し、そのコンテキストでは、これらのレポートに「メッセージ/フィードバックレポート」[MIME]タイプを作成することにより、標準の拡張可能な形式を定義します。
While there has been previous work in this area (e.g., [STRADS-BCP] and [ASRG-ABUSE]), none of it has yet been successful. It is hoped that this document will have a better fate.
この分野で以前の作業がありましたが（例：[Strads-BCP]および[Asrg-Abuse]）、どれもまだ成功していません。この文書がより良い運命を持つことが期待されています。
This format is intended primarily as an Abuse Reporting Format (ARF) for reporting email abuse but also includes support for direct feedback via end user mail clients, reports of some types of virus activity, and some similar issues. This memo also contains provision for extensions should other specific types of reports be desirable in the future.
この形式は、主に電子メールの乱用を報告するための乱用報告書（ARF）として意図されていますが、エンドユーザーメールクライアントによる直接フィードバックのサポート、いくつかのタイプのウイルス活動のレポート、およびいくつかの同様の問題も含まれています。このメモには、他の特定の種類のレポートが将来望ましい場合、拡張の規定も含まれています。
This document only defines the format and [MIME] content type to be used for these reports. Determination of where these reports should be sent, validation of their contents, and how trust among report generators and report recipients is established are outside the scope of this document. It is assumed that best practices will evolve over time, and will be codified in future documents.
このドキュメントは、これらのレポートに使用される形式と[MIME]コンテンツタイプのみを定義します。これらのレポートをどこに送信すべきか、コンテンツの検証、およびレポートジェネレーターとレポート受信者間の信頼がこのドキュメントの範囲外であることを決定します。ベストプラクティスは時間とともに進化し、将来の文書で成文化されると想定されています。
The reports defined in this document are intended to inform mail operators about:
このドキュメントで定義されているレポートは、メールオペレーターに次のことを通知することを目的としています。
o email abuse originating from their networks;
o ネットワークから発信される電子メールの乱用。
o potential issues with the perceived quality of outbound mail, such as email service providers sending mail that attracts the attention of automated abuse detection systems.
o 自動化された乱用検出システムの注意を引き付けるメールを送信する電子メールサービスプロバイダーなど、アウトバウンドメールの知覚される品質に関する潜在的な問題。
Please note that while the parent "multipart/report" content type defined in [REPORT] is used for all kinds of administrative messages, this format is intended specifically for communications among providers regarding email abuse and related issues, and SHOULD NOT be used for other reports.
[レポート]で定義されている親の「マルチパート/レポート」コンテンツタイプはあらゆる種類の管理メッセージに使用されていますが、この形式は電子メールの乱用や関連する問題に関するプロバイダー間のコミュニケーション向けであり、他の人には使用しないでください。報告。
The following requirements are necessary for feedback reports (the actual specification is defined later in this document):
フィードバックレポートには、以下の要件が必要です（実際の仕様は、このドキュメントの後半で定義されています）。
o They must be both human and machine readable;
o それらは人間と機械の両方が読みやすくなければなりません。
o A copy of the original email message (both body and header) or the message header must be enclosed in order to allow the receiver to handle the report properly;
o 受信者がレポートを適切に処理できるようにするには、元の電子メールメッセージ（ボディとヘッダーの両方）またはメッセージヘッダーを囲む必要があります。
o The machine-readable section must provide ability for the report generators to share meta-data with receivers;
o マシン読み取り可能なセクションは、レポートジェネレーターがメタデータを受信機と共有する能力を提供する必要があります。
o The format must be extensible.
o フォーマットは拡張可能でなければなりません。
This section defines various terms used throughout this document.
このセクションでは、このドキュメント全体で使用されるさまざまな用語を定義します。
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月」、および「オプション」は、[キーワード]で説明されているように解釈されます。
[EMAIL-ARCH] introduces several terms and concepts that are used in this memo, and thus readers are advised to become familiar with it as well.
[email-arch]は、このメモで使用されているいくつかの用語と概念を紹介するため、読者も同様に慣れることをお勧めします。
To satisfy the requirements, an email feedback report is defined as a [MIME] message with a top-level MIME content type of "multipart/ report" (as defined in [REPORT]). The following apply:
要件を満たすために、電子メールフィードバックレポートは、[MultiPart/ Report]（[レポート]で定義されている）のトップレベルMIMEコンテンツタイプの[MIME]メッセージとして定義されます。次の適用：
a. The "report-type" parameter of the "multipart/report" type is set to "feedback-report";
a. 「マルチパート/レポート」タイプの「レポートタイプ」パラメーターは、「フィードバックレポート」に設定されています。
b. The first MIME part of the message contains a human-readable description of the report and MUST be included.
b. メッセージの最初のmime部分には、レポートの人間が読みやすい説明が含まれており、含める必要があります。
c. The second MIME part of the message is a machine-readable section with the content type of "message/feedback-report" (defined later in this memo) and MUST be included. This section is intended to convey meta-data about the report in question that may not be readily available from the included email message itself.
c. メッセージの2番目のmime部分は、コンテンツタイプの「メッセージ/フィードバックレポート」（このメモで後で定義）を備えたマシン読み取り可能なセクションで、含める必要があります。このセクションは、含まれている電子メールメッセージ自体から容易に入手できない可能性のある問題のレポートについてメタデータを伝えることを目的としています。
d. The third MIME part of the message is either of type "message/ rfc822" (as defined in [MIME-TYPES]) and contains the original message in its entirety OR is of type "text/rfc822-headers" (as defined in [REPORT]) and contains a copy of the entire header block from the original message. This part MUST be included (contrary to [REPORT]). While some operators may choose to modify or redact this portion for privacy or legal reasons, it is RECOMMENDED that the entire original email message be included without any modification as such modifications can impede forensic work by the recipient of this report. See Section 8 for further discussion.
d. メッセージの3番目のmime部分は、「メッセージ/ rfc822」のタイプ（[mime-types]で定義）のいずれかで、元のメッセージ全体が含まれているか、「テキスト/ rfc822ヘッダー」というタイプ（[で定義されています。レポート]）および元のメッセージからヘッダーブロック全体のコピーが含まれています。この部分を含める必要があります（[レポート]に反して）。一部のオペレーターは、プライバシーまたは法的理由でこの部分を変更または編集することを選択する場合がありますが、このレポートの受信者による法医学的な作業を妨げる可能性があるため、修正なしで元の電子メールメッセージ全体を含めることをお勧めします。詳細については、セクション8を参照してください。
e. Except as discussed below, each feedback report MUST be related to only a single email message. Summary and aggregate formats are outside of the scope of this specification.
e. 以下で説明する場合を除き、各フィードバックレポートは、単一の電子メールメッセージのみに関連している必要があります。要約形式と集約形式は、この仕様の範囲外です。
f. The Subject header field of the feedback report SHOULD be the same as the included email message about which the report is being generated. If it differs, the difference MUST be limited to only a typical forwarding prefix used by Mail User Agents (MUAs) such as "FW:". (Many smaller operators using MUAs for abuse handling rely on the subject lines for processing.)
f. フィードバックレポートのサブジェクトヘッダーフィールドは、レポートが生成されていることについて含まれた電子メールメッセージと同じでなければなりません。それが異なる場合、違いは、「FW：」などのメールユーザーエージェント（MUA）が使用する典型的な転送プレフィックスのみに制限する必要があります。（乱用の取り扱いにMUAを使用している多くの小規模なオペレーターは、処理に件名に依存しています。）
g. The primary evidence of the abuse being reported is found in the third part of the report, which contains the original message. The second part contains additional derived data that may help the receiver, but in terms of selecting actionable report data, report recipients SHOULD use the content of the third part first, then data from the second part. The first part is meant to contain explanatory text for human use but is not itself a part of the report, and SHOULD NOT be used if it is in conflict with the other parts.
g. 報告されている虐待の主な証拠は、元のメッセージを含むレポートの第3部にあります。2番目の部分には、受信機に役立つ可能性のある追加の派生データが含まれていますが、実用的なレポートデータを選択するという点では、レポート受信者は最初に第3部のコンテンツを使用し、次に2番目の部分からのデータを使用する必要があります。最初の部分は、人間の使用のための説明テキストを含めることを目的としていますが、それ自体がレポートの一部ではなく、他の部分と矛盾している場合は使用しないでください。
A new [MIME] content type called "message/feedback-report" is defined. This content type provides a machine-readable section intended to let the report generator convey meta-data to the report receiver. The intent of this section is to convey information that may not be obvious or may not be easily extracted from the original email message body or header.
「メッセージ/フィードバックレポート」と呼ばれる新しい[MIME]コンテンツタイプが定義されています。このコンテンツタイプは、レポートジェネレーターがメタデータをレポートレシーバーに伝えることを目的とした機械読み取り可能なセクションを提供します。このセクションの意図は、明白ではない可能性のある情報を伝えたり、元の電子メールメッセージ本文またはヘッダーから簡単に抽出されない可能性がある情報を伝えることです。
The body of this content type consists of multiple "fields" formatted according to the ABNF of [MAIL] header fields. This section defines the initial set of fields provided by this specification. Additional fields may be registered according to the procedure described later in this memo. Although these fields have a syntax similar to those of mail message header fields, they are semantically distinct; hence, they SHOULD NOT be repeated as header fields of the message containing the report. Note that these fields represent information that the receiver is asserting about the report in question, but are not necessarily verifiable. Report receivers MUST NOT assume that these assertions are always accurate.
このコンテンツタイプの本文は、[メール]ヘッダーフィールドのABNFに従ってフォーマットされた複数の「フィールド」で構成されています。このセクションでは、この仕様で提供されるフィールドの初期セットを定義します。このメモで後で説明した手順に従って、追加のフィールドを登録できます。これらのフィールドには、メールメッセージヘッダーフィールドのフィールドと同様の構文がありますが、意味的には異なります。したがって、レポートを含むメッセージのヘッダーフィールドとして繰り返されるべきではありません。これらのフィールドは、受信者が問題のレポートについて主張しているが、必ずしも検証可能ではないという情報を表していることに注意してください。レポートレシーバーは、これらのアサーションが常に正確であると想定してはなりません。
Note that the above limitation in no way restricts the use of message header fields that are registered in the IANA header field registry with the same field names.
上記の制限は、同じフィールド名を持つIANAヘッダーフィールドレジストリに登録されているメッセージヘッダーフィールドの使用を決して制限しないことに注意してください。
The following report header fields MUST appear exactly once:
次のレポートヘッダーフィールドは、正確に1回表示する必要があります。
o "Feedback-Type" contains the type of feedback report (as defined in the corresponding IANA registry and later in this memo). This is intended to let report parsers distinguish among different types of reports.
o 「フィードバックタイプ」には、フィードバックレポートのタイプが含まれています（対応するIANAレジストリで定義されており、後でこのメモで定義されています）。これは、レポートパーサーにさまざまな種類のレポートを区別できるようにすることを目的としています。
o "User-Agent" indicates the name and version of the software program that generated the report. The format of this field MUST follow section 14.43 of [HTTP]. This field is for documentation only; there is no registry of user agent names or versions, and report receivers SHOULD NOT expect user agent names to belong to a known set.
o 「ユーザーエージェント」は、レポートを生成したソフトウェアプログラムの名前とバージョンを示します。このフィールドの形式は、[HTTP]のセクション14.43に従う必要があります。このフィールドはドキュメント専用です。ユーザーエージェント名またはバージョンのレジストリはありません。レポート受信者は、ユーザーエージェント名が既知のセットに属することを期待してはなりません。
o "Version" indicates the version of specification that the report generator is using to generate the report. The version number in this specification is set to "1".
o 「バージョン」は、レポートジェネレーターがレポートを生成するために使用している仕様のバージョンを示します。この仕様のバージョン番号は「1」に設定されています。
The following header fields are optional and MUST NOT appear more than once:
次のヘッダーフィールドはオプションであり、複数回表示してはなりません。
o "Original-Envelope-Id" contains the envelope ID string used in the original [SMTP] transaction (see section 2.2.1 of [DSN]).
o 「Original-Envelope-ID」には、元の[SMTP]トランザクションで使用されているエンベロープID文字列が含まれています（[DSN]のセクション2.2.1を参照）。
o "Original-Mail-From" contains a copy of the email address used in the MAIL FROM portion of the original SMTP transaction. The format of this field is defined in section 4.1.2 of [SMTP] as "Reverse-path".
o 「Original-Mail-from」には、元のSMTPトランザクションの一部からメールで使用される電子メールアドレスのコピーが含まれています。このフィールドの形式は、[smtp]のセクション4.1.2で「逆パス」として定義されています。
o "Arrival-Date" indicates the date and time at which the original message was received by the Mail Transfer Agent (MTA) of the generating ADMD (Administrative Management Domain). This field MUST be formatted as per section 3.3 of [MAIL].
o 「到着日」は、生成admd（管理管理ドメイン）のメール転送エージェント（MTA）によって元のメッセージが受信された日付と時刻を示します。このフィールドは、[メール]のセクション3.3に従ってフォーマットする必要があります。
o "Reporting-MTA" indicates the name of the MTA generating this feedback report. This field is defined in section 2.2.2 of [DSN], except that it is an optional field in this report.
o 「Reporting-MTA」は、このフィードバックレポートを生成するMTAの名前を示します。このフィールドは、[DSN]のセクション2.2.2で定義されていますが、このレポートのオプションフィールドであることを除きます。
o "Source-IP" contains an IPv4 or IPv6 address of the MTA from which the original message was received. Addresses MUST be formatted as per section 4.1.3 of [SMTP].
o 「Source-IP」には、元のメッセージが受信されたMTAのIPv4またはIPv6アドレスが含まれています。[SMTP]のセクション4.1.3に従って、アドレスをフォーマットする必要があります。
o "Incidents" contains an unsigned 32-bit integer indicating the number of incidents this report represents. The absence of this field implies the report covers a single incident.
o 「インシデント」には、このレポートが表すインシデントの数を示す署名されていない32ビット整数が含まれています。このフィールドがないことは、レポートが単一のインシデントをカバーすることを意味します。
The historic field "Received-Date" SHOULD also be accepted and interpreted identically to "Arrival-Date". However, if both are present, the report is malformed and SHOULD be treated as described in Section 4.
歴史的な分野の「受信日」も受け入れられ、「到着日」と同じように解釈されるべきです。ただし、両方が存在する場合、レポートは奇形であり、セクション4で説明されているように扱う必要があります。
The following set of header fields are optional and may appear any number of times as appropriate:
次のヘッダーフィールドのセットはオプションであり、必要に応じて何度も表示される場合があります。
o "Authentication-Results" indicates the result of one or more authentication checks run by the report generator. The format of this field is defined in [AUTH-RESULTS]. Report receivers should note that this field only indicates an assertion made by the report generator.
o 「認証応答」は、レポートジェネレーターによって実行される1つ以上の認証チェックの結果を示します。このフィールドの形式は[auth-results]で定義されています。レポートレシーバーは、このフィールドはレポートジェネレーターによって行われたアサーションのみを示していることに注意する必要があります。
o "Original-Rcpt-To" includes a copy of the email address used in the RCPT TO portion of the original [SMTP] transaction. The format of this field is a "Reverse-path" defined in section 4.1.2 of that memo. This field SHOULD be repeated for every SMTP recipient seen by the report generator.
o 「Original-RCPT-to」には、RCPTで使用される電子メールアドレスのコピーが元の[SMTP]トランザクションの一部に含まれています。このフィールドの形式は、そのメモのセクション4.1.2で定義されている「逆パス」です。このフィールドは、レポートジェネレーターで見られるすべてのSMTPレシピエントに対して繰り返される必要があります。
o "Reported-Domain" includes a domain name that the report generator believes to be relevant to the report, e.g., the domain whose apparent actions provoked the generation of the report. It is unspecified how the report generator determines this information, and thus the report receiver cannot be certain how it was chosen. It is often used as a means of suggesting to the report receiver how this report might be handled. In cases where the derivation is not obvious, the report generator is encouraged to clarify in the text section of the report. Domain format is defined in section 2.3.1 of [DNS].
o 「Report-Domain」には、レポートジェネレーターがレポートに関連すると考えているドメイン名、たとえば、レポートの生成を引き起こした明らかなアクションがそのドメインを含んでいます。レポートジェネレーターがこの情報を決定する方法は特定されていないため、レポートレシーバーはそれがどのように選択されたかを確認できません。これは、このレポートがどのように処理されるかをレポート受信者に提案する手段としてよく使用されます。派生が明らかでない場合、レポートジェネレーターはレポートのテキストセクションで明確にすることをお勧めします。ドメイン形式は、[DNS]のセクション2.3.1で定義されています。
o "Reported-URI" indicates a URI that the report generator believes to be relevant to the report, e.g., a suspect URI that was found in the message that caused the report to be generated. The same caveats about the origin of the value of "Reported-Domain" apply to this field. The URI format is defined in [URI].
o 「Report-URI」は、レポートジェネレーターがレポートに関連していると考えているURIを示しています。「報告されたドメイン」の値の起源についての同じ注意がこのフィールドに適用されます。URI形式は[URI]で定義されています。
Implementors should be aware that the Reported-URI field can carry many different types of data depending on the URI scheme used. For more information, please consult the "URI Schemes" registry maintained by IANA.
実装者は、報告されたURIフィールドが使用されるURIスキームに応じて、さまざまな種類のデータを運ぶことができることに注意する必要があります。詳細については、IANAが管理する「URIスキーム」レジストリを参照してください。
Furthermore, it is outside the scope of this standard whether the data carried in this field implies any additional information. Implementors may negotiate their own agreements surrounding the interpretation of this data.
さらに、このフィールドで運ばれたデータが追加情報を暗示するかどうかは、この標準の範囲外です。実装者は、このデータの解釈をめぐる独自の契約を交渉する場合があります。
The formal definition of the contents of a "message/feedback-report" media type using [ABNF] is as follows:
[ABNF]を使用した「メッセージ/フィードバックレポート」メディアタイプの内容の正式な定義は次のとおりです。
feedback-report = *( feedback-type / user-agent / version )
opt-fields-once
*( opt-fields-many )
*( ext-field )
feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF ; the "token" must be a registered feedback type as ; described elsewhere in this document
Feedback-Type = "Feedback-Type：" [cfws] token [cfws] crlf;「トークン」は、登録されたフィードバックタイプでなければなりません。このドキュメントの他の場所で説明されています
user-agent = "User-Agent:" [CFWS] product *( CFWS product ) [CFWS] CRLF
user-agent = "user-agent：" [cfws] product *（cfws product）[cfws] crlf
version = "Version:" [CFWS] %x31-39 *DIGIT [CFWS] CRLF
; as described above
opt-fields-once = [ arrival-date ]
[ incidents ]
[ original-envelope-id ]
[ original-mail-from ]
[ reporting-mta ]
[ source-ip ]
arrival-date = "Arrival-Date:" [CFWS] date-time CRLF
arvion-date = "Arrival-date：" [cfws] date-time crlf
incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF
; must be a 32-bit unsigned integer
original-envelope-id = "Original-Envelope-Id:" [CFWS] envelope-id [CFWS] CRLF
Original-Envelope-id = "original-envelope-id：" [cfws] envelope-id [cfws] crlf
original-mail-from = "Original-Mail-From:" [CFWS] reverse-path [CFWS] CRLF
Original-mail-from = "original-mail-from：" [cfws] reverse-path [cfws] crlf
reporting-mta = "Reporting-MTA:" [CFWS] mta-name-type [CFWS] ";" [CFWS] mta-name [CFWS] CRLF
Reporting-Mta = "Reporting-Mta：" [cfws] mta-name-type [cfws] ";"[cfws] mta-name [cfws] crlf
source-ip = "Source-IP:" [CFWS] ( IPv4-address-literal / IPv6-address-literal ) [CFWS] CRLF
source-ip = "source-ip：" [cfws]（ipv4-address-literal / ipv6-address-literal）[cfws] crlf
opt-fields-many = [ authres-header ]
[ original-rcpt-to ]
[ reported-domain ]
[ reported-uri ]
original-rcpt-to = "Original-Rcpt-To:" [CFWS] forward-path [CFWS] CRLF
original-rcpt-to = "original-rcpt-to：" [cfws] forward-path [cfws] crlf
reported-domain = "Reported-Domain:" [CFWS] domain [CFWS] CRLF
Report-Domain = "Report-Domain：" [cfws] domain [cfws] crlf
reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF
Report-uri = "Report-uri：" [cfws] uri [cfws] crlf
ext-field = field-name ":" unstructured
ext-field = field-name "："非構造化
A set of fields satisfying this ABNF may appear in the transmitted message in any order.
このABNFを満たす一連のフィールドは、送信されたメッセージに任意の順序で表示される場合があります。
"CRLF" and "DIGIT" are imported from [ABNF].
「CRLF」と「Digit」は[ABNF]からインポートされます。
"token" is imported from [MIME].
「トークン」は[Mime]からインポートされます。
"product" is imported from [HTTP].
「製品」は[http]からインポートされます。
"field-name", "unstructured", "CFWS", "date-time", and "domain" are imported from [MAIL].
「フィールド名」、「非構造化」、「CFWS」、「日付時」、および「ドメイン」は[メール]からインポートされます。
"envelope-id", "mta-name-type", and "mta-name" are imported from [DSN].
「Envelope-ID」、「MTA-Name-Type」、および「MTA-Name」は[DSN]からインポートされます。
"reverse-path", "forward-path", "local-part", "IPv4-address-literal", and "IPv6-address-literal" are imported from [SMTP].
「リバースパス」、「フォワードパス」、「ローカルパート」、「IPv4-Address-Literal」、および「IPv6-Address-Literal」は[SMTP]からインポートされます。
"URI" is imported from [URI].
「URI」は[URI]からインポートされています。
"authres-header" is imported from [AUTH-RESULTS].
「authres-header」は[auth-results]からインポートされています。
"ext-field" refers to extension fields, which are discussed in Section 6.
「ext-field」とは、セクション6で説明されている拡張フィールドを指します。
When an agent that accepts and handles ARF messages receives a message that purports (by MIME type) to be an ARF message but syntactically deviates from this specification, that agent SHOULD ignore or reject the message. Where rejection is performed, the rejection notice (either via an [SMTP] reply or generation of a [DSN]) SHOULD identify the specific cause for the rejection.
ARFメッセージを受け入れて処理するエージェントが、（MIMEタイプごとに）ARFメッセージであるがこの仕様から構文的に逸脱するメッセージを受信する場合、そのエージェントはメッセージを無視または拒否する必要があります。拒否が行われる場合、拒否通知（[smtp]返信または[dsn]の生成のいずれか）は、拒絶の特定の原因を特定する必要があります。
See Section 8.9 for further discussion.
詳細については、セクション8.9を参照してください。
[DSN] requires that its reports be sent with the empty [SMTP] envelope sender to avoid bounce loops. A similar requirement was considered for this specification, but it seems unlikely that an ARF report would be generated in response to receipt of an ARF report, and furthermore such a requirement would prevent an ARF generator from ever determining that an ARF report was not actually received.
[DSN]は、バウンスループを避けるために、空の[SMTP]エンベロープ送信者とともにレポートを送信する必要があります。この仕様でも同様の要件が考慮されましたが、ARFレポートの受領に応じてARFレポートが生成される可能性は低く、さらにそのような要件により、ARFジェネレーターがARFレポートが実際に受信されないと判断することができなくなります。。
On the other hand, if an ARF report is generated without the empty envelope sender and is sent to an address that actually does not work, then the generating address can also be overwhelmed by DSNs as a denial-of-service attack (see Section 8.6).
一方、ARFレポートが空のエンベロープ送信者なしで生成され、実際には機能しないアドレスに送信される場合、生成アドレスはサービス拒否攻撃としてDSNSによって圧倒されることもあります（セクション8.6を参照）。
This specification therefore makes no requirement related to the envelope sender of a generated report. Operators will have to consider what envelope sender to use within the context of their own installations.
したがって、この仕様は、生成されたレポートのエンベロープ送信者に関連する要件を作成しません。オペレーターは、自分のインストールのコンテキスト内で使用する封筒送信者を考慮する必要があります。
Like many other formats and protocols, this format may need to be extended over time to fit the ever-changing landscape of the Internet. Therefore, extensibility is provided via two IANA registries: one for feedback types and a second for report header fields. The feedback type registry is to be used in conjunction with the "Feedback-Type" field above. The header name registry is intended for registration of new meta-data fields to be used in the machine-readable portion (part 2) of this format. Please note that version numbers do not change with new field registrations unless a new specification of this format is published. Also, note that all new field registrations may only be registered as optional fields. Any new required fields REQUIRE a new version of this specification to be published.
他の多くの形式やプロトコルと同様に、この形式は、インターネットの絶えず変化する風景に合わせて時間の経過とともに拡張する必要がある場合があります。したがって、拡張性は、2つのIANAレジストリを介して提供されます。1つはフィードバックタイプ用、レポートヘッダーフィールドには2つ目です。フィードバックタイプレジストリは、上記の「フィードバックタイプ」フィールドと組み合わせて使用されます。ヘッダー名レジストリは、この形式の機械可読部分（パート2）で使用する新しいメタデータフィールドの登録を目的としています。この形式の新しい仕様が公開されていない限り、バージョン番号は新しいフィールド登録で変更されないことに注意してください。また、すべての新しいフィールド登録は、オプションのフィールドとしてのみ登録される場合があることに注意してください。新しい必要なフィールドでは、この仕様の新しいバージョンを公開する必要があります。
In order to encourage extensibility and interoperability of this format, implementors MUST ignore any fields or report types they do not explicitly support.
この形式の拡張性と相互運用性を促進するために、実装者は明示的にサポートしていないフィールドまたはレポートタイプを無視する必要があります。
Additional report types (extension report types) or report header fields might be defined in the future by later revisions to this specification, or by registrations as described above. Such types and fields MUST be registered as described above and published in an Open Specification such as an RFC.
追加のレポートタイプ（拡張レポートタイプ）またはレポートヘッダーフィールドは、この仕様の後の改訂、または上記の登録によって将来定義される場合があります。このようなタイプとフィールドは、上記のように登録し、RFCなどのオープン仕様で公開する必要があります。
Experimental report types and report header fields MUST only be used between ADMDs that have explicitly consented to use them. These names and the parameters associated with them are not documented in RFCs. Therefore, they are subject to change at any time and are not suitable for general use.
実験的なレポートタイプとレポートヘッダーフィールドは、それらを使用することに明示的に同意したADMD間でのみ使用する必要があります。これらの名前とそれらに関連するパラメーターは、RFCSで文書化されていません。したがって、それらはいつでも変更される可能性があり、一般的な使用には適していません。
IANA has registered a new [MIME] type and created two new registries, as described below.
IANAは新しい[MIME]タイプを登録し、以下に説明するように2つの新しいレジストリを作成しました。
This section provides the media type registration application from [MIME-REG] for processing by IANA:
このセクションでは、IANAによる処理のための[Mime-Reg]からのメディアタイプの登録アプリケーションを提供します。
To: ietf-types@iana.org
宛先：ietf-types@iana.org
Subject: Registration of media type message/feedback-report
件名：メディアタイプのメッセージ/フィードバックレポートの登録
Type name: message
タイプ名：メッセージ
Subtype name: feedback-report
サブタイプ名：フィードバックレポート
Required parameters: none
必要なパラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers.
考慮事項のエンコーディング：「7ビット」エンコードで十分であり、非mimeメールリーダーが表示する場合、読みやすさを維持するために使用する必要があります。
Security considerations: See Section 8 of [RFC5965].
セキュリティ上の考慮事項：[RFC5965]のセクション8を参照してください。
Interoperability considerations: Implementors MUST ignore any fields they do not support.
相互運用性の考慮事項：実装者は、サポートしていないフィールドを無視する必要があります。
Published specification: [RFC5965]
公開された仕様：[RFC5965]
Applications that use this media type: Abuse helpdesk software for ISPs, mail service bureaus, mail certifiers, and similar organizations
このメディアタイプを使用するアプリケーション：ISPS、郵便サービス局、郵便証明書、および同様の組織向けのabuse helpdeskソフトウェア
Additional information: none
追加情報：なし
Person and email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Yakov Shafranovich <ietf@shaftek.org>
Murray S. Kucherawy <msk@cloudmark.com>
Intended usage: COMMON
意図された使用法：共通
Author:
著者：
Yakov Shafranovich
ヤコフ・シャフラノビッチ
John R. Levine
ジョン・R・レヴァイン
Murray S. Kucherawy
マレー・S・クチェラウィ
Change controller: IESG
Change Controller：IESG
IANA has created the "Feedback Report Header Fields" registry. This registry contains header fields for use in feedback reports, as defined by this memo.
IANAは「フィードバックレポートヘッダーフィールド」レジストリを作成しました。このレジストリには、このメモで定義されているように、フィードバックレポートで使用するヘッダーフィールドが含まれています。
New registrations or updates MUST be published in accordance with the "Specification Required" guidelines as described in [IANA]. Any new field thus registered is considered optional by this specification unless a new version of this memo is published.
[IANA]に記載されているように、新しい登録または更新は「必要な仕様」ガイドラインに従って公開する必要があります。このように登録された新しいフィールドは、このメモの新しいバージョンが公開されない限り、この仕様によってオプションと見なされます。
New registrations and updates MUST contain the following information:
新しい登録と更新には、次の情報が含まれている必要があります。
1. Name of the field being registered or updated
1. 登録または更新されるフィールドの名前
2. Short description of the field 3. Whether the field can appear more than once
2. フィールドの短い説明3.フィールドが複数回表示できるかどうか
4. To which feedback type(s) this field applies (or "any")
4. フィードバックタイプには、このフィールドが適用されます（または「任意」）
5. The document in which the specification of the field is published
5. フィールドの仕様が公開されている文書
6. New or updated status, which MUST be one of:
6. 新規または更新されたステータスは、次のいずれかでなければなりません。
current: The field is in current use
現在：フィールドは現在使用されています
deprecated: The field is in current use but its use is discouraged
非推奨：フィールドは現在使用されていますが、その使用は落胆しています
historic: The field is no longer in current use
歴史的：フィールドはもはや現在使用されていません
An update may make a notation on an existing registration indicating that a registered field is historic or deprecated if appropriate.
更新により、登録フィールドが必要に応じて歴史的または非推奨であることを示す既存の登録の表記が作成される場合があります。
The initial registry contains these values:
初期レジストリにはこれらの値が含まれています。
Field Name: Arrival-Date Description: date/time the original message was received Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：到着日説明：日付/時刻元のメッセージが複数の外観を受信しました：関連する「フィードバックタイプ」：任意の公開：[RFC5965]ステータス：現在
Field Name: Authentication-Results Description: results of authentication check(s) Multiple Appearances: Yes Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：認証復元説明：認証チェックの結果複数の外観：はい関連する「フィードバックタイプ」：任意の公開：[RFC5965]ステータス：現在
Field Name: Feedback-Type Description: registered feedback report type Multiple Appearances: No Related "Feedback-Type": N/A Published in: [RFC5965] Status: current Field Name: Incidents Description: expression of how many similar incidents are represented by this report Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：フィードバックタイプの説明：登録フィードバックレポートタイプ複数の外観：関連する「フィードバックタイプ」：N/A公開：[RFC5965]ステータス：現在のフィールド名：インシデント説明：同様のインシデントの表現このレポート複数の外観：関連する「フィードバックタイプ」はありません：[RFC5965]ステータス：現在の公開：現在
Field Name: Original-Mail-From Description: email address used in the MAIL FROM portion of the original SMTP transaction Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：オリジナルメールからの説明：元のSMTPトランザクションの一部からのメールで使用される電子メールアドレス複数の外観：関連する「フィードバックタイプ」：[RFC5965]ステータス：現在の公開：現在
Field Name: Original-Rcpt-To Description: email address used in the RCPT TO portion of the original SMTP transaction Multiple Appearances: Yes Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：Original-RCPT-to説明：元のSMTPトランザクションの一部にRCPTで使用される電子メールアドレス複数の外観：はい関連「フィードバックタイプ」：任意の公開：[RFC5965]ステータス：現在
Field Name: Received-Date Description: date/time the original message was received (replaced by "Arrival-Date") Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: historic
フィールド名：受信日説明：日付/時刻元のメッセージが受信されました（「到着日」に置き換えられました」複数の外観：関連する「フィードバックタイプ」：[RFC5965]ステータス：[RFC5965]ステータス：任意
Field Name: Reported-Domain Description: a domain name the report generator considers to be key to the message about which a report is being generated Multiple Appearances: Yes Related "Feedback-Type": any Published in: [RFC5965] Status: current Field Name: Reported-URI Description: a URI the report generator considers to be key to the message about which a report is being generated Multiple Appearances: Yes Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：報告ドメイン説明：ドメイン名レポートジェネレーターは、レポートが生成されているメッセージの鍵であると考える複数の外観：はい関連「フィードバックタイプ」：公開：[RFC5965]ステータス：現在のフィールド名前：報告-URI説明：uRIレポートジェネレーターは、レポートが生成されているメッセージの鍵であると考えています。
Field Name: Reporting-MTA Description: MTA generating this report Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：レポート-MTA説明：このレポートを生成するMTA複数の外観：関連する「フィードバックタイプ」：任意の公開：[RFC5965]ステータス：現在
Field Name: Source-IP Description: IPv4 or IPv6 address from which the original message was received Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：Source-IP説明：元のメッセージが受信されたIPv4またはIPv6アドレス複数の外観：関連する「フィードバックタイプ」：任意の公開：[RFC5965]ステータス：現在
Field Name: User-Agent Description: name and version of the program generating the report Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：ユーザーエージェント説明：レポートの生成プログラムの名前とバージョン複数の外観：関連する「フィードバックタイプ」：任意の公開：[RFC5965]ステータス：現在
Field Name: Version Description: version of specification used Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
フィールド名：バージョンの説明：使用された仕様のバージョン複数の外観：関連する「フィードバックタイプ」：任意の公開：[rfc5965]ステータス：現在
IANA has created the "Feedback Report Type Values" registry. This registry contains feedback types for use in feedback reports, defined by this memo.
IANAは「フィードバックレポートタイプ値」レジストリを作成しました。このレジストリには、このメモで定義されたフィードバックレポートで使用するフィードバックタイプが含まれています。
New registrations or updates MUST be published in accordance with the "Specification Required" guidelines as described in [IANA]. Any new field thus registered is considered optional by this specification unless a new version of this memo is published.
[IANA]に記載されているように、新しい登録または更新は「必要な仕様」ガイドラインに従って公開する必要があります。このように登録された新しいフィールドは、このメモの新しいバージョンが公開されない限り、この仕様によってオプションと見なされます。
New registrations MUST contain the following information:
新しい登録には、次の情報が含まれている必要があります。
1. Name of the feedback type being registered
1. 登録されているフィードバックタイプの名前
2. Short description of the feedback type
2. フィードバックタイプの短い説明
3. The document in which the specification of the field is published
3. フィールドの仕様が公開されている文書
4. New or updated status, which MUST be one of:
4. 新規または更新されたステータスは、次のいずれかでなければなりません。
current: The field is in current use
現在：フィールドは現在使用されています
deprecated: The field is in current use but its use is discouraged
非推奨：フィールドは現在使用されていますが、その使用は落胆しています
historic: The field is no longer in current use
歴史的：フィールドはもはや現在使用されていません
The initial registry contains these values:
初期レジストリにはこれらの値が含まれています。
Feedback Type Name: abuse Description: unsolicited email or some other kind of email abuse Published in: [RFC5965] Status: current
フィードバックタイプ名：乱用の説明：未承諾の電子メールまたは公開されている他の種類の電子メールの悪用：[RFC5965]ステータス：現在
Feedback Type Name: fraud Description: indicates some kind of fraud or phishing activity Published in: [RFC5965] Status: current
フィードバックタイプ名：詐欺の説明：[RFC5965]ステータス：現在の詐欺またはフィッシング活動の種類を示します
Feedback Type Name: other Description: any other feedback that does not fit into other registered types Published in: [RFC5965] Status: current
フィードバックタイプ名：その他の説明：[RFC5965]ステータス：現在の登録型タイプに適合しないその他のフィードバック
Feedback Type Name: virus Description: report of a virus found in the originating message Published in: [RFC5965] Status: current
フィードバックタイプ名：ウイルスの説明：[RFC5965]ステータス：現在の発行メッセージにあるウイルスのレポート：現在
The following security considerations apply when generating or processing a feedback report:
フィードバックレポートを生成または処理するときに、次のセキュリティに関する考慮事項が適用されます。
All of the Security Considerations from [REPORT] are inherited here.
[レポート]からのセキュリティ上の考慮事項はすべて、ここで継承されています。
This specification describes a report format. The authentication and validity of the content of the report SHOULD be established through other means. The content of an unvetted report could be wrong, incomplete or deliberately false, including the alleged abuse incident in the third part, derived data in the second part or the human-readable first part.
この仕様には、レポート形式が記載されています。レポートのコンテンツの認証と有効性は、他の手段を通じて確立する必要があります。未開のレポートの内容は、第3部での虐待事件の疑い、第2部の派生データ、または人間の読み取り可能な第1部を含む、間違っている、不完全または故意に虚偽である可能性があります。
There will be some desire to perform some actions in an automated fashion in order to enact timely responses to common feedback reports. Caution must be taken, however, as there is no substantial security around the content of these reports. An attacker could craft a report meant to generate undesirable actions on the part of a report recipient.
一般的なフィードバックレポートに対するタイムリーな応答を実現するために、自動化された方法でいくつかのアクションを実行したいという欲求があります。ただし、これらのレポートの内容に関する実質的なセキュリティはないため、注意が必要です。攻撃者は、レポートの受信者側に望ましくないアクションを生成することを目的としたレポートを作成できます。
It is suggested that the origin of an ARF report be vetted, such as by using common message authentication schemes like [SMIME], [DKIM], [SPF], or [SENDERID], prior to the undertaking of any kind of automated action in response to receipt of the report. In particular, S/MIME offers the strongest authentication and the cost of key exchange is assumed in the process of establishing a bilateral reporting relationship that uses this specification; however, it is not as transparent as the others and thus will interfere with the parsing capabilities of code that is designed specifically to handle multipart/report messages.
[SMIME]、[DKIM]、[SPF]、または[SenderID]などの一般的なメッセージ認証スキームを使用するなど、ARFレポートの起源は、あらゆる種類の自動化されたアクションが実施する前に、[SENDERID]などの一般的なメッセージ認証スキームを使用するなどして吟味されることが示唆されています。報告書の受領への応答。特に、S/MIMEは最も強力な認証を提供し、主要な交換のコストは、この仕様を使用する二国間報告関係を確立するプロセスで想定されています。ただし、他のものほど透明ではないため、マルチパート/レポートメッセージを処理するために特別に設計されたコードの解析機能に干渉します。
The details of the required validation to achieve this are a matter of local policy and are thus outside the scope of this specification.
これを達成するために必要な検証の詳細はローカルポリシーの問題であり、したがって、この仕様の範囲外です。
If an attack becomes known against an authentication method, clearly then the agent verifying that method can be fooled into thinking an inauthentic message is authentic, and thus the value of this header field can be misleading. It follows that any attack against an authentication method that might be used to protect the authenticity of an abuse report is also a security consideration here.
認証方法に対して攻撃が知られるようになると、明らかにその方法を確認するエージェントは、不正なメッセージが本物であると考えるようにだまされる可能性があるため、このヘッダーフィールドの値は誤解を招く可能性があります。したがって、虐待レポートの信頼性を保護するために使用される可能性のある認証方法に対する攻撃も、ここでのセキュリティに関する考慮事項です。
It is possible for an attacker to generate an ARF message field that is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in recipient parsing code. Implementors SHOULD thoroughly verify all such messages and be robust against intentionally as well as unintentionally malformed messages.
攻撃者は、レシピエントの解析コードの弱点を発見または悪用するために、非常に大きい、または不正されているARFメッセージフィールドを生成することができます。実装者は、そのようなすべてのメッセージをすべて徹底的に検証し、意図的に不正なメッセージに対して意図的に、および意図的に不正なメッセージに対して堅牢である必要があります。
The sending of these reports can reveal possibly private information about the person sending the report. For example, such a report sent in response to a mailing list posting will reveal to the report recipient a valid email address on the list that might otherwise have remained hidden.
これらのレポートを送信すると、レポートを送信する人に関する個人情報が明らかになります。たとえば、メーリングリストの投稿に応答して送信されたこのようなレポートは、レポートの受信者にリストの有効な電子メールアドレスを明らかにします。
For this reason, report generators might wish to redact portions of the report to conceal private information. Doing so could be necessary where privacy trumps operational necessity, but, as mentioned in Section 2, it might impede a timely or meaningful response from the report recipient.
このため、レポートジェネレーターは、報告書の一部を編集して個人情報を隠したい場合があります。プライバシーが運用上の必要性に勝る場合に必要な場合がありますが、セクション2で述べたように、レポートの受信者からのタイムリーまたは意味のある応答を妨げる可能性があります。
Systems have been implemented that generate ARF reports automatically in response to an event. For example, software monitoring a honeypot email address might generate an ARF report immediately upon delivery of any message to it. An attacker that becomes aware of such a configuration can exploit it to attack an ARF recipient with automatically generated ARF reports.
イベントに応じてARFレポートを自動的に生成するシステムが実装されています。たとえば、Honeypotのメールアドレスを監視するソフトウェアは、メッセージを配信するとすぐにARFレポートを生成する可能性があります。このような構成に気付く攻撃者は、自動的に生成されたARFレポートでARFレシピエントを攻撃するためにそれを悪用することができます。
As this format is sometimes used to automatically report malware, ARF processors (human or otherwise) SHOULD ensure that attachments are processed in a manner appropriate for unverified and potentially hostile data.
この形式はマルウェアを自動的に報告するために使用される場合があるため、ARFプロセッサ（人間またはその他）は、添付ファイルが未確認の潜在的に敵対的なデータに適した方法で処理されるようにする必要があります。
Further to Section 8.2, the User-Agent field is an assertion of the generating software and is neither specified in this memo nor derived from the message represented in the third part of the report. It is intended for documentation and debugging, and since it is trivially forged by a malicious agent, it SHOULD NOT be interpreted by recipients.
セクション8.2にさらに、ユーザーエージェントフィールドは生成ソフトウェアのアサーションであり、このメモで指定されていないことも、レポートの3番目の部分で表されるメッセージからも導き出されていません。ドキュメントとデバッグを目的としており、悪意のあるエージェントによって些細なことに鍛造されているため、受信者によって解釈されるべきではありません。
Further to the discussion in Section 4, there might be cases where an ARF processing agent elects to accept messages not consistent with this specification, such as during transition periods where some fields are moving toward "historic" or "deprecated" status, or the introduction of new non-standard extension or experimental fields. Such choices need to be implemented with extreme caution; where two different fields have related meaning (e.g., "Received-Date", which is historic, and "Arrival-Date", which is current), an attacker could craft a report that makes a confusing claim in an attempt to exploit such liberal parsing logic.
セクション4の議論に加えて、ARF処理剤が、一部のフィールドが「歴史的」または「非推奨」ステータスに移行している移行期間中、または導入部など、この仕様と一致しないメッセージを受け入れることを選択する場合がある場合があります。新しい非標準拡張または実験フィールドの。このような選択は、非常に注意して実装する必要があります。2つの異なるフィールドに関連する意味がある場合（例：歴史的な「受信日」、「到着日」、最新の「到着日」）、攻撃者は、そのようなリベラルを悪用するために混乱する主張をする報告書を作成できます。解析ロジック。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[Auth-Results] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 5451、2009年4月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[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-Reg] Freed、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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[レポート] Vaudreuil、G。、「メールシステム管理メッセージのレポートのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[ASRG-ABUSE] Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF), "Abuse Reporting Standards Subgroup of the ASRG", May 2005.
[ASRG-ABUSE]インターネット研究タスクフォース（IRTF）の反スパム研究グループ（ASRG）、「ASRGの虐待報告基準サブグループ」、2005年5月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[Dkim] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J。、およびM. Thomas、「Domainkeys Idefied Mail（DKIM）署名」、RFC 4871、2007年5月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[メールアーチ] Crocker、D。、「Internet Mail Architecture」、RFC 5598、2009年7月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[Senderid] Lyon、J。およびM. Wong、「送信者ID：認証電子メール」、RFC 4406、2006年4月。
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[Smime] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF] Wong、M。およびW. Schlitt、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 4408、2006年4月。
[STRADS-BCP] Crissman, G., "Proposed Spam Reporting BCP Document", May 2005.
[Strads-BCP] Crissman、G。、「提案されたスパム報告BCPドキュメント」、2005年5月。
The authors would like to thank many of the members of the email community who provided helpful comments and suggestions for this document including many of the participants in ASRG, IETF, and MAAWG activities, and all of the members of the abuse-feedback-report public mailing list.
著者は、ASRG、IETF、およびMAAWG活動の多くの参加者、およびAubsion-Feedback-Reportのすべてのメンバーを含むこのドキュメントに有益なコメントと提案を提供してくれたメールコミュニティのメンバーの多くに感謝したいと思います。メーリングリスト。
This section presents some examples of the use of this message format to report feedback about an arriving message.
このセクションでは、このメッセージ形式の使用の例を示して、到着するメッセージに関するフィードバックを報告します。
Simple report:
簡単なレポート：
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information about this format please see http://www.mipassoc.org/arf/.
これは、2005年3月8日のThuのIP 192.0.2.1から受け取った電子メールメッセージの電子メール乱用レポートです。この形式の詳細については、http：//www.mipassoc.org/arf/を参照してください。
--part1_13d.2e68ed54_boundary Content-Type: message/feedback-report
-PART1_13D.2E68ED54_BOUNDARY CONTENT-TYPE：メッセージ/フィードバックレポート
Feedback-Type: abuse User-Agent: SomeGenerator/1.0 Version: 1
フィードバックタイプ：Aubsion User-Agent：SomeGenerator/1.0バージョン：1
--part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline
-PART1_13D.2E68ED54_BOUNDARY CONTENT-TYPE：MESSAGE/RFC822コンテンツ - 分散：インライン
Received: from mailserver.example.net (mailserver.example.net [192.0.2.1]) by example.com with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 -0400
受信：ESMTP ID M63D4137594E46を使用したExample.comによるMailServer.example.net（MailServer.example.net [192.0.2.1]）から。Thu、2005年3月8日14:00:00 -0400
From: <somespammer@example.net>
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500
Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam --part1_13d.2e68ed54_boundary--
スパムスパムスパムスパムスパムスパムスパムスパムスパムスパムスパム-PART1_13D.2E68ED54_BOUNDARY--
Example 1: Required fields only
例1：必須フィールドのみ
Illustration of a feedback report generated according to this specification. Only the required fields are used.
この仕様に従って生成されたフィードバックレポートの図。必要なフィールドのみが使用されます。
A full email abuse report:
完全な電子メールの悪用レポート：
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information about this format please see http://www.mipassoc.org/arf/.
これは、2005年3月8日のThuのIP 192.0.2.1から受け取った電子メールメッセージの電子メール乱用レポートです。この形式の詳細については、http：//www.mipassoc.org/arf/を参照してください。
--part1_13d.2e68ed54_boundary Content-Type: message/feedback-report
-PART1_13D.2E68ED54_BOUNDARY CONTENT-TYPE：メッセージ/フィードバックレポート
Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
Reporting-MTA: dns; mail.example.com
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com;
spf=fail smtp.mail=somespammer@example.com
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html
Reported-Uri: mailto:user@example.com
Removal-Recipient: user@example.com
--part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline
-PART1_13D.2E68ED54_BOUNDARY CONTENT-TYPE：MESSAGE/RFC822コンテンツ - 分散：インライン
From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
Thu, 08 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500
Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam --part1_13d.2e68ed54_boundary--
スパムスパムスパムスパムスパムスパムスパムスパムスパムスパムスパム-PART1_13D.2E68ED54_BOUNDARY--
Example 1: Generic abuse report with maximum returned information
例1：最大の返品情報を含む一般的な虐待レポート
A contrived example in which the report generator has returned all possible information about an abuse incident.
レポートジェネレーターが虐待事件に関するすべての可能な情報を返した不自然な例。
Authors' Addresses
著者のアドレス
Yakov Shafranovich ShafTek Enterprises 4014 Labyrinth Rd. Baltimore, MD 21215 US
Yakov Shafranovich Shaftek Enterprises 4014 Labyrinth Rd。ボルチモア、MD 21215 US
EMail: ietf@shaftek.org
URI: http://www.shaftek.org
John R. Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 US
ジョンR.レバインタウガノックネットワークPOボックス727トルーマンスバーグ、ニューヨーク14886米国
Phone: +1 831 480 2300
EMail: standards@taugh.com
Murray S. Kucherawy 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