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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
スパム問題が拡大し続けており、潜在的なソリューションが進化するにつれ、メール事業者はますます自分自身や他の関係者の間で乱用報告書を交換しています。しかし、異なる事業者が独自のフォーマットを定義しているため、これらのレポートの受信機は、それらのそれぞれを解釈するためのカスタムソフトウェアを書くことを余儀なくされています。また、多くの事業者が処理、電子メールに関する非乱用関連のフィードバックを提供するために、他のさまざまなレポート形式を使用します。このメモは[REPORT]で定義された「マルチパート/レポート」コンテンツタイプを使用し、その文脈で「メッセージ/フィードバック・レポート」を作成することにより、標準的な拡張可能なフォーマットを定義[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乱用]）この領域では以前の研究がなされているが、そのどれもが、まだ成功していません。この文書は、より良い運命を持っていることが期待されます。
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.
[REPORT]で定義された親「マルチパート/レポート」コンテンツタイプは、管理メッセージのすべての種類のために使用されるが、この形式は、電子メールの乱用と関連する問題についてのプロバイダ間の通信のために具体的に意図されている、および他のために使用すべきではないことに注意してくださいレポート。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
[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:
要件を満たすために、電子メールフィードバックレポートは、（[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。メッセージの第二の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。メッセージの第三のMIME部分は、タイプ（[MIMEタイプ]で定義されるように）とで定義されるように（「テキスト/ RFC822-ヘッダを」その全体が元のメッセージを含んでいるか、またはタイプである「メッセージ/ RFC822」のいずれかです[ REPORT]）と、元のメッセージから全体ヘッダーブロックのコピーを含みます。この部分は、（[REPORT]とは逆）を含まなければなりません。一部の事業者がプライバシーや法的な理由で、この部分を変更したり、墨消しすることを選択するかもしれないが、そのような変更は、この報告書の受取人による法医学作業を妨げる可能性として原稿全体の電子メールメッセージがそのまま含まれることが推奨されます。さらなる議論については、セクション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.
電子。以下に議論されている場合を除き、各フィードバックレポートは、単一の電子メールメッセージに関連していなければなりません。要約および集約フォーマットは、本明細書の範囲外です。
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.
グラム。報告される乱用の主要な証拠は、元のメッセージを含むレポートの第3部分に見出されます。第二の部分は、受信機を助けることができる追加の導出されたデータが含まれていますが、実用的なレポートデータを選択するという点で、レポートの受信者は、第二の部分から、その後、第一のデータを第三の部分のコンテンツを使用すべきです。最初の部分は、ヒトでの使用のための説明テキストが含まれているためのものが、レポートの一部ではない、それ自体であり、それは他の部分と競合している場合に使用されるべきではありませんさ。
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.
このコンテンツタイプの本体は[MAIL]ヘッダーフィールドの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:
次のレポートのヘッダーフィールドは、一度だけ表示される必要があります。
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「のUser-Agentは、」レポートを生成するソフトウェアプログラムの名前とバージョンを示します。このフィールドのフォーマットは、[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 "のオリジナル・エンベロープ-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「のオリジナルメール-からは、」オリジナルのSMTPトランザクションの一部からMAILに使用したメールアドレスのコピーが含まれています。このフィールドのフォーマットは、「リバースパス」として[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）によって受信された日付と時刻を示しています。このフィールドは[MAIL]のセクション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「-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「ソース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-結果]で定義されています。レポートの受信機は、このフィールドは、レポートジェネレータによって行われたアサーションを示していることに注意してください。
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「のオリジナル・RCPTは-するには、」オリジナルの[SMTP]トランザクションのRCPT TO部分に使用したメールアドレスのコピーを含んでいます。このフィールドの形式は、そのメモのセクション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「報告・ドメインは、」レポート・ジェネレータは、例えば、その見かけ上のアクションレポートの生成を引き起こしたドメインレポートに関連すると信じているドメイン名が含まれています。レポートジェネレータがこの情報をどのように決定するか指定されていないため、レポートの受信機は、それが選ばれたかを特定することはできません。それは、多くの場合、このレポートが処理されるかもしれない方法レポートの受信機に示唆する手段として使用されます。導出は明らかでない場合には、レポート・ジェネレータは、レポートのテキストセクションで明確にすることが奨励されます。ドメインフォーマットは、[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].
○「報告-URIは」レポートジェネレータは、例えば、レポートが生成される原因となったメッセージの中で発見された疑わしい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 )
フィードバック・レポート= *（フィードバック型/ユーザーエージェント/バージョン）OPT-フィールドワンス*（OPT-フィールド-多く）*（EXT-フィールド）
feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF ; the "token" must be a registered feedback type as ; described elsewhere in this document
帰還型= "フィードバック型：" [CFWS] [CFWS] CRLFトークン。 「トークンは」として登録されたフィードバック型でなければなりません。本書の他の箇所に記載
user-agent = "User-Agent:" [CFWS] product *( CFWS product ) [CFWS] CRLF
ユーザーエージェント= "ユーザーエージェント：" [CFWS]製品*（CFWS製品）[CFWS] CRLF
version = "Version:" [CFWS] %x31-39 *DIGIT [CFWS] CRLF ; as described above
バージョン= "バージョン：" [CFWS]％のx31-39 * DIGIT [CFWS] CRLF。上記のように
opt-fields-once = [ arrival-date ] [ incidents ] [ original-envelope-id ] [ original-mail-from ] [ reporting-mta ] [ source-ip ]
オプトインフィールドワンス= [到着日] [事件] [オリジナルのエンベロープ-ID] [オリジナルメール-から] [報告-MTA] [ソースIP]
arrival-date = "Arrival-Date:" [CFWS] date-time CRLF
到着日時= "到着-日：" [CFWS]日時CRLF
incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF ; must be a 32-bit unsigned integer
インシデント= "インシデント：" [CFWS] 1 * DIGIT [CFWS] CRLF。 32ビット符号なし整数でなければなりません
original-envelope-id = "Original-Envelope-Id:" [CFWS] envelope-id [CFWS] CRLF
元のエンベロープ-ID = "オリジナルエンベロープ-ID：" [CFWS]エンベロープ-ID [CFWS] CRLF
original-mail-from = "Original-Mail-From:" [CFWS] reverse-path [CFWS] CRLF
= "オリジナルメール-から："-から元のメール[CFWS]リバースパス[CFWS] CRLF
reporting-mta = "Reporting-MTA:" [CFWS] mta-name-type [CFWS] ";" [CFWS] mta-name [CFWS] CRLF
報告-MTA = "報告-MTA：" [CFWS] MTA名型[CFWS] ";" [CFWS] MTA名[CFWS] CRLF
source-ip = "Source-IP:" [CFWS] ( IPv4-address-literal / IPv6-address-literal ) [CFWS] CRLF
ソースIP = "ソース-IP：" [CFWS]（IPv4のアドレスリテラル/ IPv6のアドレスリテラル）[CFWS] CRLF
opt-fields-many = [ authres-header ] [ original-rcpt-to ] [ reported-domain ] [ reported-uri ]
オプトインフィールド多= [authresヘッダ] [原RCPT-へ] [報告ドメイン] [報告-URI]
original-rcpt-to = "Original-Rcpt-To:" [CFWS] forward-path [CFWS] CRLF
原稿RCPT-へ= "オリジナル-RCPT-TO：" [CFWS]往路[CFWS] CRLF
reported-domain = "Reported-Domain:" [CFWS] domain [CFWS] CRLF
報告されたドメイン= "報告-ドメイン：" [CFWS]ドメイン[CFWS] CRLF
reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF
報告-URI = "報告-URI：" [CFWS] URI [CFWS] CRLF
ext-field = field-name ":" unstructured
EXT-フィールド=フィールド名 "：" 非構造化
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」および「桁が」[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」、「日時」、および「ドメイン」[MAIL]から輸入されています。
"envelope-id", "mta-name-type", and "mta-name" are imported from [DSN].
"エンベロープ-ID"、 "MTA名型"、および "MTA名は" [DSN]からインポートされています。
"reverse-path", "forward-path", "local-part", "IPv4-address-literal", and "IPv6-address-literal" are imported from [SMTP].
「ローカルパート」、「IPv4のアドレスリテラル」、「フォワード・パス」、「パスを逆」、および「IPv6のアドレスリテラルは、」[SMTP]からインポートされています。
"URI" is imported from [URI].
"URI" は、[URI]からインポートされています。
"authres-header" is imported from [AUTH-RESULTS].
"authresヘッダは、" [AUTH-結果]からインポートされています。
"ext-field" refers to extension fields, which are discussed in Section 6.
「EXT-フィールドは、」セクション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メッセージであることがなく、構文的にこの仕様から外れ、そのエージェントは、メッセージを無視するか、拒否すべきです。拒絶反応が行われる場合、（いずれかの[DSN]の[SMTP]返信または生成を介して）拒絶通知が拒否の原因を特定してください。
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レポートは空のエンベロープ送信者なしで生成され、実際に動作しないアドレスに送信された場合に、その後、生成アドレスもサービス拒否攻撃としてのDSNに圧倒することができます（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.
他の多くのフォーマットとプロトコルと同様に、このフォーマットは、インターネットの刻々と変化する風景に合うように時間をかけて拡張する必要があります。フィードバックタイプ用とレポートヘッダーフィールドのための第二：したがって、拡張性は、二つのIANAレジストリを介して提供されます。帰還型レジストリは、上記「フィードバック型」フィールドと併せて使用されます。ヘッダ名レジストリは、この形式の機械読み取り可能な部分（その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.
実験レポートタイプとレポートヘッダフィールドは、明示的にそれらを使用することに同意しているADMDsの間で使用しなければなりません。これらの名前とそれに関連するパラメータは、RFCで文書化されていません。そのため、彼らはいつでも変更することがあり、一般的な使用には適していません。
IANA has registered a new [MIME] type and created two new registries, as described below.
以下に説明するようにIANAは、新規[MIME]タイプを登録し、二つの新しいレジストリを作成しました。
This section provides the media type registration application from [MIME-REG] for processing by IANA:
このセクションでは、IANAによって処理するために、[MIME-REG]からメディアタイプ登録アプリケーションを提供します。
To: 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
このメディアタイプを使用するアプリケーション：ISPは、メールサービスビューロー、メール認証者のための乱用ヘルプデスクソフトウェア、および同様の組織
Additional information: none
追加情報：なし
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Yakov Shafranovich <ietf@shaftek.org>
ヤコブShafranovich <итф@шафтек.орг>
Murray S. Kucherawy <msk@cloudmark.com>
マレーS.カーリー<мск@слудмарк.ком>
Intended usage: COMMON
意図している用法：COMMON
Author:
著者：
Yakov Shafranovich
ジェームズShafranovich
John R. Levine
ジョンR.レヴィン
Murray S. Kucherawy
マレーS. Kucheryavyi
Change controller: IESG
変更コントローラ：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:
新規登録と更新は、以下の情報を含まなければなりません：
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
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
フィールド名：帰還型説明：登録されたフィードバックレポートタイプの複数の出演：いいえ関連「帰還型」：Nで公開/ A：[RFC5965]状態：現在
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
フィールド名：インシデント説明：いいえ関連「帰還型」：いずれかの公開：このレポートの複数の外観で表現されているどのように多くの類似した事件の発現[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トランザクションの複数の外観の一部からMAILに使用したメールアドレス[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
フィールド名：オリジナル-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]ステータス：歴史
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
フィールド名：報告 - ドメイン説明：はい関連「帰還型」：任意の公開中：[RFC5965]ステータス：現在のドメインは、発電機は、報告書は、複数の外観を生成しているかについてのメッセージへの鍵であると考えてレポートに名前を付けます
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
フィールド名：報告-URI説明：URIは、レポートジェネレータは、レポートに複数の外観を生成しているかについてのメッセージへの鍵であると考えて：はい関連「帰還型」：任意の公開中：[RFC5965]ステータス：電流を
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
フィールド名：送信元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:
新規登録は、以下の情報を含まなければなりません：
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
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.
[REPORT]から[セキュリティの考慮事項のすべてがここに継承されます。
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.
この仕様は、レポートの形式について説明します。報告書の内容の認証および有効性は、他の手段によって確立されるべきです。 unvettedレポートの内容は、第三の部分に疑惑乱用事件を含む、第二の部分または人間可読最初の部分に由来するデータ、間違った不完全な又は故意偽であってもよいです。
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.
ARFレポートの原点は、このような[SMIME]、[DKIM]、[SPF]、または[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レポートを生成が実装されています。例えば、ハニーポットの電子メールアドレスを監視ソフトウェアは、それへのメッセージの配信時に直ちに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節に、User-Agentフィールドは、生成ソフトウェアの表明であり、このメモで指定されていないにも報告書の第三部で表さメッセージ由来もされていません。これは、ドキュメントやデバッグのために意図され、そしてそれは自明悪意のあるエージェントによって偽造されているので、それが受取人によって解釈されるべきものではありません。
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.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、およびP. Overell、。
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
、RFC 5451、2009年4月 "メッセージ認証ステータスを示すためのメッセージヘッダーフィールド" [AUTH-結果] Kucherawy、M.、。
[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]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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.
[キーワード]ブラドナーの、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月。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[REPORT]ヴォードルイユ、G.、「メールシステム管理メッセージの報告のための複合/レポートのコンテンツタイプ」、RFC 3462、2003年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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.
インターネットResearch Task Force（IRTF）の[ASRG濫用]アンチスパム研究グループ（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]オールマン、E.、カラス、J.、デラニー、M.、リビー、M.、フェントン、J.、およびM.トーマス、 "ドメインキー・アイデンティファイド・メール（DKIM）署名"、RFC 4871、2007年5月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]クロッカー、D.、 "インターネットメールのアーキテクチャ"、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]リヨン、J.とM.ウォン、 "送信者ID：の認証Eメール"、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.ターナー、RFC 5751、2010年1月 "/多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様を固定"。
[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]ウォン、M.およびW. Schlitt、 "SPF（Sender Policy Framework）をEメール、バージョン1でのドメインの認可使用のために"、RFC 4408、2006年4月。
[STRADS-BCP] Crissman, G., "Proposed Spam Reporting BCP Document", May 2005.
[STRADS-BCP] Crissman、G.、 "提案スパム報告BCP文書"、2005年5月。
Appendix A. Acknowledgements
付録A.謝辞
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の活動への参加者の多くを含め、このドキュメントのための有益なコメントや提案を提供し、電子メール、コミュニティのメンバーの多くに感謝したい、と虐待フィードバック・レポートの公共のすべてのメンバーですメーリングリスト。
Appendix B. Sample Feedback Reports
付録B.サンプルフィードバックレポート
This section presents some examples of the use of this message format to report feedback about an arriving message.
このセクションでは、到着したメッセージについてのフィードバックを報告するには、このメッセージフォーマットの使用のいくつかの例を示します。
B.1. Simple Report for Email Abuse without Optional Headers
B.1。オプションヘッダのないメール乱用のための簡単な報告書
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"
From：<abusedesk@example.com>日付：木、2005年3月8日17時40分36秒EDT件名：FW：<abuse@example.net> MIME-バージョン：1.0のContent-Type：にお金を獲得マルチパート/レポート。レポートタイプ=フィードバックレポート。境界= "part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit
--part1_13d.2e68ed54_boundaryのContent-Type：text / plainの。文字セット= "US-ASCII" コンテンツ転送 - エンコード：7ビット
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/.
これは、木のIP 192.0.2.1、2005年3月8日14時00分00秒EDTから受信した電子メールメッセージの電子メールの乱用レポートです。この形式の詳細については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
帰還型：乱用のUser-Agent：SomeGenerator / 1.0バージョン：1
--part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline
--part1_13d.2e68ed54_boundaryのContent-Type：メッセージ/ 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
受信された：mailserver.example.netから（mailserver.example.net [192.0.2.1]）example.com ESMTP番号M63d4137594e46とすることにより、木、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
From：<somespammer@example.net>宛先：<非公開受信者>件名：お金MIME-バージョンを獲得：1.0コンテンツタイプ：text / plainのメッセージID：8787KJKJ3K4J3K4J3K4J3.mail@example.net日付：木、2004年9月2日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.
この仕様に応じて生成されたフィードバックレポートのイラスト。唯一の必須フィールドが使用されています。
B.2. Full Report for Email Abuse with All Headers
B.2。すべてのヘッダと電子メールの乱用のためのフルレポート
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"
From：<abusedesk@example.com>日付：木、2005年3月8日17時40分36秒EDT件名：FW：<abuse@example.net> MIME-バージョン：1.0のContent-Type：にお金を獲得マルチパート/レポート。レポートタイプ=フィードバックレポート。境界= "part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit
--part1_13d.2e68ed54_boundaryのContent-Type：text / plainの。文字セット= "US-ASCII" コンテンツ転送 - エンコード：7ビット
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/.
これは、木のIP 192.0.2.1、2005年3月8日14時00分00秒EDTから受信した電子メールメッセージの電子メールの乱用レポートです。この形式の詳細については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
帰還型：乱用のUser-Agent：SomeGenerator / 1.0バージョン：1元のメール-から：<somespammer@example.net>オリジナル-RCPT-TO：<user@example.com>到着-日：木、2005年3月8日午前14時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
報告-MTA：DNSを。 mail.example.com出典-IP：192.0.2.1認証-結果：mail.example.com。 SPF =失敗smtp.mail=somespammer@example.com報告-ドメイン：example.net報告-ウリ：http://example.net/earn_money.html報告-URI：のmailto：user@example.com取り外し - 受信者：ユーザー@ example.com
--part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline
--part1_13d.2e68ed54_boundaryのContent-Type：メッセージ/ 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
<somespammer@example.net>受付：ESMTP ID M63d4137594e46とexample.comによってmailserver.example.net（mailserver.example.net [192.0.2.1]）から。木、2005年3月8日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
宛先：<非公開受信者>件名：お金MIME-バージョンを獲得：1.0コンテンツタイプ：text / plainのメッセージID：8787KJKJ3K4J3K4J3K4J3.mail@example.net日付：木、2004年9月2日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
ヤコフShafranovich ShafTek企業4014迷宮Rdを。ボルチモア、MD 21215米国
EMail: ietf@shaftek.org URI: http://www.shaftek.org
電子メール：ietf@shaftek.org URI：http://www.shaftek.org
John R. Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 US
ジョンR.レヴィンTaughannockネットワーク私書箱727 Trumansburgに、NY 14886米国
Phone: +1 831 480 2300 EMail: standards@taugh.com
電話：+1 831 480 2300 Eメール：standards@taugh.com
Murray S. Kucherawy 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