[要約] RFC 6652は、SPF認証の失敗を報告するためのAbuse Reporting Formatを定義しています。このRFCの目的は、SPF認証の失敗を効果的に報告し、インターネット上のメール送信者の信頼性を向上させることです。
Internet Engineering Task Force (IETF) S. Kitterman
Request for Comments: 6652 Agari
Updates: 4408 June 2012
Category: Standards Track
ISSN: 2070-1721
Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format
悪用レポート形式を使用したSender Policy Framework（SPF）認証失敗レポート
Abstract
概要
This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.
このメモは、メッセージ認証の失敗をオンデマンドで詳細に報告できるようにする、Abuse Reporting Format（ARF）およびSender Policy Framework（SPF）仕様の拡張機能を示しています。
This memo updates RFC 4408 by providing an IANA registry for SPF modifiers.
このメモは、SPF修飾子にIANAレジストリを提供することにより、RFC 4408を更新します。
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/rfc6652.
このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6652で入手できます。
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 ....................................................2
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Imported Definitions .......................................3
3. Optional Reporting Address for SPF ..............................3
4. Requested Reports ...............................................4
4.1. Requested Reports for SPF Failures .........................5
5. IANA Considerations .............................................5
5.1. SPF Modifier Registration ..................................5
6. Security Considerations .........................................6
6.1. Identity Selection .........................................6
6.2. Report Volume ..............................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Acknowledgements .......................................8
Appendix B. Examples ...............................................8
B.1. SPF DNS Record for Domain That Sends No Mail but
Requests Reports ...........................................8
B.2. Minimal SPF DNS Record Change to Add a Reporting
Address ....................................................8
B.3. SPF DNS Record with Reporting Address, Report
Percentage, and Requested Report Type ......................8
The Abuse Reporting Format [ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye toward automating both the generation and consumption of those reports.
不正使用報告フォーマット[ARF]は、メッセージングインフラストラクチャで不正使用のレポートを送信するためのメッセージフォーマットを定義し、これらのレポートの生成と消費の両方の自動化を目指しています。
The Sender Policy Framework [SPF] is one mechanism for message sender authentication; it is "path-based", meaning it authenticates the route that a message took from origin to destination. The output is a verified domain name that can then be subjected to some sort of evaluation process (e.g., comparison to a known-good list, submission to a reputation service, etc.).
送信者ポリシーフレームワーク[SPF]は、メッセージ送信者認証のメカニズムの1つです。これは「パスベース」です。つまり、メッセージが発信元から宛先へとたどるルートを認証します。出力は検証済みのドメイン名であり、何らかの評価プロセス（既知の良好なリストとの比較、評判サービスへの提出など）を行うことができます。
This document extends [SPF] to add an optional reporting address and other parameters. Extension of [ARF] to add features required for the reporting of these incidents is covered in [ARF-AUTHFAIL] and [ARF-AS].
このドキュメントは、[SPF]を拡張して、オプションのレポートアドレスとその他のパラメーターを追加します。これらのインシデントのレポートに必要な機能を追加するための[ARF]の拡張は、[ARF-AUTHFAIL]および[ARF-AS]でカバーされています。
This document additionally creates a an IANA registry of [SPF] record modifiers to avoid modifier namespace collisions.
このドキュメントはさらに、[SPF]レコード修飾子のIANAレジストリを作成して、修飾子の名前空間の衝突を回避します。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
The [ABNF] token "qp-section" is defined in [MIME].
[ABNF]トークン「qp-section」は[MIME]で定義されています。
"local-part" is defined in [MAIL].
「local-part」は[MAIL]で定義されています。
"addr-spec" is defined in [MAIL].
「addr-spec」は[MAIL]で定義されています。
There exist cases in which an ADministrative Management Domain (ADMD) (see [EMAIL-ARCH]) employing [SPF] for announcing sending practices may want to know when messages are received via unauthorized routing. Currently, there is no such method defined in conjunction with standardized approaches such as [ARF]. Similar information can be gathered using a specially crafted [SPF] record and a special DNS server to track [SPF] record lookups.
送信慣行を通知するために[SPF]を採用している管理管理ドメイン（ADMD）（[EMAIL-ARCH]を参照）が、不正なルーティングを介してメッセージを受信したことを知りたい場合があります。現在、[ARF]のような標準化されたアプローチと組み合わせて定義されたそのような方法はありません。特別に細工された[SPF]レコードと特別なDNSサーバーを使用して同様の情報を収集し、[SPF]レコードの検索を追跡できます。
This document defines the following optional "modifier" (as defined in Section 4.6.1 of [SPF]) to SPF records, using the form defined in that specification:
このドキュメントでは、次のオプションの「修飾子」（[SPF]のセクション4.6.1で定義）をSPFレコードに、その仕様で定義されている形式を使用して定義しています。
ra= Reporting Address (plain-text; OPTIONAL; no default). MUST be a local-part (see Section 3.4.1 of [MAIL]) specifying an e-mail address to which a report SHOULD be sent when mail claiming to be from this domain (see Section 2.4 of [SPF] for a description of how domains are identified for SPF checks) has failed the evaluation algorithm described in [SPF], in particular because a message arrived via an unauthorized route. To generate a complete address to which the report is sent, the Verifier simply appends to this value an "@" followed by the SPF-compliant domain per Section 4.1 of [SPF]. ra= modifiers in a record that was reached by following an "include" mechanism (defined in Section 5.2 of [SPF]) MUST be ignored.
ra =レポートアドレス（プレーンテキスト、オプション、デフォルトなし）。このドメインからのものであると主張するメールの場合にレポートを送信する必要がある電子メールアドレスを指定するローカルパーツ（[MAIL]のセクション3.4.1を参照）である必要があります（[SPF]のセクション2.4を参照）。 SPFチェックのためにドメインがどのように識別されるか）は、[SPF]で説明されている評価アルゴリズムに失敗しました。特に、メッセージが不正なルートを介して到着したためです。レポートの送信先となる完全なアドレスを生成するために、ベリファイアはこの値に「@」を追加し、その後に[SPF]のセクション4.1に従ってSPF準拠ドメインを追加します。 「含める」メカニズム（[SPF]のセクション5.2で定義）に従って到達したレコードのra =修飾子は無視する必要があります。
ABNF:
ABNF：
spf-report-tag = "ra=" qp-section
spf-report-tag = "ra =" qp-section
rp= Requested Report Percentage (plain-text; OPTIONAL; default is "100"). The value is an integer from 0 to 100 inclusive that indicates what percentage of incidents of SPF failures, selected at random, are to cause reports to be generated. The report generator SHOULD NOT issue reports for more than the requested percentage of incidents. An exception to this might be some out-of-band arrangement between two parties to override it with some mutually agreed value. Report generators MAY make use of the "Incidents:" field in [ARF] to indicate that there are more reportable incidents than there are reports.
rp =リクエストされたレポートの割合（プレーンテキスト、オプション、デフォルトは "100"）。値は0から100までの整数で、ランダムに選択されたSPF障害のインシデントの何パーセントがレポートを生成させるかを示します。レポートジェネレータは、要求されたインシデントの割合を超えるレポートを発行してはなりません（SHOULD NOT）。これに対する例外は、相互に合意した値でオーバーライドするための2つのパーティ間の帯域外の取り決めである可能性があります。レポートジェネレーターは、[ARF]の「インシデント：」フィールドを使用して、レポートよりも報告可能なインシデントが多いことを示すことができます。
ABNF:
ABNF：
spf-rp-tag = "rp=" 1*12DIGIT "/" 1*12DIGIT
rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 4.1 for a list of valid tags.
rr =要求されたレポート（プレーンテキスト、オプション、デフォルトは「すべて」）。値は、レポートが必要な条件を表すトークンのコロンで区切られたリストである必要があります。有効なタグのリストについては、セクション4.1を参照してください。
ABNF:
ABNF：
spf-rr-type = ( "all" / "e" / "f" / "s" / "n" )
spf-rr-tag = "rr=" spf-rr-type *( ":" spf-rr-type )
In the absence of an "ra=" tag in the SPF record, the "rp=" and "rr=" tags MUST be ignored, and the report generator MUST NOT issue a report.
SPFレコードに「ra =」タグがない場合、「rp =」および「rr =」タグは無視する必要があり、レポートジェネレーターはレポートを発行してはなりません（MUST NOT）。
This memo also includes, as the "rr" tokens defined above, the means by which the sender can request reports for specific circumstances of interest. Verifiers MUST NOT generate reports for incidents that do not match a requested report and MUST ignore requests for reports not included in this list.
このメモには、上記で定義された「rr」トークンとして、送信者が関心のある特定の状況のレポートを要求できる手段も含まれています。検証者は、要求されたレポートと一致しないインシデントのレポートを生成してはならず（MUST NOT）、このリストに含まれていないレポートの要求を無視しなければなりません（MUST NOT）。
The following report requests are defined for SPF results:
次のレポート要求がSPF結果に対して定義されています。
all All reports are requested.
すべてのレポートが要求されます。
e Reports are requested for messages that produced an SPF result of "TempError" or "PermError".
eレポートは、 "TempError"または "PermError"のSPF結果を生成したメッセージに対して要求されます。
f Reports are requested for messages that produced an SPF result of "Fail".
f SPFの結果が「失敗」となったメッセージのレポートが要求されます。
s Reports are requested for messages that produced an SPF result of "SoftFail".
■「SoftFail」のSPF結果を生成したメッセージのレポートが要求されます。
n Reports are requested for messages that produced an SPF result of "Neutral" or "None".
n「中立」または「なし」のSPF結果を生成したメッセージのレポートが要求されます。
As required by [IANA-CONS], this section contains registry information for the new [SPF] modifiers.
[IANA-CONS]で必要な場合、このセクションには、新しい[SPF]修飾子のレジストリ情報が含まれています。
IANA has created the Modifier Names registry under Sender Policy Framework Parameters, to include a list of all registered SPF modifier names and their defining documents.
IANAは、Sender Policy Framework Parametersの下にModifier Namesレジストリを作成し、登録されているすべてのSPF修飾子名とその定義ドキュメントのリストを含めています。
New registrations or updates are to be published in accordance with the "Specification Required" guidelines as described in [IANA-CONS]. New registrations and updates MUST contain the following information:
新規登録または更新は、[IANA-CONS]で説明されている「必要な仕様」のガイドラインに従って公開されます。新規登録と更新には、次の情報が含まれている必要があります。
1. Name of the modifier being registered or updated
1. 登録または更新される修飾子の名前
2. The document in which the specification of the modifier is published
2. 修飾子の仕様が公開されている文書
3. New or updated status, which MUST be one of the following:
3. 新規または更新されたステータス。次のいずれかである必要があります。
Current: The field is in current use
現在：フィールドは現在使用中です
Deprecated: The field might be 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.
更新により、既存の登録に表記が作成され、登録されたフィールドが履歴であるか、必要に応じて非推奨になったことが示される場合があります。
+------------+-----------------+---------+
| MODIFIER | REFERENCE | STATUS |
+------------+-----------------+---------+
| exp | RFC 4408 | Current |
| redirect | RFC 4408 | Current |
| ra | (this document) | Current |
| rp | (this document) | Current |
| rr | (this document) | Current |
+------------+-----------------+---------+
Inherited considerations: implementers are advised to consider the Security Considerations sections of [SPF], [ARF], [ARF-AS], and [ARF-AUTHFAIL].
継承される考慮事項：実装者は、[SPF]、[ARF]、[ARF-AS]、および[ARF-AUTHFAIL]のセキュリティに関する考慮事項のセクションを検討することをお勧めします。
In addition to the advice in the Security Considerations section of [ARF-AS], these additional considerations apply to the generation of [SPF] authentication failure reports:
[ARF-AS]のセキュリティに関する考慮事項セクションのアドバイスに加えて、これらの追加の考慮事項が[SPF]認証失敗レポートの生成に適用されます。
Preventing an [SPF] failure for SPF authentication failure reports is essential to mitigate the risk of data loops.
データループのリスクを軽減するには、SPF認証失敗レポートの[SPF]失敗を防ぐことが不可欠です。
If the [SMTP] return address to be used will not be the NULL return address, i.e., "MAIL FROM:<>", then the selected return address MUST be selected such that it will pass [SPF] MAIL FROM checks upon initial receipt.
使用する[SMTP]返信アドレスがNULL返信アドレスでない場合、つまり「MAIL FROM：<>」の場合、選択した返信アドレスは、最初の受信時に[SPF] MAIL FROMチェックに合格するように選択する必要があります。 。
If the report is passed to the Message Submission Agent (MSA) (MSA is described in [EMAIL-ARCH] using [SMTP]), the HELO/EHLO command parameter SHOULD also be selected so that it will pass [SPF] HELO checks.
レポートがメッセージ送信エージェント（MSA）に渡される場合（MSAは[SMTP]を使用して[EMAIL-ARCH]で記述されます）、HELO / EHLOコマンドパラメータも選択して、[SPF] HELOチェックに合格するようにする必要があります。
It is impossible to predict the volume of reports this facility will generate when enabled by a report receiver. An implementer ought to anticipate substantial volume, since the amount of abuse occurring at receivers cannot be known ahead of time, and may vary rapidly and unpredictably.
この機能がレポートレシーバーによって有効にされたときに生成するレポートの量を予測することは不可能です。レシーバーで発生する乱用の量は事前に知ることができず、急速に予測できないほど変動する可能性があるため、実装者はかなりの量を予測する必要があります。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[ARF] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張可能な形式」、RFC 5965、2010年8月。
[ARF-AS] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", RFC 6650, June 2012.
[ARF-AS] Falk、J。およびM. Kucherawy、編、「電子メールフィードバックレポートの作成と使用：不正使用報告フォーマット（ARF）の適用性に関する声明」、RFC 6650、2012年6月。
[ARF-AUTHFAIL] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012.
[ARF-AUTHFAIL] Fontana、H。、「Abuse Reporting Formatを使用した認証失敗の報告」、RFC 6591、2012年4月。
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA-CONS] Narten、T。およびH. Alvestrand、「RFCでIANAに関する考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF] Wong、M。およびW. Schlitt、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 4408、2006年4月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[メールアーク]クロッカーD.、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月。
The author wishes to acknowledge the following for their review and constructive criticism of this proposal: Murray Kucherawy, Tim Draegen, Julian Mehnle, and John Levine.
著者は、この提案のレビューと建設的な批評のために、マレークチェラウィ、ティムドレーゲン、ジュリアンメーンル、およびジョンレバインを認めたいと思います。
v=spf1 ra=postmaster -all
v=spf1 mx:example.org ra=postmaster -all
B.3. SPF DNS Record with Reporting Address, Report Percentage, and Requested Report Type
B.3. レポートアドレス、レポートの割合、および要求されたレポートタイプを含むSPF DNSレコード
v=spf1 mx:example.org -all ra=postmaster rp=10 rr=e
Author's Address
著者のアドレス
Scott Kitterman Agari 3611 Scheel Dr. Ellicott City, MD 21042 US
Scott Kitterman Agari 3611 Scheel Dr. Ellicott City、MD 21042 US
Phone: +1 301 325 5475
EMail: scott@kitterman.com