RFC 7372

Email Authentication Status Codes

📅 published September 2014, from ietf

RFC 7372: Email Authentication Status Codes 💌

Okay bestie, let's get the basics down first 🎀

  • RFC number and title: RFC 7372, "Email Authentication Status Codes"
  • Author: M. Kucherawy
  • Issued by: Internet Engineering Task Force (IETF)
  • Date: September 2014
  • Category: Standards Track
  • ISSN: 2070-1721
  • Updates: RFC 7208 🦋

Abstract 🌸

So this doc registers code points, which are basically named slots for status codes, so a server can send a status code back to an email client saying a message is being rejected or deferred specifically because email authentication failed 💅 It also updates RFC 7208, since some of the code points being registered replace the ones that document recommended for use.

Status of This Memo 📜

This is an Internet Standards Track document.

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, has had public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7372 ✨

Copyright (c) 2014 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, since 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 they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Key Words . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  New Enhanced Status Codes . . . . . . . . . . . . . . . . . .   3
     3.1.  DKIM Failure Codes  . . . . . . . . . . . . . . . . . . .   3
     3.2.  SPF Failure Codes . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Reverse DNS Failure Code  . . . . . . . . . . . . . . . .   5
     3.4.  Multiple Authentication Failures Code . . . . . . . . . .   5
   4.  General Considerations  . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   8

1. Introduction ✨

Okay, backstory time 🧚 [RFC3463] introduced Enhanced Mail System Status Codes, and [RFC5248] created an IANA registry for them.

[RFC6376] and [RFC7208] introduced DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF), respectively. They're two protocols for doing message authentication. Another super common email acceptance test is the reverse Domain Name System (DNS) check on an email client's IP address, as described in Section 3 of [RFC7001].

Here's the tea ☕ The current set of enhanced status codes has no code for saying a message got rejected or deferred because of local policy related to any of these mechanisms. That's potentially useful info for agents that need more than basic handling details about why a message was rejected on receipt. This document introduces enhanced status codes so clients can hear about those cases 🫶

Section 3.2 updates [RFC7208], since new enhanced status codes relevant to that spec are being registered and recommended for use.

2. Key Words 🔑

Here's the official word list, and it's important, so it stays exactly as written:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. New Enhanced Status Codes 🧁

The new enhanced status codes live in the following subsections, so let's peek in 👀

3.1. DKIM Failure Codes 💌

Before the code points, two terms you'll want to know:

  • passing: A signature is "passing" if the basic DKIM verification algorithm, as defined in [RFC6376], succeeds.
  • acceptable: A signature is "acceptable" if it satisfies all locally defined requirements (if any) in addition to passing the basic DKIM verification algorithm (e.g., certain header fields are included in the signed content, no partial signatures, etc.).

Now the codes:

      Code:               X.7.20
      Sample Text:        No passing DKIM signature found
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          did not contain any passing DKIM
                          signatures.  (This violates the
                          advice of Section 6.1 of RFC 6376.)
      Reference:          [RFC7372]; [RFC6376]
      Submitter:          M. Kucherawy
      Change controller:  IESG
      Code:               X.7.21
      Sample Text:        No acceptable DKIM signature found
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          contains one or more passing DKIM signatures,
                          but none are acceptable.  (This violates the
                          advice of Section 6.1 of RFC 6376.)
      Reference:          [RFC7372]; [RFC6376]
      Submitter:          M. Kucherawy
      Change controller:  IESG
      Code:               X.7.22
      Sample Text:        No valid author-matched DKIM signature found
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          contains one or more passing DKIM
                          signatures, but none are acceptable because
                          none have an identifier(s)
                          that matches the author address(es) found in
                          the From header field.  This is a special
                          case of X.7.21. (This violates the advice
                          of Section 6.1 of RFC 6376.)
      Reference:          [RFC7372]; [RFC6376]
      Submitter:          M. Kucherawy
      Change controller:  IESG

