--- 1/draft-ietf-dmarc-rfc7601bis-05.txt 2019-01-28 11:13:11.461975162 -0800 +++ 2/draft-ietf-dmarc-rfc7601bis-06.txt 2019-01-28 11:13:11.573977908 -0800 @@ -1,19 +1,19 @@ Individual submission M. Kucherawy -Internet-Draft January 20, 2019 +Internet-Draft January 28, 2019 Obsoletes: 7601 (if approved) Intended status: Standards Track -Expires: July 24, 2019 +Expires: August 1, 2019 Message Header Field for Indicating Message Authentication Status - draft-ietf-dmarc-rfc7601bis-05 + draft-ietf-dmarc-rfc7601bis-06 Abstract This document specifies a message header field called Authentication- Results 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), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 24, 2019. + This Internet-Draft will expire on August 1, 2019. Copyright Notice Copyright (c) 2019 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 @@ -66,78 +66,78 @@ 1.5.5. Other Terms . . . . . . . . . . . . . . . . . . . . . 9 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9 2. Definition and Format of the Header Field . . . . . . . . . . 10 2.1. General Description . . . . . . . . . . . . . . . . . . . 10 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10 2.3. Property Types (ptypes) and Properties . . . . . . . . . . 13 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 14 2.5. Authentication Identifier Field . . . . . . . . . . . . . 15 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 16 2.7. Defined Methods and Result Values . . . . . . . . . . . . 16 - 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 17 - 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18 - 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 20 - 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 21 - 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 22 - 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 22 - 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 23 + 2.7.1. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 2.7.2. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 + 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20 + 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 21 + 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21 + 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 22 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . . 24 - 4.1. Header Field Position and Interpretation . . . . . . . . . 26 - 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 27 + 4.1. Header Field Position and Interpretation . . . . . . . . . 25 + 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 26 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 27 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 6.1. The Authentication-Results Header Field . . . . . . . . . 29 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 6.1. The Authentication-Results Header Field . . . . . . . . . 28 6.2. "Email Authentication Methods" Registry Description . . . 29 6.3. "Email Authentication Methods" Registry Update . . . . . . 30 - 6.3.1. 'header.a' for DKIM . . . . . . . . . . . . . . . . . 31 - 6.3.2. 'header.s' for DKIM . . . . . . . . . . . . . . . . . 32 + 6.3.1. 'header.a' for DKIM . . . . . . . . . . . . . . . . . 30 + 6.3.2. 'header.s' for DKIM . . . . . . . . . . . . . . . . . 31 6.4. "Email Authentication Property Types" Registry - Description . . . . . . . . . . . . . . . . . . . . . . . 32 + Description . . . . . . . . . . . . . . . . . . . . . . . 31 - 6.5. "Email Authentication Property Types" Registry Update . . 33 + 6.5. "Email Authentication Property Types" Registry Update . . 32 6.6. "Email Authentication Result Names" Registry - Description . . . . . . . . . . . . . . . . . . . . . . . 33 + Description . . . . . . . . . . . . . . . . . . . . . . . 32 6.7. "Email Authentication Result Names" Registry Update . . . 33 - 6.8. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . . 34 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 6.8. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 34 - 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 36 + 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 35 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 36 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 36 - 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 37 - 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 37 - 7.7. Attacks against Authentication Methods . . . . . . . . . . 37 + 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 36 + 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 36 + 7.7. Attacks against Authentication Methods . . . . . . . . . . 36 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 37 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 37 - 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 38 + 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 37 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . . 39 - Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 43 - Appendix B. Authentication-Results Examples . . . . . . . . . . . 43 + Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 42 + Appendix B. Authentication-Results Examples . . . . . . . . . . . 42 B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 43 B.2. Nearly Trivial Case; Service Provided, but No - Authentication Done . . . . . . . . . . . . . . . . . . . 44 - B.3. Service Provided, Authentication Done . . . . . . . . . . 45 + Authentication Done . . . . . . . . . . . . . . . . . . . 43 + B.3. Service Provided, Authentication Done . . . . . . . . . . 44 B.4. Service Provided, Several Authentications Done, Single - MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.5. Service Provided, Several Authentications Done, - Different MTAs . . . . . . . . . . . . . . . . . . . . . . 47 - B.6. Service Provided, Multi-tiered Authentication Done . . . . 49 - B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 50 + Different MTAs . . . . . . . . . . . . . . . . . . . . . . 46 + B.6. Service Provided, Multi-tiered Authentication Done . . . . 48 + B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 49 Appendix C. Operational Considerations about Message - Authentication . . . . . . . . . . . . . . . . . . . 51 - Appendix D. Changes since RFC7601 . . . . . . . . . . . . . . . . 52 - Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 53 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 + Authentication . . . . . . . . . . . . . . . . . . . 50 + Appendix D. Changes since RFC7601 . . . . . . . . . . . . . . . . 51 + Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 52 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction This document describes a header field called Authentication-Results for electronic mail messages that presents the results of a message authentication effort in a machine-readable format. The intent of the header field is to create a place to collect such data when message authentication mechanisms are in use so that a Mail User Agent (MUA) and downstream filters can make filtering decisions and/or provide a recommendation to the user as to the validity of the @@ -151,42 +151,46 @@ This document specifies the format of this header field and discusses the implications of its presence or absence. However, it does not discuss how the data contained in the header field ought to be used, such as what filtering decisions are appropriate or how an MUA might render those results, as these are local policy and/or user interface design questions that are not appropriate for this document. At the time of publication of this document, the following are published email authentication methods: - o Author Domain Signing Practices ([ADSP]) (Historic) - o SMTP Service Extension for Authentication ([AUTH]) o DomainKeys Identified Mail Signatures ([DKIM]) o Domain-based Message Authentication, Reporting and Conformance ([DMARC]) o Sender Policy Framework ([SPF]) o reverse IP address name validation ("iprev", defined in Section 3) o Require-Recipient-Valid-Since Header Field and SMTP Service Extension ([RRVS]) o S/MIME Signature Verification ([SMIME-REG]) o Vouch By Reference ([VBR]) + The following historic specifications were previously supported by + this framework, but have since become obsolete: + + o Author Domain Signing Practices ([ADSP]) (Historic) + o DomainKeys ([DOMAINKEYS]) (Historic) - o Sender ID ([SENDERID]) (Experimental) + + o Sender ID ([SENDERID]) (Historic) There exist registries for tokens used within this header field that refer to the specifications listed above. Section 6 describes the registries and their contents and specifies the process by which entries are added or updated. It also updates the existing contents to match the current states of these specifications. The goal of this work is to give current and future authentication schemes a common framework within which to deliver their results to downstream agents and discourage the creation of unique header fields @@ -318,33 +322,32 @@ o "Authorization" is the establishment of permission to use a resource or represent an identity. In this context, authorization indicates that a message from a particular ADMD arrived via a route the ADMD has explicitly approved. o "Authentication" is the assertion of validity of a piece of data about a message (such as the sender's identity) or the message in its entirety. - As examples: SPF and Sender ID are authorization mechanisms in that - they express a result that shows whether the ADMD that apparently - sent the message has explicitly authorized the connecting Simple Mail - Transfer Protocol ([SMTP]) client to relay messages on its behalf, - but they do not actually validate any other property of the message - itself. By contrast, DKIM is agnostic as to the routing of a message - but uses cryptographic signatures to authenticate agents, assign - (some) responsibility for the message (which implies authorization), - and ensure that the listed portions of the message were not modified - in transit. Since the signatures are not tied to SMTP connections, - they can be added by either the ADMD of origin, intermediate ADMDs - (such as a mailing list server), other handling agents, or any - combination. + As examples: SPF is an authorization mechanism in that it expresses a + result that shows whether the ADMD that apparently sent the message + has explicitly authorized the connecting Simple Mail Transfer + Protocol ([SMTP]) client to relay messages on its behalf, but they do + not actually validate any other property of the message itself. By + contrast, DKIM is agnostic as to the routing of a message but uses + cryptographic signatures to authenticate agents, assign (some) + responsibility for the message (which implies authorization), and + ensure that the listed portions of the message were not modified in + transit. Since the signatures are not tied to SMTP connections, they + can be added by either the ADMD of origin, intermediate ADMDs (such + as a mailing list server), other handling agents, or any combination. Rather than create a separate header field for each class of solution, this specification groups them both into a single header field. 1.5.4. Email Architecture o A "border MTA" is an MTA that acts as a gateway between the general Internet and the users within an organizational boundary. (See also Section 1.2.) @@ -743,38 +746,32 @@ Each individual authentication method returns one of a set of specific result values. The subsections below provide references to the documents defining the authentication methods specifically supported by this document, and their corresponding result values. Verifiers SHOULD use these values as described below. New methods not specified in this document, but intended to be supported by the header field defined here, MUST include a similar result table either in their defining documents or in supplementary ones. -2.7.1. DKIM and DomainKeys +2.7.1. DKIM DKIM is represented by the "dkim" method and is defined in [DKIM]. - DomainKeys is defined in [DOMAINKEYS] and is represented by the - "domainkeys" method. - - Section 3.8 of [DOMAINKEYS] enumerates some possible results of a - DomainKeys evaluation. Those results are not used when generating - this header field; rather, the results returned are listed below. A signature is "acceptable to the ADMD" if it passes local policy checks (or there are no specific local policy checks). For example, an ADMD policy might require that the signature(s) on the message be added using the DNS domain present in the From header field of the message, thus making third-party signatures unacceptable even if they verify. - Both DKIM and DomainKeys use the same result set, as follows: + The DKIM result set is as follows: none: The message was not signed. pass: The message was signed, the signature or signatures were acceptable to the ADMD, and the signature(s) passed verification tests. fail: The message was signed and the signature or signatures were acceptable to the ADMD, but they failed the verification test(s). @@ -799,51 +796,41 @@ however, represents one of the tags found in the DKIM-Signature header field rather than a distinct header field. For example, the ptype-property combination "header.d" refers to the content of the "d" (signing domain) tag from within the signature header field, and not a distinct header field called "d". Note that in an EAI-formatted message, the values of the "d" and "i" properties can be expressed in UTF-8. In addition to previous registrations, this document registers the - DKIM tag "a" (cryptographic algorithm used to sign the message) as a - reportable property. This can be used to aid receivers during post- - verification processing. In particular, [RFC8301] obsoleted use of - the "rsa-sha1" algorithm in DKIM, so it is important to be able to - distinguish such signatures from those using preferred algorithms. + DKIM tags "a" (cryptographic algorithm used to sign the message) and + "s" (selector) as reportable properties. This can be used to aid + receivers during post-verification processing. In particular, + [RFC8301] obsoleted use of the "rsa-sha1" algorithm in DKIM, so it is + important to be able to distinguish such signatures from those using + preferred algorithms. The ability to report different DKIM results for a message with multiple signatures is described in [RFC6008]. [DKIM] advises that if a message fails verification, it is to be treated as an unsigned message. A report of "fail" here permits the receiver of the report to decide how to handle the failure. A report of "neutral" or "none" preempts that choice, ensuring the message will be treated as if it had not been signed. - Section 3.1 of [DOMAINKEYS] describes a process by which the sending - address of the message is determined. DomainKeys results are thus - reported along with the signing domain name, the sending address of - the message, and the name of the header field from which the latter - was extracted. This means that a DomainKeys result includes a ptype- - property combination of "header.d", plus one of "header.from" and - "header.sender". The sending address extracted from the header is - included with any [MAIL]-style comments removed; moreover, the local- - part of the address and the "@" character are removed if it has not - been authenticated in some way. - -2.7.2. SPF and Sender ID +2.7.2. SPF - SPF and Sender ID use the "spf" and "sender-id" method names, - respectively. The result values for SPF are defined in Section 2.6 - of [SPF], and those definitions are included here by reference: + SPF uses the "spf" method name. The result values for SPF are + defined in Section 2.6 of [SPF], and those definitions are included + here by reference: +-----------+------------------------------+ | Code | Meaning | +-----------+------------------------------+ | none | [SPF], Section 2.6.1 | +-----------+------------------------------+ | pass | [SPF], Section 2.6.3 | +-----------+------------------------------+ | fail | [SPF], Section 2.6.4 | +-----------+------------------------------+ @@ -864,45 +851,33 @@ For SPF, the ptype used is "smtp", and the property is either "mailfrom" or "helo", since those values are the ones SPF can evaluate. (If the SMTP client issued the EHLO command instead of HELO, the property used is "helo".) Note that in an EAI-formatted message, the local-part of the "mailfrom" can be expressed in UTF-8 and the domain part can be expressed as a U-label. - The "sender-id" method is described in [SENDERID]. For this method, - the ptype used is "header" and the property will be the name of the - header field from which the Purported Responsible Address (see [PRA]) - was extracted -- namely, one of "Resent-Sender", "Resent-From", - "Sender", or "From". - - The results for Sender ID are listed and described in Section 4.2 of - [SENDERID], but for the purposes of this specification, the SPF - definitions enumerated above are used instead. Also, [SENDERID] - specifies result codes that use mixed case, but they are used all - lowercase in this context. - - For both methods, an additional result of "policy" is defined, which + For this method, an additional result of "policy" is defined, which means the client was authorized to inject or relay mail on behalf of the sender's DNS domain according to the authentication method's algorithm, but local policy dictates that the result is unacceptable. For example, "policy" might be used if SPF returns a "pass" result, but a local policy check matches the sending DNS domain to one found in an explicit list of unacceptable DNS domains (e.g., spammers). - If the retrieved sender policies used to evaluate SPF and Sender ID - do not contain explicit provisions for authenticating the local-part - (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported - along with results for these mechanisms SHOULD NOT include the local- - part or the following "@" character. + If the retrieved sender policies used to evaluate SPF do not contain + explicit provisions for authenticating the local-part (see Section + 3.4.1 of [MAIL]) of an address, the "pvalue" reported along with + results for this mechanism SHOULD NOT include the local-part or the + following "@" character. 2.7.3. "iprev" The result values used by the "iprev" method, defined in Section 3, are as follows: pass: The DNS evaluation succeeded, i.e., the "reverse" and "forward" lookup results were returned and were in agreement. fail: The DNS evaluation failed. In particular, the "reverse" and @@ -1153,27 +1128,25 @@ An MTA adding this header field has to take steps to identify it as legitimate to the MUAs or downstream filters that will ultimately consume its content. One process to do so is described in Section 5. Further measures may be necessary in some environments. Some possible solutions are enumerated in Section 7.1. This document does not mandate any specific solution to this issue as each environment has its own facilities and limitations. Most known message authentication methods focus on a particular - identifier to evaluate. SPF and Sender ID differ in that they can - yield a result based on more than one identifier; specifically, SPF - can evaluate the RFC5321.HELO parameter or the RFC5321.MailFrom - parameter, and Sender ID can evaluate the RFC5321.MailFrom parameter - or the Purported Responsible Address (PRA) identity. When generating - this field to report those results, only the parameter that yielded - the result is included. + identifier to evaluate. SPF differs in that it can yield a result + based on more than one identifier; specifically, SPF can evaluate the + RFC5321.HELO parameter or the RFC5321.MailFrom parameter. When + generating this field to report those results, only the parameter + that yielded the result is included. For MTAs that add this header field, adding header fields in order (at the top), per Section 3.6 of [MAIL], is particularly important. Moreover, this header field SHOULD be inserted above any other trace header fields such MTAs might prepend. This placement allows easy detection of header fields that can be trusted. End users making direct use of this header field might inadvertently trust information that has not been properly vetted. If, for example, a basic SPF result were to be relayed that claims an @@ -1412,39 +1385,35 @@ | Method | ptype | Property | +------------+--------+----------------------------------+ | auth | smtp | auth | +------------+--------+----------------------------------+ | auth | smtp | mailfrom | +------------+--------+----------------------------------+ | dkim | header | d | +------------+--------+----------------------------------+ | dkim | header | i | +------------+--------+----------------------------------+ - | domainkeys | header | d | - +------------+--------+----------------------------------+ - | domainkeys | header | from | - +------------+--------+----------------------------------+ - | domainkeys | header | sender | - +------------+--------+----------------------------------+ | iprev | policy | iprev | +------------+--------+----------------------------------+ - | sender-id | header | name of header field used by PRA | - +------------+--------+----------------------------------+ | spf | smtp | mailfrom | +------------+--------+----------------------------------+ | spf | smtp | helo | +------------+--------+----------------------------------+ - In addition, two new entries are added to this registry, as follows: + Notably, the DomainKeys and Sender ID entries are not updated to + refer to this revised specification, as they are considered obsolete. + IANA is accordingly asked to change the Status of the "sender-id" + entry in this table to "deprecated". -6.3.1. 'header.a' for DKIM + Finally, two new entries are added to this registry, as follows: +6.3.1. 'header.a' for DKIM Method: dkim Definition: [this document] ptype: header property: a Description: value of signature "a" tag @@ -1532,37 +1501,47 @@ Status: the status of this entry, which is either: active: The entry is in current use. deprecated: The entry is no longer in current use. 6.7. "Email Authentication Result Names" Registry Update The following entries in this registry are to be updated to reflect - new Specifications as follows: + this new Specification as follows: o All "auth" method result codes ("fail", "none", "pass", "permerror", "temperror") are now specified in Section 2.7.4 of this document. o All "dkim" method result names ("fail", "neutral", "none", "pass", "permerror", "policy", "temperror") are now specified in Section 2.7.1 of this document. o All "iprev" method result names ("fail", "pass", "permerror", "temperror") are now specified in Section 2.7.3 of this document. - o The "sender-id" and "spf" method result names "fail", "neutral", - "none", "pass", "permerror", "policy", "softfail", and "temperror" - are now specified in Section 2.7.2 of this document. The - registrations for result name "hardfail" are not updated. + o The "spf" method result names "fail", "neutral", "none", "pass", + "permerror", "policy", "softfail", and "temperror" are now + specified in Section 2.7.2 of this document. The registration for + result name "hardfail" is not updated. + + The following entries in this registry are to be updated with a new + Status of "deprecated", with no change to the Specification as they + reference historic protocols: + + o All "domainkeys" method result names ("fail", "neutral", "none", + "pass", "permerror", "policy", and "temperror"). + + o All "sender-id" method result names ("fail", "neutral", "none", + "pass", "permerror", "policy", "softfail", and "temperror"). 6.8. SMTP Enhanced Status Codes The entry for X.7.25 in the "Enumerated Status Codes" sub-registry of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry" is to be updated to refer only to Section 3.3 of [AUTH-ESC] as that is where that registration was done. 7. Security Considerations @@ -1900,24 +1879,20 @@ . [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, . - [PRA] Lyon, J., "Purported Responsible Address in E-Mail - Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, - . - [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, DOI 10.17487/ RFC5451, April 2009, . [RFC6008] Kucherawy, M., "Authentication-Results Registration for Differentiating among Cryptographic Results", RFC 6008, DOI 10.17487/RFC6008, September 2010, . @@ -2082,64 +2057,62 @@ B.4. Service Provided, Several Authentications Done, Single MTA A message that was relayed inbound via a single MTA that conforms to this specification and applied three different message authentication checks: Authentication-Results: example.com; auth=pass (cram-md5) smtp.auth=sender@example.net; spf=pass smtp.mailfrom=example.net - Authentication-Results: example.com; - sender-id=pass header.from=example.net + Authentication-Results: example.com; iprev=pass + policy.iprev=192.0.2.200 Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) (dialup-1-2-3-4.example.net [192.0.2.200]) by mail-router.example.com (8.11.6/8.11.6) with ESMTPA id g1G0r1kA003489; Fri, Feb 15 2002 17:19:07 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.com From: sender@example.net Message-Id: <12345.abc@example.net> Subject: here's a sample Hello! Goodbye! Example 4: Headers Reporting Results from One MTA The Authentication-Results header field is present, indicating that the delivering MTA conforms to this specification. Once again, the receiving DNS domain name is used as the authserv-id. Furthermore, the sender authenticated herself/himself to the MTA via a method - specified in [AUTH], and both SPF and Sender ID checks were done and + specified in [AUTH], and both SPF and "iprev" checks were done and passed. The MUA could extract and relay this extra information if desired. Two Authentication-Results header fields are not required since the same host did all of the checking. The authenticating agent could have consolidated all the results into one header field. This example illustrates a scenario in which a remote user on a dial-up connection (example.net) sends mail to a border MTA (example.com) using SMTP authentication to prove identity. The dial-up provider has been explicitly authorized to relay mail as - example.net, producing "pass" results from the SPF and Sender ID - checks. + example.net, producing a "pass" result from the SPF check. B.5. Service Provided, Several Authentications Done, Different MTAs A message that was relayed inbound by two different MTAs that conform to this specification and applied multiple message authentication checks: Authentication-Results: example.com; - sender-id=fail header.from=example.com; dkim=pass (good signature) header.d=example.com Received: from mail-router.example.com (mail-router.example.com [192.0.2.1]) by auth-checker.example.com (8.11.6/8.11.6) with ESMTP id i7PK0sH7021929; Fri, Feb 15 2002 17:19:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; t=1188964191; c=simple/simple; h=From:Date:To:Subject: Message-Id:Authentication-Results; bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; @@ -2165,38 +2138,36 @@ The Authentication-Results header field is present, indicating conformance to this specification. Once again, the authserv-id used is the recipient's DNS domain name. The header field is present twice because two different MTAs in the chain of delivery did authentication tests. The first MTA, mail-router.example.com, reports that SMTP AUTH and SPF were both used and that the former passed while the latter failed. In the SMTP AUTH case, additional information is provided in the comment field, which the MUA can choose to render if desired. - The second MTA, auth-checker.example.com, reports that it did a - Sender ID test (which failed) and a DKIM test (which passed). Again, - additional data about one of the tests is provided as a comment, - which the MUA may choose to render. Also noteworthy here is the fact - that there is a DKIM signature added by example.com that assured the - integrity of the lower Authentication-Results field. + The second MTA, auth-checker.example.com, reports that it did a DKIM + test (which passed). Again, additional data about one of the tests + is provided as a comment, which the MUA may choose to render. Also + noteworthy here is the fact that there is a DKIM signature added by + example.com that assured the integrity of the lower Authentication- + Results field. Since different hosts did the two sets of authentication checks, the header fields cannot be consolidated in this example. - This example illustrates more typical transmission of mail into + This example illustrates more typical transmission of a message into example.com from a user on a dial-up connection example.net. The user appears to be legitimate as he/she had a valid password allowing authentication at the border MTA using SMTP AUTH. The SPF test failed since example.com has not granted example.net's dial-up - network authority to relay mail on its behalf. The Sender ID test - failed since example.com has not granted mail-router.example.com - authority to relay mail on its behalf. However, the DKIM test passed + network authority to relay mail on its behalf. The DKIM test passed because the sending user had a private key matching one of example.com's published public keys and mail-router.example.com used it to sign the message. B.6. Service Provided, Multi-tiered Authentication Done A message that had authentication done at various stages, one of which was outside the receiving ADMD: Authentication-Results: example.com; @@ -2372,24 +2343,27 @@ o Added IANA registration for DKIM "a" and "s" properties. o Include EAI guidance. o Adjust some ABNF tokes and names for easier inclusion by other documents. o Made minor editorial adjustments. + o Deprecate entries from RFCs that are now Historic. + Appendix E. Acknowledgments The author wishes to acknowledge the following individuals for their - review and constructive criticism of this document: Seth Blank, Tim - Draegen, Scott Kitterman, John Levine, and Alessandro Vesely. + review and constructive criticism of this document: Kurt Andersen, + Seth Blank, Tim Draegen, Scott Kitterman, John Levine, and Alessandro + Vesely. Author's Address Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 United States Email: superuser@gmail.com