ietf-corpus

rfc-6652

Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format

S. Kitterman
date2012-06 streamIETF areaapp wgmarf statusPROPOSED STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc6652 doi10.17487/RFC6652 errataview
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 RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]

updates

Extracted elements (15)

design-rationale §3

No standardized method existed for ADMDs using SPF to receive notifications when messages arrive via unauthorized routes. While SPF record lookups could be tracked via specially crafted DNS records and servers, this document provides a standardized, ARF-based mechanism as a cleaner alternative.

email

design-rationale §3

The 'rp=' percentage mechanism allows domain owners to throttle report generation to a statistical sample, acknowledging that full reporting of all failures may be impractical at scale. Report generators MAY use the ARF 'Incidents:' field to indicate more reportable events than reports sent.

email

interoperability-note §1

This document updates RFC 4408 (SPF) by establishing the IANA SPF Modifier Names registry, preventing future modifier namespace collisions. The 'ra=', 'rp=', and 'rr=' modifiers defined here extend RFC 4408's modifier framework as defined in its Section 4.6.1.

email, registry

normative-requirement §3 MUST NOT

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.

email

normative-requirement §3 MUST

'ra=' modifiers in an SPF record reached by following an 'include' mechanism MUST be ignored.

email

normative-requirement §3 SHOULD NOT

The report generator SHOULD NOT issue reports for more than the percentage of incidents specified by the 'rp=' modifier.

email

normative-requirement §4 MUST NOT

Verifiers MUST NOT generate reports for incidents that do not match a requested report type in 'rr=', and MUST ignore requests for report types not defined in Section 4.1.

email

protocol-element §4.1

Four SPF result-based report request tokens are defined: 'all' (all reports), 'e' (TempError or PermError), 'f' (Fail), 's' (SoftFail), and 'n' (Neutral or None). These correspond to SPF evaluation outcomes defined in RFC 4408.

email

protocol-element §3

The 'ra=' SPF record modifier specifies a local-part reporting address to which ARF failure reports SHOULD be sent when mail claiming to be from the domain fails SPF evaluation, particularly via unauthorized routing. The verifier constructs the full address by appending '@' and the SPF-compliant domain.

email, security

protocol-element §3

The 'rp=' SPF record modifier specifies the Requested Report Percentage, an integer from 0 to 100 indicating what percentage of SPF failure incidents should trigger reports. Default is 100.

email

protocol-element §3

The 'rr=' SPF record modifier specifies Requested Reports as a colon-separated list of tokens indicating conditions under which reports are desired. Default is 'all'. Valid tokens are: all, e (TempError/PermError), f (Fail), s (SoftFail), n (Neutral/None).

email

registry §5.1

IANA created the 'Modifier Names' registry under 'Sender Policy Framework Parameters'. New registrations require Specification Required review and must include: modifier name, defining document, and status (Current, Deprecated, or Historic). Initial entries are: exp (RFC 4408, Current), redirect (RFC 4408, Current), ra (RFC 6652, Current), rp (RFC 6652, Current), rr (RFC 6652, Current).

email, registry

security-consideration §6.2

Implementers ought to anticipate substantial and unpredictable report volume when this facility is enabled, since the amount of abuse at receivers cannot be known ahead of time and may vary rapidly.

email, security

security-consideration §6.1 MUST

To prevent data loops, if the SMTP return address used for SPF failure reports is not the NULL return address ('<>'), it MUST be selected such that it will pass SPF MAIL FROM checks upon initial receipt. The HELO/EHLO parameter SHOULD also be selected to pass SPF HELO checks when submitting via an MSA.

email, security

wire-format §3

The 'ra=' modifier uses the ABNF production 'spf-report-tag = "ra=" qp-section', where the value is a qp-section (quoted-printable encoded local-part per MIME). The 'rp=' modifier uses 'spf-rp-tag = "rp=" 1*12DIGIT "/" 1*12DIGIT'. The 'rr=' modifier uses 'spf-rr-tag = "rr=" spf-rr-type *( ":" spf-rr-type )' where spf-rr-type is one of: all, e, f, s, n.

email