[要約] RFC 6650は、電子メールのフィードバックレポートの作成と使用に関するガイドラインであり、ARF（Abuse Reporting Format）の適用性について説明しています。このRFCの目的は、電子メールの不正利用の報告を効果的に行うための標準化とプロトコルの提案です。
Internet Engineering Task Force (IETF) J. Falk
Request for Comments: 6650 Return Path
Updates: 5965 M. Kucherawy, Ed.
Category: Standards Track Cloudmark
ISSN: 2070-1721 June 2012
Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
電子メールフィードバックレポートの作成と使用：不正使用報告フォーマット（ARF）の適用性ステートメント
Abstract
概要
RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed.
RFC 5965は、メールオペレーターが受信した電子メールに関するフィードバックを他の関係者に報告することを目的とした、拡張可能な機械可読形式を定義しています。この適用性ステートメントでは、悪用と認証の両方の失敗イベントを報告するためにこの形式を利用する一般的な方法について説明します。任意のサイズのメールボックスプロバイダー、メール送信エンティティ、およびエンドユーザーは、これらの方法を基礎として使用して、最適な手順を作成できます。関連するオプションのメカニズムについても説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6650.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6650で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions .....................................................4
3. Solicited and Unsolicited Reports ...............................4
4. Generating and Handling Solicited Abuse Reports .................4
4.1. General Considerations for Feedback Providers ..............4
4.2. Where to Send Reports ......................................5
4.3. What to Put in Reports .....................................5
4.4. General Considerations for Feedback Consumers ..............5
4.5. What to Expect .............................................6
4.6. What to Do with Reports ....................................6
5. Generating and Handling Unsolicited Abuse Reports ...............6
5.1. General Considerations .....................................6
5.2. When to Generate Reports ...................................7
5.3. Where to Send Reports ......................................7
5.4. What to Put in Reports .....................................8
5.5. What to Do with Reports ....................................9
6. Generating Automatic Authentication Failure Reports ............10
7. Security Considerations ........................................11
7.1. Security Considerations in Other Documents ................11
7.2. Forgeries .................................................11
7.3. Amplification Attacks .....................................11
7.4. Automatic Generation ......................................11
7.5. Reporting Multiple Incidents ..............................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................14
The Abuse Reporting Format (ARF) was initially developed for two very specific use cases. Initially, it was intended to be used for reporting feedback between large email operators, or from large email operators to end user network access operators, any of whom could be presumed to have automated abuse-handling systems. Secondarily, it is used by those same large mail operators to send those same reports to other entities, including those involved in sending bulk email for commercial purposes. In either case, the reports would be triggered by direct end user action such as clicking on a "report spam" button in their email client.
虐待報告フォーマット（ARF）は、最初は2つの非常に特殊なユースケース用に開発されました。当初は、大規模な電子メールオペレーター間のフィードバック、または大規模な電子メールオペレーターからエンドユーザーのネットワークアクセスオペレーターへのフィードバックを報告するために使用することを意図していました。第二に、同じ大規模なメール事業者が、同じレポートを他のエンティティに送信するために使用します。いずれの場合も、レポートは、電子メールクライアントの[スパムを報告]ボタンをクリックするなどの直接的なエンドユーザーアクションによってトリガーされます。
Though other uses for ARF as defined in [RFC5965] have been discussed (and may be documented similarly in the future), abuse reporting remains the primary application, with a small amount of adoption of extensions that enable authentication failure reporting.
[RFC5965]で定義されている他のARFの使用法が議論されてきましたが（将来的には同様に文書化される可能性があります）、認証の失敗の報告を可能にする拡張機能の少量の採用により、不正使用の報告が依然として主要なアプリケーションです。
This applicability statement provides direction for using ARF in both contexts. It also includes some statements about the use of ARF in conjunction with other email technologies.
この適用性ステートメントは、両方のコンテキストでARFを使用するための指示を提供します。また、ARFを他の電子メールテクノロジーと組み合わせて使用する方法についても説明します。
The purpose for reporting abusive messages is to stop recurrences. The methods described in this document focus on automating abuse reporting as much as practical, so as to minimize the work of a site's abuse team. There are further reasons why abuse feedback generation is worthwhile, such as instruction of mail filters or reputation trackers, or initiation of investigations of particularly egregious abuses. These other applications are not discussed in this memo.
不正なメッセージを報告する目的は、再発を防ぐことです。このドキュメントで説明する方法は、サイトの不正行為チームの作業を最小限に抑えるために、不正行為の報告を可能な限り自動化することに重点を置いています。メールフィルターやレピュテーショントラッカーの指示、特に悪質な不正行為の調査の開始など、悪用フィードバックの生成に価値がある理由は他にもあります。これらの他のアプリケーションは、このメモでは説明されていません。
Further introduction to this topic may be found in [RFC6449], which has more information about the general topic of abuse reporting. Many of the specific ARF guidelines in this document were taken from the principles presented in [RFC6449].
このトピックの詳細は、[RFC6449]に記載されています。RFC6449には、不正行為の報告に関する一般的なトピックに関する詳細情報があります。このドキュメントの特定のARFガイドラインの多くは、[RFC6449]で提示された原則から取られました。
At the time of publication of this document, five feedback types are registered. This document only discusses two of them ("abuse" [RFC5965] and "auth-failure" [RFC6591]), as they are seeing sufficient use in practice that applicability statements can be made about them. The others, i.e., "fraud" [RFC5965], "other" [RFC5965], and "not-spam" [RFC6430], are either too new or too seldom used to be included here.
このドキュメントの公開時には、5つのフィードバックタイプが登録されています。このドキュメントでは、2つ（ "abuse" [RFC5965]および "auth-failure" [RFC6591]）についてのみ説明します。これは、それらについて適用性ステートメントを作成できるという十分な使用が実際に見られているためです。その他、つまり「詐欺」[RFC5965]、「その他」[RFC5965]、および「非スパム」[RFC6430]は、あまりに新しいか、あまり使用されていないため、ここに含めることはできません。
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 [RFC2119] and are intended to replace the Requirement Levels described in Section 3.3 of [RFC2026].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈され、[RFC2026]のセクション3.3で説明されている要件レベルを置き換えることを目的としています。
Some of the terminology used in this document is taken from [RFC5598].
このドキュメントで使用されている用語の一部は、[RFC5598]から引用されています。
"Mailbox Provider" refers to an organization that accepts, stores, and offers access to [RFC5322] messages ("email messages") for end users. Such an organization has typically implemented SMTP [RFC5321] and might provide access to messages through IMAP [RFC3501], the Post Office Protocol (POP) [RFC1939], a proprietary interface designed for HTTP [RFC2616], or a proprietary protocol.
「メールボックスプロバイダー」とは、[RFC5322]メッセージ（「電子メールメッセージ」）へのアクセスを受け入れ、保存し、エンドユーザーに提供する組織を指します。このような組織は通常、SMTP [RFC5321]を実装しており、IMAP [RFC3501]、Post Office Protocol（POP）[RFC1939]、HTTP [RFC2616]用に設計された独自のインターフェイス、または独自のプロトコルを介してメッセージへのアクセスを提供します。
The original, and still by far the most common, application of [RFC5965] is when two mail systems make a private agreement to exchange abuse reports -- usually reports due to recipients manually reporting messages as spam. We refer to these as solicited reports.
[RFC5965]の元の、これまでで最も一般的なアプリケーションは、2つのメールシステムが不正使用報告を交換するために私的な合意をするときです。通常、受信者が手動でメッセージをスパムとして報告するための報告です。これらを請求レポートと呼びます。
Other uses for ARF involve such reports sent between parties that don't know each other. These unsolicited reports are sent without prior arrangement between the parties as to the context and meaning of the reports. Therefore, the constraints on how these unsolicited reports need to be structured such that they are likely to be useful to the recipient -- e.g., to what address(es) they can usefully be sent, what issues they can be used to report, and how they can be handled by the receiver of the report -- are very different.
ARFの他の用途には、お互いを知らない当事者間で送信されるそのようなレポートが含まれます。これらの未承諾のレポートは、レポートのコンテキストと意味に関して当事者間で事前に調整することなく送信されます。したがって、これらの非送信請求レポートが受信者にとって有用である可能性が高いように構造化する必要がある方法に関する制約-たとえば、それらを送信できるアドレス、レポートに使用できる問題、およびそれらをレポートの受信者がどのように処理できるか-非常に異なります。
The two cases are covered separately in the sections that follow.
2つのケースについては、以降のセクションで個別に説明します。
A Mailbox Provider receives reports of abusive or unwanted mail from its users, most often by providing a "report spam" button (or similar nomenclature) in the MUA (Mail User Agent). The method of transferring this message and any associated metadata from the MUA to the Mailbox Provider's ARF processing system is not defined by any standards document but is discussed further in Section 3.2 of [RFC6449]. Policy concerns related to the collection of this data are discussed in Section 3.4 of [RFC6449].
メールボックスプロバイダーは、MUA（メールユーザーエージェント）に「スパムを報告する」ボタン（または同様の用語）を提供することにより、ユーザーからの不正または迷惑メールのレポートを受け取ります。このメッセージと関連するメタデータをMUAからメールボックスプロバイダーのARF処理システムに転送する方法は、標準ドキュメントでは定義されていませんが、[RFC6449]のセクション3.2で詳しく説明されています。このデータの収集に関するポリシーの懸念については、[RFC6449]のセクション3.4で説明されています。
To implement the recommendations of this memo, the reports are formatted per [RFC5965] and transmitted as an email message [RFC5322], typically using SMTP [RFC5321].
このメモの推奨事項を実装するために、レポートは[RFC5965]に従ってフォーマットされ、通常はSMTP [RFC5321]を使用して電子メールメッセージ[RFC5322]として送信されます。
Ongoing maintenance of an ARF processing system is discussed in Section 3.6 of [RFC6449].
ARF処理システムの継続的なメンテナンスについては、[RFC6449]のセクション3.6で説明されています。
The Mailbox Provider SHOULD NOT send reports to addresses that have not explicitly requested them. A valid deviation might be the result of local policy instructions. The process whereby such parties may request the reports is discussed in Section 3.5 of [RFC6449].
メールボックスプロバイダーは、明示的に要求していないアドレスにはレポートを送信しないでください。有効な逸脱は、ローカルポリシーの指示の結果である可能性があります。そのような関係者がレポートを要求するプロセスは、[RFC6449]のセクション3.5で説明されています。
The reports SHOULD use "Feedback-Type: abuse" for the report type. Although a Mailbox Provider generating the reports can use other types appropriate to the nature of the abuse being reported, the operator receiving the reports might not treat different feedback types differently.
レポートは、レポートタイプに「Feedback-Type：abuse」を使用する必要があります（SHOULD）。レポートを生成するメールボックスプロバイダーは、報告される不正行為の性質に適した他のタイプを使用できますが、レポートを受信するオペレーターは、異なるフィードバックタイプを異なる方法で処理しない場合があります。
The following fields are optional in [RFC5965] but SHOULD be used in this context when their corresponding values are available: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To. Other optional fields can be included as deemed appropriate by the implementer.
[RFC5965]では次のフィールドはオプションですが、対応する値が利用可能な場合は、このコンテキストで使用する必要があります（Original-Mail-From、Arrival-Date、Source-IP、およびOriginal-Rcpt-To）。他のオプションのフィールドは、実装者が適切であると見なした場合に含めることができます。
User-identifiable data MAY be obscured as described in [RFC6590].
[RFC6590]で説明されているように、ユーザー識別可能なデータは不明瞭になる場合があります。
ARF report streams are established proactively between Feedback Providers and Feedback Consumers. Recommendations for preparing to request feedback are discussed in Section 4.1 of [RFC6449].
ARFレポートストリームは、フィードバックプロバイダーとフィードバックコンシューマーの間で事前に確立されます。フィードバックをリクエストするための準備に関する推奨事項は、[RFC6449]のセクション4.1で説明されています。
Operators MUST be able to accept ARF [RFC5965] reports as email messages [RFC5322] over SMTP [RFC5321]. These messages, and other types of email messages that can be received, are discussed in Section 4.2 of [RFC6449].
オペレーターは、ARF [RFC5965]レポートをSMTP [RFC5321]を介して電子メールメッセージ[RFC5322]として受け入れる必要があります。これらのメッセージ、および受信可能な他のタイプの電子メールメッセージについては、[RFC6449]のセクション4.2で説明されています。
Recipients of feedback reports that are part of formal feedback arrangements have to be capable of handling large volumes of reports. This could require automation of report processing as discussed in Section 4.4 of [RFC6449].
正式なフィードバックの一部であるフィードバックレポートの受信者は、大量のレポートを処理できる必要があります。これには、[RFC6449]のセクション4.4で説明されているように、レポート処理の自動化が必要になる場合があります。
The list of valid Feedback-Types is defined in [RFC5965], which created an IANA registry for valid values to allow for extensions. However, to allow for handling of new types that are not yet supported, an automated report processing system MUST NOT reject (in the SMTP sense) a report based solely on an unknown Feedback-Type. The automated system can simply set reports of unknown types aside for manual handling. However, Mailbox Providers might only make use of the "abuse" Feedback-Type. Therefore, report receivers might be required to do additional analysis to separate different types of abuse reports after receipt if they do not have prior specific knowledge of the sender of the report.
有効なFeedback-Typesのリストは[RFC5965]で定義されており、拡張を可能にする有効な値のIANAレジストリが作成されました。ただし、まだサポートされていない新しいタイプの処理を可能にするために、自動レポート処理システムは、未知のフィードバックタイプのみに基づくレポートを（SMTPの意味で）拒否してはなりません（MUST NOT）。自動化されたシステムは、不明なタイプのレポートを手動で処理するために別にすることができます。ただし、メールボックスプロバイダーは、「乱用」フィードバックタイプのみを使用する場合があります。したがって、レポートの受信者は、レポートの送信者について事前に特定の知識がない場合、受信後にさまざまな種類の不正使用レポートを分離するために追加の分析を行う必要がある場合があります。
Report receivers MUST accept reports that have obscured their user-identifiable data as described in [RFC6590]. That document also discusses the handling of such reports. This technique is also discussed in Section 4.4 of [RFC6449].
[RFC6590]で説明されているように、レポートレシーバーはユーザー識別可能なデータを覆い隠したレポートを受け入れる必要があります。そのドキュメントでは、そのようなレポートの処理についても説明しています。この手法については、[RFC6449]のセクション4.4でも説明しています。
Section 4.3 of [RFC6449] discusses actions that mail operators might take upon receiving a report (or multiple reports).
[RFC6449]のセクション4.3は、メールオペレーターがレポート（または複数のレポート）を受信したときに実行する可能性のあるアクションについて説明しています。
It is essential for report recipients to be capable of throttling reports being sent to avoid damage to their own installations. Therefore, Feedback Providers MUST provide a way for report recipients to request that no further reports be sent. Unfortunately, no standardized mechanism for such requests exists to date, and all existing mechanisms for meeting this requirement are out-of-band.
レポートの受信者が自分のインストールへの損傷を回避するために、送信されるレポートを調整できることが不可欠です。したがって、フィードバックプロバイダーは、レポート受信者がこれ以上レポートを送信しないように要求する方法を提供する必要があります。残念ながら、そのような要求に対する標準化されたメカニズムは現在のところ存在せず、この要件を満たすための既存のメカニズムはすべて帯域外です。
Message authentication is generally a good idea, but it is especially important to encourage credibility of, and thus response to, unsolicited reports. Therefore, as with any other message, Feedback Providers sending unsolicited reports SHOULD send reports that they expect will pass the Sender Policy Framework (SPF) [RFC4408] and/or DomainKeys Identified Mail (DKIM) [RFC6376] checks.
メッセージ認証は一般的には良い考えですが、未承諾のレポートの信頼性を高め、それに対する応答を促すことが特に重要です。したがって、他のメッセージと同様に、未承諾レポートを送信するフィードバックプロバイダーは、送信者ポリシーフレームワーク（SPF）[RFC4408]および/またはDomainKeys Identified Mail（DKIM）[RFC6376]チェックに合格すると期待するレポートを送信する必要があります（SHOULD）。
Handling of unsolicited reports has a significant cost to the report receiver. Senders of unsolicited reports, especially those sending large volumes of them automatically, SHOULD NOT send reports that cannot be used as a basis for action by the recipient, whether this is due to the report being sent about an incident that is not abuse-related, the report being sent to an email address that won't result in action, or the content or format of the report being hard for the recipient to read or use.
未承諾レポートの処理は、レポート受信者にとって大きなコストになります。迷惑なレポートの送信者、特に大量のレポートを自動的に送信するものは、乱用に関連しないインシデントに関するレポートが送信されたためかどうかにかかわらず、受信者によるアクションの基礎として使用できないレポートを送信してはなりません（SHOULD NOT）。アクションにつながらないメールアドレスにレポートが送信される、またはレポートの内容や形式が受信者にとって読みにくい、または使用できない。
Feedback Providers SHOULD NOT report all mail sent from a particular sender merely because some of it is determined to be abusive.
フィードバックプロバイダーは、特定の送信者から送信されたすべてのメールを報告するべきではありません。
Mechanical reports of mail that "looks like" spam, based solely on the results of inline content analysis tools, SHOULD NOT be sent since, because of their subjective nature, they are unlikely to provide a basis for the recipient to take action. Complaints generated by end users about mail that is determined by them to be abusive, or mail delivered to "spam trap" or "honeypot" addresses, are far more likely to be accurate and MAY be sent.
インラインコンテンツ分析ツールの結果のみに基づいて、スパムのように見えるメールの機械的なレポートは、主観的な性質上、受信者が行動を起こすための基礎を提供する可能性が低いため、送信しないでください。エンドユーザーが乱用していると判断したメール、または「スパムトラップ」または「ハニーポット」アドレスに配信されたメールについて生成された苦情は、はるかに正確であり、送信される可能性があります。
If a Feedback Provider applies SPF [RFC4408] to arriving messages, a report SHOULD NOT be generated to the RFC5321.MailFrom domain if the SPF evaluation produced a "Fail", "SoftFail", "TempError", or "PermError" report, as no reliable assertion or assumption can be made that use of the domain was authorized. A valid exception would be specific knowledge that the SPF result is not definitive for that domain under those circumstances (for example, a message that is also signed using DKIM [RFC6376] by the same domain, and that signature validates).
フィードバックプロバイダーがSPF [RFC4408]を到着メッセージに適用する場合、SPF評価が「Fail」、「SoftFail」、「TempError」、または「PermError」レポートを生成した場合、レポートはRFC5321.MailFromドメインに生成されるべきではありません。ドメインの使用が許可されたという信頼できる表明または仮定を行うことはできません。有効な例外は、SPFの結果がそれらの状況下でそのドメインに対して決定的ではないという特定の知識です（たとえば、同じドメインによってDKIM [RFC6376]を使用しても署名され、その署名が検証されるメッセージ）。
Rather than generating feedback reports themselves, MUAs SHOULD create abuse reports and send these reports back to their Mailbox Providers so that they can generate and send ARF messages on behalf of end users (see Section 3.2 of [RFC6449]). This allows centralized processing and tracking of reports, and provides training input to filtering systems. There is, however, no standard mechanism for this signaling between MUAs and Mailbox Providers to trigger abuse reports.
フィードバックレポートを自分で生成するのではなく、MUAは不正使用レポートを作成し、エンドユーザーに代わってARFメッセージを生成して送信できるようにメールボックスプロバイダーに送信する必要があります（[RFC6449]のセクション3.2を参照）。これにより、レポートの集中処理と追跡が可能になり、フィルタリングシステムにトレーニング入力を提供します。ただし、MUAとメールボックスプロバイダーの間でこのシグナリングを使用して不正行為レポートをトリガーする標準的なメカニズムはありません。
Feedback Providers SHOULD NOT send reports to recipients that are uninvolved or only peripherally involved. For example, they SHOULD NOT send reports to the operator of every Autonomous System in the path between the apparent originating system and the operator generating the report. Instead, they need to send reports to recipients that are both responsible for the messages and able to do something about them.
フィードバックプロバイダーは、関与していないか、周辺機器のみに関係している受信者にレポートを送信しないでください。たとえば、見かけの発信元システムとレポートを生成するオペレーターの間のパスにあるすべての自律システムのオペレーターにレポートを送信してはなりません（SHOULD NOT）。代わりに、メッセージの責任者であり、メッセージに対して何かを実行できる受信者にレポートを送信する必要があります。
Deciding where to send an unsolicited report will typically rely on heuristics. Abuse addresses in WHOIS [RFC3912] records of the IP address relaying the subject message and/or of the domain name found in the results of a PTR ("reverse lookup") query on that address are likely reasonable candidates, as is the abuse@domain role address (see [RFC2142]) of related domains. Unsolicited reports SHOULD NOT be sent to email addresses that are not clearly intended to handle abuse reports. Legitimate candidates include those found in WHOIS records or on a web site that either are explicitly described as an abuse contact or are of the form "abuse@domain".
非送信請求レポートの送信先の決定は、通常、ヒューリスティックスに依存します。 WHOIS [RFC3912]レコードの件名メッセージを中継するIPアドレスのレコードおよび/またはそのアドレスに対するPTR（「逆引き」）クエリの結果で見つかったドメイン名の不正使用アドレスは、abuse @と同様に妥当な候補である可能性があります。関連ドメインのドメイン役割アドレス（[RFC2142]を参照）。迷惑レポートを処理することを明確に意図していないメールアドレスには、一方的なレポートを送信しないでください。正当な候補者には、WHOISレコードまたはWebサイトで見つかった、虐待の連絡先として明示的に記述されている、または「abuse @ domain」の形式の候補者が含まれます。
Where an abusive message is authenticated using a domain-level authentication technology such as DKIM [RFC6376] or SPF [RFC4408], the domain that has been verified by the authentication mechanism is often a reasonable candidate for receiving feedback about the message. For DKIM, though, while the authenticated domain has some responsibility for the mail sent, it can be a poor contact point for abuse issues (for example, it could represent the message's author but not its sender, it could identify the bad actor responsible for the message, or it could refer to a domain that cannot receive mail at all).
不正なメッセージがDKIM [RFC6376]やSPF [RFC4408]などのドメインレベルの認証技術を使用して認証される場合、認証メカニズムによって検証されたドメインは、メッセージに関するフィードバックを受信するための妥当な候補であることがよくあります。ただし、DKIMの場合、認証されたドメインは送信されたメールに対してある程度の責任がありますが、悪用の問題の連絡窓口としては不十分な場合があります（たとえば、メッセージの作成者を表すが送信者を表すことはできない場合があります）。メッセージ、またはまったくメールを受信できないドメインを参照する可能性があります）。
Often, unsolicited reports will have no meaning if sent to abuse reporting addresses belonging to the abusive parties themselves. In fact, it is possible that such reports might reveal information about complainants. Reports SHOULD NOT be sent to such addresses if they can be identified beforehand, except where the abusive party is known to be responsive to such reports.
多くの場合、迷惑な当事者自身に属する悪用報告アドレスに送信された場合、一方的な報告は意味がありません。実際、そのようなレポートで申立人に関する情報が明らかになる可能性があります。虐待する当事者がそのようなレポートに応答することがわかっている場合を除いて、事前に特定できる場合は、そのようなアドレスにレポートを送信しないでください。
Reports SHOULD use "Feedback-Type: abuse" but can use other types as appropriate. However, the Mailbox Provider generating the reports cannot assume that the operator receiving the reports will treat different Feedback-Types differently.
レポートは「Feedback-Type：abuse」を使用する必要がありますが、必要に応じて他のタイプを使用できます。ただし、レポートを生成するメールボックスプロバイダーは、レポートを受信するオペレーターが異なるフィードバックタイプを異なる方法で処理することを想定できません。
Reports SHOULD include the following optional fields whenever their corresponding values are available and applicable to the report: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To. Other optional fields can be included as deemed appropriate by the implementer.
レポートには、対応する値が使用可能でレポートに適用できる場合は常に、Original-Mail-From、Arrival-Date、Source-IP、Original-Rcpt-Toのオプションフィールドを含める必要があります（SHOULD）。他のオプションのフィールドは、実装者が適切であると見なした場合に含めることができます。
Experience suggests that the use of ARF is advisable in most contexts. Automated recipient systems can handle abuse reports sent in ARF at least as well as any other format such as plain text, with or without a copy of the message attached. That holds even for systems that did not request ARF reports, assuming such reports are generated considering the possibility of recipients that don't use automated ARF parsing. Anyone sending unsolicited reports in ARF can legitimately presume that some recipients will only be able to access the human-readable (first, text/plain) part of it and SHOULD include all information needed also in this part. Further, they SHOULD ensure that the report is readable when viewed as plain text, to give low-end ticketing systems as much assistance as possible. In extreme cases, failure to take these steps may result in the report being discarded or ignored.
経験から、ほとんどの状況でARFの使用が推奨されます。自動化された受信者システムは、メッセージのコピーが添付されているかどうかに関係なく、少なくともプレーンテキストなどの他の形式と同様に、ARFで送信された不正使用レポートを処理できます。自動化されたARF解析を使用しない受信者の可能性を考慮してそのようなレポートが生成されると仮定すると、ARFレポートを要求しなかったシステムについても同様です。 ARFで未承諾のレポートを送信する人はだれでも、一部の受信者は人間が読める（最初のテキスト/プレーン）部分にしかアクセスできないと正当に推測でき、この部分にも必要なすべての情報を含める必要があります（SHOULD）。さらに、ローエンドの発券システムにできるだけ多くの支援を提供するために、プレーンテキストとして表示したときにレポートが読みやすくなるようにする必要があります。極端な場合、これらの手順を実行しないと、レポートが破棄または無視される可能性があります。
Receivers of unsolicited reports can take advantage of the standardized parts of ARF to automate processing. Independent of the sender of the report, they can improve processing by separating valid reports from invalid reports by, for example, looking for references to IP address ranges, domains, and mailboxes for which the recipient organization is responsible in the copy of the reported message, and by correlating multiple reports of similar messages to identify bulk email senders.
非送信請求レポートの受信者は、ARFの標準化された部分を利用して処理を自動化できます。レポートの送信者とは関係なく、レポートされたメッセージのコピーで受信者の組織が担当するIPアドレス範囲、ドメイン、メールボックスへの参照を探すなどして、有効なレポートを無効なレポートから分離することで、処理を改善できます。 、および類似したメッセージの複数のレポートを相関させて、大量の電子メール送信者を識別する。
Per Section 4.4 of [RFC6449], a network service provider MAY use ARF data for automated forwarding of feedback messages to the originating customer.
[RFC6449]のセクション4.4に従い、ネットワークサービスプロバイダーは、元の顧客へのフィードバックメッセージの自動転送にARFデータを使用できます（MAY）。
Published abuse mailbox addresses SHOULD NOT reject non-ARF messages based solely on the format, as generation of ARF messages can occasionally be unavailable or not applicable. Deviation from this requirement could be done due to local policy decisions regarding other message criteria.
公開された不正使用メールボックスアドレスは、ARFメッセージの生成が時々利用できないか適用できない場合があるため、形式のみに基づいて非ARFメッセージを拒否しないでください。この要件からの逸脱は、他のメッセージ基準に関するローカルポリシーの決定により行われる可能性があります。
Although [RFC6449] suggests that replying to feedback is not useful, in the case of receipt of ARF reports where no feedback arrangement has been established, a non-automated reply might be desirable to indicate what action resulted from the complaint, heading off more severe filtering by the Feedback Provider. In addition, using an address that cannot receive replies precludes any requests for additional information and increases the likelihood that further reports will be discarded or blocked. Thus, a Feedback Provider sending unsolicited reports SHOULD NOT generate reports for which a reply cannot be received. Where an unsolicited report results in the establishment of contact with a responsible and responsive party, this data can be saved for future complaint handling and possible establishment of a formal (solicited) feedback arrangement. See Section 3.5 of [RFC6449] for a discussion of establishment of feedback arrangements.
[RFC6449]はフィードバックへの返信は役に立たないことを示唆していますが、フィードバックの取り決めが確立されていないARFレポートを受け取った場合、苦情からどのようなアクションが発生したかを示すために、非自動返信が望ましい場合があります。フィードバックプロバイダーによるフィルタリング。さらに、返信を受信できないアドレスを使用すると、追加情報の要求が排除され、以降のレポートが破棄またはブロックされる可能性が高くなります。したがって、一方的なレポートを送信するフィードバックプロバイダーは、応答を受信できないレポートを生成してはなりません（SHOULD NOT）。未承諾の報告により責任のある応答者との連絡が確立された場合、このデータは、将来の苦情処理および正式な（要請された）フィードバックの確立のために保存できます。フィードバックの取り決めの確立については、[RFC6449]のセクション3.5をご覧ください。
There are some cases where report generation is caused by automation rather than user requests. A specific example of this is reporting, using ARF (or extensions to it), of messages that fail particular message authentication checks. Examples of this include [RFC6651] and [RFC6652]. The considerations presented below apply in those cases.
レポートの生成がユーザーのリクエストではなく自動化によって引き起こされる場合があります。この特定の例は、特定のメッセージ認証チェックに失敗したメッセージのARF（またはその拡張）を使用したレポートです。この例には、[RFC6651]と[RFC6652]が含まれます。以下に示す考慮事項は、これらの場合に適用されます。
The applicability statement for this use case is somewhat smaller, as many of the issues associated with abuse reports are not relevant to reports about authentication failures.
不正使用の報告に関連する問題の多くは認証の失敗に関する報告とは関係がないため、この使用例の適用性に関する記述はやや小さくなります。
Automatic feedback generators MUST select actual message recipients based on data provided by willing report receivers. In particular, recipients MUST NOT be selected using heuristics.
自動フィードバックジェネレーターは、自発的なレポート受信者から提供されたデータに基づいて、実際のメッセージ受信者を選択する必要があります。特に、受信者はヒューリスティックを使用して選択してはなりません。
If the message under evaluation by the Verifier is an ARF [RFC5965] message, a report MUST NOT be automatically generated.
検証者によって評価中のメッセージがARF [RFC5965]メッセージである場合、レポートは自動的に生成されてはならない（MUST NOT）。
The message for a new report sent via SMTP MUST be constructed so as to avoid amplification attacks, deliberate or otherwise. The envelope sender address of the report MUST be chosen so that these reports will not generate mail loops. Similar to Section 2 of [RFC3464], the envelope sender address of the report MUST be chosen to ensure that no feedback reports will be issued in response to the report itself. Therefore, when an SMTP transaction is used to send a report, the MAIL FROM command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>". An exception to this would be the use of a reverse-path selected such that SPF checks on the report will pass; in such cases, the operator will need to make provisions to avoid the amplification attack or mail loop via other means.
SMTP経由で送信される新しいレポートのメッセージは、意図的またはその他の増幅攻撃を回避するように構築する必要があります。これらのレポートがメールループを生成しないように、レポートのエンベロープ送信者アドレスを選択する必要があります。 [RFC3464]のセクション2と同様に、レポート自体に応答してフィードバックレポートが発行されないように、レポートのエンベロープ送信者アドレスを選択する必要があります。したがって、SMTPトランザクションを使用してレポートを送信する場合、MAIL FROMコマンドはNULLの逆パスを使用する必要があります（つまり、 "MAIL FROM：<>"）。これに対する例外は、レポートのSPFチェックがパスするように選択されたリバースパスの使用です。このような場合、事業者は増幅攻撃や他の手段によるメールループを回避するための対策を講じる必要があります。
Reports SHOULD use "Feedback-Type: auth-failure" but MAY use other types as appropriate. However, the Mailbox Provider generating the reports cannot assume that the operator receiving the reports will treat different Feedback-Types differently.
レポートは「Feedback-Type：auth-failure」を使用する必要がありますが、必要に応じて他のタイプを使用してもかまいません（MAY）。ただし、レポートを生成するメールボックスプロバイダーは、レポートを受信するオペレーターが異なるフィードバックタイプを異なる方法で処理することを想定できません。
These reports SHOULD include the following fields, although they are optional in [RFC5965], whenever their corresponding values are available: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To. Other optional fields can be included as deemed appropriate by the implementer.
これらのレポートには、[RFC5965]ではオプションですが、対応する値が利用可能な場合は常に、Original-Mail-From、Arrival-Date、Source-IP、Original-Rcpt-Toの各フィールドを含める必要があります（SHOULD）。他のオプションのフィールドは、実装者が適切であると見なした場合に含めることができます。
Implementers are strongly urged to review, at a minimum, the Security Considerations sections of [RFC5965] and [RFC6449].
実装者は、少なくとも、[RFC5965]と[RFC6449]のセキュリティに関する考慮事項のセクションを確認することを強くお勧めします。
Feedback Providers that relay user complaints directly, rather than by reference to a stored message (e.g., IMAP or POP), could be duped into sending a complaint about a message that the complaining user never actually received, as an attack on the purported originator of the falsified message. Feedback Providers need to be resilient to such attack methods.
格納されたメッセージ（IMAPやPOPなど）を参照するのではなく、ユーザーの苦情を直接中継するフィードバックプロバイダーは、不平を言うユーザーの攻撃者としての攻撃として、実際に受信したことのないメッセージに関する苦情を送信する可能性があります。改ざんされたメッセージ。フィードバックプロバイダーは、このような攻撃方法に対して回復力を持つ必要があります。
Also, these reports may be forged as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as mail distribution list exploders) that wish to make automatic use of reports of any kind should take appropriate precautions to minimize the potential damage from denial-of-service attacks.
また、これらのレポートは通常のインターネット電子メールと同じくらい簡単に偽造できます。ユーザーエージェントおよび自動メール処理機能（メール配布リストの展開など）は、あらゆる種類のレポートを自動的に使用したい場合、サービス拒否攻撃による潜在的な被害を最小限に抑えるために適切な予防策を講じる必要があります。
Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves be signed with something like DKIM and/or authorized by something like SPF. Note, however, that if there is a problem with the email infrastructure at either end, DKIM and/or SPF may result in reports that aren't trusted or even accepted by their intended recipients, so it is important to make sure those components are properly configured. The use of both technologies in tandem can resolve this concern to a degree, since they generally have disjoint failure modes.
おそらく、この脅威を緩和する最も簡単な方法は、これらのレポート自体にDKIMなどの署名が必要であり、SPFなどの承認が必要であると主張することです。ただし、どちらか一方のメールインフラストラクチャに問題がある場合、DKIMまたはSPF、あるいはその両方により、信頼できない、または意図した受信者によっても受け入れられないレポートが作成される可能性があるため、これらのコンポーネントを確認することが重要です。適切に構成されています。両方の技術を組み合わせて使用すると、一般に不整合の障害モードがあるため、この問題をある程度解決できます。
Failure to comply with the recommendations regarding selection of the envelope sender can lead to amplification denial-of-service attacks. This is discussed in Section 6 as well as in [RFC3464].
エンベロープ送信者の選択に関する推奨事項に従わないと、増幅サービス拒否攻撃につながる可能性があります。これについては、セクション6と[RFC3464]で説明されています。
ARF [RFC5965] reports have historically been generated individually as a result of some kind of human request, such as someone clicking a "Report Abuse" button in a mail reader. In contrast, the mechanisms described in some extension documents (i.e., [RFC6651] and [RFC6652]) are focused around automated reporting. This obviously implies the potential for much larger volumes or higher frequency of messages, and thus greater mail system load (both for Feedback Providers and report receivers).
ARF [RFC5965]レポートは、誰かがメールリーダーの[Report Abuse]ボタンをクリックするなど、何らかの人間の要求の結果として個別に生成されてきました。対照的に、いくつかの拡張ドキュメント（つまり、[RFC6651]と[RFC6652]）で説明されているメカニズムは、自動化されたレポーティングに焦点を当てています。これは明らかに、大量のメッセージまたはメッセージの頻度が高くなる可能性があり、したがってメールシステムの負荷が大きくなる可能性があることを意味します（フィードバックプロバイダーとレポートレシーバーの両方）。
Those mechanisms are primarily intended for use in generating reports to aid implementers of DKIM [RFC6376], Author Domain Signing Practices (ADSP) [RFC5617], and SPF [RFC4408], and other related protocols during development and debugging. They are not generally intended for prolonged forensic use, specifically because of these load concerns. However, extended use is possible by ADministrative Management Domains (ADMDs) that want to keep a close watch for fraud or infrastructure problems. It is important to consider the impact of doing so on both Feedback Providers and the requesting ADMDs.
これらのメカニズムは主に、DKIM [RFC6376]、作成者ドメイン署名プラクティス（ADSP）[RFC5617]、およびSPF [RFC4408]の実装者を支援するレポートの生成と、開発およびデバッグ中のその他の関連プロトコルでの使用を目的としています。それらは、特にこれらの負荷の懸念のために、通常は長期間の法医学的使用を目的としたものではありません。ただし、詐欺またはインフラストラクチャの問題を注意深く監視する必要がある管理管理ドメイン（ADMD）によって、拡張された使用が可能です。フィードバックプロバイダーと要求元のADMDの両方でそうすることの影響を考慮することが重要です。
A sender requesting these reports can cause its mail servers to be overwhelmed if it sends out signed messages whose signatures fail to verify for some reason, provoking a large number of reports from Feedback Providers. Similarly, a Feedback Provider could be overwhelmed by a large volume of messages requesting reports whose signatures fail to validate, as the Feedback Provider now needs to send reports back to the Signer.
これらのレポートを要求する送信者は、何らかの理由で署名の検証に失敗した署名付きメッセージを送信し、フィードバックプロバイダーからの大量のレポートを送信すると、メールサーバーに負荷がかかる可能性があります。同様に、フィードバックプロバイダーは、署名を検証できないレポートを要求する大量のメッセージに圧倒される可能性があります。フィードバックプロバイダーは、レポートを署名者に返信する必要があるためです。
Limiting the rate of generation of these messages may be appropriate but threatens to inhibit the distribution of important and possibly time-sensitive information.
これらのメッセージの生成率を制限することは適切な場合がありますが、重要で時間に依存する可能性のある情報の配布を阻害する恐れがあります。
In general ARF feedback loop terms, it is often suggested that Feedback Providers only create these (or any) ARF reports after an out-of-band arrangement has been made between two parties. These extension mechanisms provide ways to adjust parameters of an authorized abuse report feedback loop that is configured and activated by private agreement. The alternative (sending reports automatically based solely on data found in the messages) may have unintended consequences.
一般的なARFフィードバックループ条件では、フィードバックプロバイダーは、これらの（または任意の）ARFレポートを、2者間で帯域外の取り決めが行われた後にのみ作成することが推奨されます。これらの拡張メカニズムは、プライベートアグリーメントによって設定およびアクティブ化される、承認された不正行為レポートフィードバックループのパラメーターを調整する方法を提供します。別の方法（メッセージで見つかったデータのみに基づいてレポートを自動的に送信する）は、意図しない結果をもたらす可能性があります。
If it is known that a particular host generates abuse reports upon certain incidents, an attacker could forge a high volume of messages that will trigger such a report. The recipient of the report could then be inundated with reports. This could easily be extended to a distributed denial-of-service attack by finding a number of report-generating servers.
特定のホストが特定のインシデントで不正行為レポートを生成することがわかっている場合、攻撃者はそのようなレポートをトリガーする大量のメッセージを偽造する可能性があります。その後、レポートの受信者はレポートで殺到する可能性があります。これは、レポートを生成する多数のサーバーを見つけることにより、分散型サービス拒否攻撃に簡単に拡張できます。
The incident count referenced in ARF [RFC5965] provides a limited form of mitigation. The host that generates reports can elect to send reports only periodically, with each report representing a number of identical or nearly identical incidents. One might even do something inverse-exponentially, sending reports for each of the first ten incidents, then every tenth incident up to 100, then every 100th incident up to 1000, etc., until some period of relative quiet after which the limitation resets.
ARF [RFC5965]で参照されているインシデント数は、限定された形の緩和を提供します。レポートを生成するホストは、レポートを定期的にのみ送信することを選択できます。各レポートは、同一またはほぼ同一のインシデントの数を表します。最初の10件のインシデントごとにレポートを送信し、次に10件ごとに最大100に、次に100件ごとに最大1000までというように、逆指数関数的に何かを実行することもできます。
The use of this technique for "nearly identical" incidents in particular causes a degradation in reporting quality, however. If for example a large number of pieces of spam arrive from one attacker, a reporting agent could decide only to send a report about a fraction of those messages. While this averts a flood of reports to a system administrator, the precise details of each incident are similarly not sent.
ただし、特に「ほぼ同一」のインシデントにこの手法を使用すると、レポートの品質が低下します。たとえば、1人の攻撃者から大量のスパムが届いた場合、レポートエージェントはそれらのメッセージの一部に関するレポートのみを送信することを決定できます。これにより、システム管理者への大量のレポートが回避されますが、各インシデントの正確な詳細は同様に送信されません。
Other rate-limiting provisions might be considered, such as detecting a temporary failure response from the report destination and thus halting report generation to that destination for some period, or simply imposing or negotiating a hard limit on the number of reports to be sent to a particular receiver in a given time frame.
レポートの宛先からの一時的な障害応答を検出して、その宛先へのレポート生成を一定期間停止する、または単にレポートに送信するレポートの数にハード制限を課す、または交渉するなど、他のレート制限規定が考慮される場合があります。特定の時間枠内の特定の受信機。
The author and editor wish to thank Steve Atkins, John Levine, Shmuel Metz, S. Moonesamy, and Alessandro Vesely for their contributions to this memo.
著者と編集者は、このメモへの貢献に対してSteve Atkins、John Levine、Shmuel Metz、S。Moonesamy、およびAlessandro Veselyに感謝します。
All of the best practices referenced by this document are found in [RFC6449], written within the Collaboration Committee of the Messaging Anti-Abuse Working Group (MAAWG).
このドキュメントで参照されているすべてのベストプラクティスは、[RFC6449]にあります。これは、メッセージング乱用防止ワーキンググループ（MAAWG）のコラボレーション委員会内に書かれています。
Finally, the original author wishes to thank the doctors and staff at the University of Texas MD Anderson Cancer Center for doing what they do.
最後に、元の著者は、テキサス大学MDアンダーソンがんセンターの医師とスタッフに、彼らの仕事をしてくれたことに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598] Crocker、D。、「Internet Mail Architecture」、RFC 5598、2009年7月。
[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[RFC5965] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張可能なフォーマット」、RFC 5965、2010年8月。
[RFC6591] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012.
[RFC6591] Fontana、H。、「不正使用報告形式を使用した認証失敗報告」、RFC 6591、2012年4月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]マイヤーズ、J。およびM.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、1996年5月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997.
[RFC2142] Crocker、D。、「Common Services、Roles、およびFunctionsのメールボックス名」、RFC 2142、1997年5月。
[RFC2616] 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.
[RFC2616] 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月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464] Moore、K.およびG. Vaudreuil、「An Extensible Message Format for Delivery Status Notifications」、RFC 3464、2003年1月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004.
[RFC3912]ダイグル、L。、「WHOISプロトコル仕様」、RFC 3912、2004年9月。
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[RFC4408] Wong、M。およびW. Schlitt、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 4408、2006年4月。
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[RFC5617] Allman、E.、Fenton、J.、Delany、M。、およびJ. Levine、「DomainKeys Identified Mail（DKIM）Author Domain Signing Practices（ADSP）」、RFC 5617、2009年8月。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376] Crocker、D。、編、Hansen、T。、編、およびM. Kucherawy、編、「DomainKeys Identified Mail（DKIM）Signatures」、RFC 6376、2011年9月。
[RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: not-spam", RFC 6430, November 2011.
[RFC6430] Li、K。およびB. Leiba、「Email Feedback Report Type Value：not-spam」、RFC 6430、2011年11月。
[RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational Recommendations", RFC 6449, November 2011.
[RFC6449] Falk、J.、Ed。、「Complaint Feedback Loop Operational Recommendations」、RFC 6449、2011年11月。
[RFC6590] Falk, J., Ed., and M. Kucherawy, Ed., "Redaction of Potentially Sensitive Data from Mail Abuse Reports", RFC 6590, April 2012.
[RFC6590] Falk、J。、編、およびM. Kucherawy、編、「メールの不正使用報告からの機密データの編集」、RFC 6590、2012年4月。
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, June 2012.
[RFC6651] Kucherawy、M。、「Extensions to DomainKeys Identified Mail（DKIM）for Failure Reporting」、RFC 6651、2012年6月。
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012.
[RFC6652] Kitterman、S。、「Sender Policy Framework（SPF）Authentication Failure Reporting Using a Abuse Reporting Format」、RFC 6652、2012年6月。
Authors' Addresses
著者のアドレス
J.D. Falk Return Path 100 Mathilda Place, Suite 100 Sunnyvale, CA 94086 USA
J.D. Falk Return Path 100 Mathilda Place、Suite 100 Sunnyvale、CA 94086 USA
URI: http://www.returnpath.net/
Murray S. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US
マレーS.クチェラウィ（編集者）Cloudmark 128 King St.、2nd Floor San Francisco、CA 94107 US
EMail: superuser@gmail.com