3.2. SPF Failure Codes 🌈

      Code:               X.7.23
      Sample Text:        SPF validation failed
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          completed an SPF check that produced a
                          "fail" result, contrary to local policy
                          requirements.  Used in place of 5.7.1, as
                          described in Section 8.4 of RFC 7208.
      Reference:          [RFC7372]; [RFC7208]
      Submitter:          M. Kucherawy
      Change controller:  IESG
      Code:               X.7.24
      Sample Text:        SPF validation error
      Associated basic status code:  451/550
      Description:        This status code is returned when evaluation
                          of SPF relative to an arriving message
                          resulted in an error.  Used in place of
                          4.4.3 or 5.5.2, as described in Sections
                          8.6 and 8.7 of RFC 7208.
      Reference:          [RFC7372]; [RFC7208]
      Submitter:          M. Kucherawy
      Change controller:  IESG

3.3. Reverse DNS Failure Code 🔄

      Code:               X.7.25
      Sample Text:        Reverse DNS validation failed
      Associated basic status code:  550
      Description:        This status code is returned when an SMTP
                          client's IP address failed a reverse DNS
                          validation check, contrary to local policy
                          requirements.
      Reference:          [RFC7372]; Section 3 of [RFC7001]
      Submitter:          M. Kucherawy
      Change controller:  IESG

3.4. Multiple Authentication Failures Code 🙈

      Code:               X.7.26
      Sample Text:        Multiple authentication checks failed
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          failed more than one message authentication
                          check, contrary to local policy requirements.
                          The particular mechanisms that failed are not
                          specified.
      Reference:          [RFC7372]
      Submitter:          M. Kucherawy
      Change controller:  IESG

4. General Considerations 🧠

Because of how SMTP works, only one enhanced status code can be returned for a given exchange between client and server. But an operator might decide to defer or reject a message for several reasons at once 😭 So clients getting these codes need to keep in mind that the failure one code reflects might not be the only reason, or the most important reason, the message or command wasn't accepted.

It's important to note that Section 6.1 of [RFC6376] discourages special treatment of messages bearing no valid DKIM signature. Some operators ignore that advice, and a few even require a valid Author Domain Signature (that is, one matching the domain(s) in the From header field) before they'll accept a message. On top of that, some newer technologies built on SPF and DKIM depend on those authentications. This work doesn't endorse configurations that go against DKIM's recommendations. It just acknowledges that they exist, and it aims to improve interoperability with those operators 🫶

One specific use case for these codes is mailing list software. It processes rejections so it can remove addresses that are no longer valid from the subscriber set. In that case, it needs to tell authentication failures apart from signs that the recipient address is no longer valid 💅

If a receiving server runs multiple authentication checks and more than one of them fails, which means the message should be rejected, the SMTP server SHOULD use the code that indicates multiple methods failed, rather than only reporting the first one that failed. It may be the case that one method is always expected to fail, so returning that method's specific code isn't useful information for the sending agent 🙃

The reverse IP DNS check is defined in Section 3 of [RFC7001].

Any message authentication or policy enforcement technologies developed in the future should also register their own enhanced status codes, so operators who want to use them can get this kind of specific reporting too ✨

7. Normative References ✨

okay bestie, this is the reading list the spec leans on 📚 every one of these is a doc the RFC says you need to know, so think of it as the "required reading" pile 🎀

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💜 this is the one that defines all those capital-letter MUST and SHOULD words, so yes, it's the foundation of everything 🫶
  • [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. 🍓 the original enhanced status code system that the new codes in this doc build on 🧚
  • [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008. 🌸 this one's the registry where those codes live, so it's giving organized 📋
  • [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011. 🔐 DKIM, the signing system the DKIM failure codes are all about 💅
  • [RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013. 🦋 the header field that carries the authentication results, iconic 👑
  • [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014. 🌈 SPF, the sender-checking system the SPF failure codes come from, periodt ✨

Appendix A. Acknowledgments 🎀

bestie, shoutout to everyone who helped make this happen 🫶 Claudio Allocchio, Dave Crocker, Ned Freed, Arnt Gulbrandsen, Scott Kitterman, Barry Leiba, Alexey Melnikov, S. Moonesamy, Hector Santos, and Stephen Turnbull all contributed to this work, so they're the real MVPs 👑💖

Author's Address 💌

Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA

EMail: superuser@gmail.com

📦 where this page comes from