Message Header Field for Indicating Message Authentication Status
RFC 5451
| Document | Type |
RFC - Proposed Standard
(April 2009; Errata)
Obsoleted by RFC 7001
Updated by RFC 6577
Was draft-kucherawy-sender-auth-header (individual in app area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5451 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Lisa Dusseault | ||
| Send notices to | tony@att.com | ||
Network Working Group M. Kucherawy Request for Comments: 5451 Sendmail, Inc. Category: Standards Track April 2009 Message Header Field for Indicating Message Authentication Status Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. Kucherawy Standards Track [Page 1] RFC 5451 Authentication-Results Header Field April 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 5 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 5 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 6 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 7 2. Definition and Format of the Header Field . . . . . . . . . . 8 2.1. General Description . . . . . . . . . . . . . . . . . . . 8 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 8 2.3. Authentication Identifier Field . . . . . . . . . . . . . 10 2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 12 2.4.2. SPF and Sender-ID Results . . . . . . . . . . . . . . 13 2.4.3. "iprev" Results . . . . . . . . . . . . . . . . . . . 14 2.4.4. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 14 2.4.5. Extension Result Codes . . . . . . . . . . . . . . . . 15 2.5. Authentication Methods . . . . . . . . . . . . . . . . . . 15 2.5.1. Definition of Initial Methods . . . . . . . . . . . . 16 2.5.2. Extension Methods . . . . . . . . . . . . . . . . . . 16 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 17 4. Adding the Header Field to A Message . . . . . . . . . . . . . 18 4.1. Header Field Position and Interpretation . . . . . . . . . 19 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 20 5. Removing the Header Field . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6.1. The Authentication-Results Header Field . . . . . . . . . 22 6.2. Email Authentication Method Name Registry . . . . . . . . 22 6.3. Email Authentication Result Name Registry . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 26 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 27 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 28 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 28 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 28 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 28 7.7. Attacks against Authentication Methods . . . . . . . . . . 28 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 29 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 29 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 29 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 29Show full document text