RFC 6652

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

📅 published June 2012, from ietf

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

Okay bestie, here's the header tea 💅

Request for Comments: 6652 📄 Written by: S. Kitterman (Agari) 🧚 Stream: Internet Engineering Task Force (IETF) 🌈 Category: Standards Track 👑 (this is a real Internet Standards Track spec, so it's giving serious energy) Date: June 2012 🍓 Updates: RFC 4408 🔥 Obsoletes: nothing listed in the header ISSN: 2070-1721

Abstract 💖

This memo extends the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specs so that message authentication failures can be reported in detail, on demand. 🦋

It also updates RFC 4408 by setting up an IANA registry for SPF modifiers. 📋

Status of This Memo 📜

This is an Internet Standards Track document. ✨

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. For more on Internet Standards, check Section 2 of RFC 5741. 🌸

Info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6652. 💜

Copyright (c) 2012 IETF Trust and the people listed 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) as they stand on the publication date. Please actually read them, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 📖

1. Introduction 🌸

The Abuse Reporting Format [ARF] is a message format for sending abuse reports through the messaging infrastructure. The big dream is automating both making these reports and reading them. 🤖

The Sender Policy Framework [SPF] is one way to do message sender authentication. It's "path-based," which means it checks the route a message took from where it started to where it ended up. The output is a verified domain name, which can then go through some kind of evaluation, like checking a known-good list or sending it to a reputation service. 🦋

This document extends [SPF] with an optional reporting address and some other parameters. Extending [ARF] with the features needed to report these incidents is covered in [ARF-AUTHFAIL] and [ARF-AS]. 💅

This document also creates an IANA registry of [SPF] record modifiers, so modifier names don't collide. 🎀

2. Definitions 💜

2.1. Key Words

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]. ✨

2.2. Imported Definitions

The [ABNF] token "qp-section" is defined in [MIME]. 📦

"local-part" is defined in [MAIL]. 📬

"addr-spec" is defined in [MAIL]. 💌

3. Optional Reporting Address for SPF 🦋

Sometimes an ADministrative Management Domain (ADMD) (see [EMAIL-ARCH]) that uses [SPF] to announce its sending practices wants to know when messages come in through unauthorized routing. Right now there's no method for that defined alongside standardized approaches like [ARF]. You can gather similar info with a specially crafted [SPF] record and a special DNS server that tracks [SPF] record lookups, but that's a lot of hoops. 🙈

This document defines the following optional "modifier" (as defined in Section 4.6.1 of [SPF]) for SPF records, using the form that specification defines: 🌈

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 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 build the full address the report goes to, the Verifier just appends 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. 🚫

ABNF:

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 says what percentage of SPF failure incidents, picked at random, should generate reports. The report generator SHOULD NOT issue reports for more than the requested percentage of incidents. An exception might be some out-of-band arrangement between two parties to override it with a mutually agreed value. Report generators MAY use the "Incidents:" field in [ARF] to show that there are more reportable incidents than there are reports. 📊

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 the conditions under which a report is wanted. See Section 4.1 for a list of valid tags. 🎯

ABNF:

spf-rr-type = ( "all" / "e" / "f" / "s" / "n" )

spf-rr-tag = "rr=" spf-rr-type *( ":" spf-rr-type )

Without an "ra=" tag in the SPF record, the "rp=" and "rr=" tags MUST be ignored, and the report generator MUST NOT issue a report. No address, no reports, periodt. 🙅‍♀️

4. Requested Reports ✨

This memo also uses the "rr" tokens defined above to let the sender ask for reports about specific situations they care about. Verifiers MUST NOT generate reports for incidents that don't match a requested report, and they MUST ignore requests for reports that aren't in this list. 💅

4.1. Requested Reports for SPF Failures

These are the report requests defined for SPF results: 🌸

  • all All reports are requested.
  • e Reports are requested for messages that produced an SPF result of "TempError" or "PermError".
  • f Reports are requested for messages that produced an SPF result of "Fail".
  • s Reports are requested for messages that produced an SPF result of "SoftFail".
  • n Reports are requested for messages that produced an SPF result of "Neutral" or "None".

