| MARF Working Group | S. Kitterman |
| Internet-Draft | Agari |
| Updates: 4408 (if approved) | March 12, 2012 |
| Intended status: Standards Track | |
| Expires: September 11, 2012 |
SPF Authentication Failure Reporting using the Abuse Report Format
draft-ietf-marf-spf-reporting-09
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.
This memo updates RFC4408 by providing an IANA registry for SPF modifiers.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
[ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye toward automating both the generating and consumption of those reports.
[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.).
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 [I-D.IETF-MARF-AUTHFAILURE-REPORT] and [I-D.IETF-MARF-AS].
This document additionally creates a an IANA registry of [SPF] record modifiers to avoid modifier namespace collisions.
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].
The ABNF token "qp-section" is defined in [MIME].
"local-part" is defined in [MAIL].
"addr-spec" is defined in [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.
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:
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.
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.
The following report requests are defined for SPF results:
As required by [IANA-CONSIDERATIONS], this section contains registry information for the new [SPF] modifiers.
IANA is requested to create the Sender Policy Framework Modifier Registry, to include a list of all registered SPF modifier names and their defining documents.
New registrations or updates are to be published in accordance with the "Specification Required" guidelines as described in [IANA-CONSIDERATIONS]. New registrations and updates MUST contain the following information:
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 | RFC4408 | current |
| redirect | RFC4408 | current |
| ra | (this document) | current |
| rp | (this document) | current |
| rr | (this document) | current |
+------------+-----------------+---------+
Inherited considerations: implementors are advised to consider the Security Considerations sections of [SPF], [ARF], [I-D.IETF-MARF-AS], and [I-D.IETF-MARF-AUTHFAILURE-REPORT].
In addition to the advice in the Security Considerations section of [I-D.IETF-MARF-AS], these additional considerations apply to generation of [SPF] authentication failure reports:
Preventing an [SPF] failure for SPF SPF authentication failure reports is essential to mitigate the risk of data loops.
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.
| [EMAIL-ARCH] | Crocker, D, "Internet Mail Architecture", RFC 5598, October 2008. |
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
v=spf1 mx:example.org -all ra=postmaster rp=10 rr=e