RFC 6577

RFC 6577 📮✨ Authentication-Results Registration Update for Sender Policy Framework (SPF) Results

Title block tea: 💅 This one is by Murray S. Kucherawy from Cloudmark, Inc., dated March 2012. It's a Standards Track doc, ISSN 2070-1721, and it updates RFC 5451. It doesn't obsolete anything. 🎀

Abstract

okay so this memo is basically a registry glow-up 🌸. It updates the list of authentication method results that goes in Authentication-Results: message header fields, and it fixes a mismatch between how that registry was first set up and what the Sender Policy Framework (SPF) spec says. Iconic clean-up energy 🧹✨

This memo updates RFC 5451.

Status of This Memo

This is an Internet Standards Track document. 🦋

It's a product of the Internet Engineering Task Force (IETF) and reflects IETF community consensus. It got 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 latest status, errata, and feedback info on this doc, go to http://www.rfc-editor.org/info/rfc6577. 👀

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🔐

This doc 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 those, because they lay out your rights and restrictions for this doc. 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 described in the Simplified BSD License. Legal stuff, but it matters 🫶

Table of Contents

1. Introduction ....................................................2
2. Keywords ........................................................2
3. New 'fail' Definition ...........................................2
4. IANA Considerations .............................................2
   4.1. Addition of 'Status' Columns ...............................3
   4.2. Update to Result Names .....................................3
5. Security Considerations .........................................3
6. References ......................................................4
   6.1. Normative References .......................................4
   6.2. Informative References .....................................4
Appendix A. Examples in RFC 5451 ...................................5
Appendix B. Acknowledgements .......................................5

1. Introduction 🌷

[AUTHRES] introduced a new header field for email messages that shows the results of a message authentication check in a machine-readable format. That RFC made a registry of results for a few authentication mechanisms, and one of them was the Sender Policy Framework [SPF]. Here's the tea: one entry in that registry doesn't match the SPF spec. That got flagged in an erratum [ERR2617] filed with the RFC Editor. So this memo updates the IANA registries to fix it 💖

2. Keywords 🔑

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

3. New 'fail' Definition 💀

The new "fail" result replaces the existing "hardfail" result for [SPF] (and therefore also for [SENDER-ID]). It has the same definition that "hardfail" had in Section 2.4.2 of [AUTHRES], which is:

This client is explicitly not authorized to inject or relay mail using the sender's DNS domain. 🚫

4. IANA Considerations 📋

This section lists the actions IANA is being asked to take, per [IANA]. Very organized of them 🗂️

4.1. Addition of 'Status' Columns 🏷️

IANA has added a column called "Status" to both the Email Authentication Methods and Email Authentication Result Names registries. Both live in the Email Authentication Parameters group. The column shows whether each entry is currently in use. Legal values are:

active: The entry is in current use. 🟢

deprecated: The entry is no longer in current use. 🪦

New registrations to either table MUST specify one of these values. 📝

All existing entries are marked "active" as of publication of this memo, except for the ones listed below.

4.2. Update to Result Names 🔄

[AUTHRES] listed "hardfail" as the result to use when a message fails an [SPF] evaluation. The thing is, the SPF spec itself used the string "fail" for those failures. Oops 🙈

So IANA marked "hardfail" as "deprecated" in the Email Authentication Result Names registry and updated the "fail" entry like this:

Code:  fail

Defined:  [AUTHRES]

Auth Method:  spf, sender-id

Meaning:  [this memo] Section 3

Status:  active

5. Security Considerations 🚨

This memo fixes a registry error, and the stakes are real, so pay attention 👀. Older implementations might not recognize or use the corrected entry. For that reason, implementers are advised to support both result strings for some period of time. Also, it's known that some implementations are already using the SPF-defined result string, so the mismatch is already happening in the wild 😭

6. References 📚

6.1. Normative References

[AUTHRES]    Kucherawy, M., "Message Header Field for Indicating
             Message Authentication Status", RFC 5451, April 2009.

[ERR2617]    "RFC Errata", Errata ID 2617, RFC 5451,
             <http://www.rfc-editor.org>.

[KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2. Informative References

[ERR2818]    "RFC Errata", Errata ID 2818, RFC 5451,
             <http://www.rfc-editor.org>.

[IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
             May 2008.

[SENDER-ID]  Lyon, J. and M. Wong, "Sender ID: Authenticating
             E-Mail", RFC 4406, April 2006.

[SPF]        Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
             for Authorizing Use of Domains in E-Mail, Version 1",
             RFC 4408, April 2006.

Appendix A. Examples in RFC 5451 🧾

This update also applies to the examples in [AUTHRES], specifically the one in Appendix B.5. The error there, [ERR2818], is not fixed by this update. This update only covers the normative parts of that spec and the related IANA registrations. Still, it's assumed that you could easily see what needs fixing in those examples.

Corrected examples will show up in a full update to [AUTHRES] at some future time. ⏳

Appendix B. Acknowledgements 🫶

The author would like to thank the following people for their review and constructive criticism of this proposal: S. Moonesamy, Scott Kitterman. Real ones 💜

Author's Address

Murray S. Kucherawy
Cloudmark, Inc.
128 King St., 2nd Floor
San Francisco, CA  94107
US

Phone: +1 415 946 3800
EMail: msk@cloudmark.com