5. IANA Considerations 📋

As required by [IANA-CONS], this section has the registry info for the new [SPF] modifiers. 🧾

5.1. SPF Modifier Registration

IANA created the Modifier Names registry under Sender Policy Framework Parameters. It lists every registered SPF modifier name along with the document that defines it. 🗂️

New registrations or updates are published under the "Specification Required" guidelines described in [IANA-CONS]. New registrations and updates MUST contain the following info: 🔑

  1. Name of the modifier being registered or updated
  2. The document where the modifier's specification is published
  3. New or updated status, which MUST be one of the following:
    • 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 can mark an existing registration as historic or deprecated if that fits. 🪦

Here's the registry as it stands:

              +------------+-----------------+---------+
              | MODIFIER   | REFERENCE       | STATUS  |
              +------------+-----------------+---------+
              | exp        | RFC 4408        | Current |
              | redirect   | RFC 4408        | Current |
              | ra         | (this document) | Current |
              | rp         | (this document) | Current |
              | rr         | (this document) | Current |
              +------------+-----------------+---------+

6. Security Considerations 🔥

Inherited considerations: implementers are advised to look at the Security Considerations sections of [SPF], [ARF], [ARF-AS], and [ARF-AUTHFAIL]. Read those, bestie, they matter. 🛡️

On top of the advice in the Security Considerations section of [ARF-AS], these extra considerations apply when generating [SPF] authentication failure reports: 😭

6.1. Identity Selection

Stopping an [SPF] failure for SPF authentication failure reports is essential to avoid the risk of data loops. This is serious, not a vibe. 🌀

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 so that it will pass [SPF] MAIL FROM checks upon initial receipt. 📮

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. 🫶

6.2. Report Volume

It's impossible to predict how many reports this facility will generate once a report receiver turns it on. Implementers ought to expect substantial volume, since nobody can know ahead of time how much abuse will show up at receivers, and it can spike fast and unpredictably. Be prepared, bestie. 🌋

7. References 📚

7.1. Normative References

The reference list for this section didn't come through in this part, so it'll continue in part 2. 🧚

7.2. Informative References

Same deal here: the informative references are coming up in part 2. 💜

7.1. Normative References

okay so these are the docs this spec literally can't function without, bestie 🧚 if you skip them you're not reading the real thing

  • [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
  • [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-AUTHFAIL] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012.
  • [IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
  • [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
  • [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.

7.2. Informative References

these ones are more like background reading 📚 super helpful for the big picture but not strictly required

  • [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

Appendix A. Acknowledgements

big thank-you energy 🫶 the author gives a shoutout to the people who reviewed the proposal and gave honest, constructive feedback. Murray Kucherawy, Tim Draegen, Julian Mehnle, and John Levine all get their flowers 🌸

Appendix B. Examples

ok the examples are my favourite part, they're basically little DNS records that show the vibe in action 💅

B.1. SPF DNS Record for Domain That Sends No Mail but Requests Reports

v=spf1 ra=postmaster -all

this one is for a domain that never sends mail but still wants reports, a total "I don't send, but I want the tea" move ☕

B.2. Minimal SPF DNS Record Change to Add a Reporting Address

v=spf1 mx:example.org ra=postmaster -all

the smallest possible glow-up: just add the reporting address and you're set 🎀

B.3. SPF DNS Record with Reporting Address, Report Percentage, and Requested Report Type

v=spf1 mx:example.org -all ra=postmaster rp=10 rr=e

the full main character record 👑 reporting address, report percentage, and requested report type all in one line, iconic ✨

Author's Address

Scott Kitterman
Agari
3611 Scheel Dr.
Ellicott City, MD  21042
US

Phone: +1 301 325 5475
EMail: scott@kitterman.com

and that's the whole spec, periodt 💖

📦 where this page comes from