--- 1/draft-ietf-dmarc-rfc7601bis-02.txt 2018-08-22 11:13:13.606858921 -0700 +++ 2/draft-ietf-dmarc-rfc7601bis-03.txt 2018-08-22 11:13:13.698861150 -0700 @@ -1,19 +1,19 @@ DMARC Working Group M. Kucherawy -Internet-Draft May 9, 2018 +Internet-Draft August 22, 2018 Obsoletes: 7601 (if approved) Intended status: Standards Track -Expires: November 10, 2018 +Expires: February 23, 2019 Message Header Field for Indicating Message Authentication Status - draft-ietf-dmarc-rfc7601bis-02 + draft-ietf-dmarc-rfc7601bis-03 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. @@ -25,21 +25,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 November 10, 2018. + This Internet-Draft will expire on February 23, 2019. Copyright Notice Copyright (c) 2018 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 @@ -59,76 +59,78 @@ 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 1.5.2. Internationalized Email . . . . . . . . . . . . . . . 7 1.5.3. Security . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.4. Email Architecture . . . . . . . . . . . . . . . . . . 8 1.5.5. Other Terms . . . . . . . . . . . . . . . . . . . . . 9 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9 2. Definition and Format of the Header Field . . . . . . . . . . 9 2.1. General Description . . . . . . . . . . . . . . . . . . . 9 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10 - 2.3. Property Types (ptypes) and Properties . . . . . . . . . . 12 - 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13 + 2.3. Property Types (ptypes) and Properties . . . . . . . . . . 13 + 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 14 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 - 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15 + 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 16 2.7. Defined Methods and Result Values . . . . . . . . . . . . 16 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 22 + 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . . 24 4.1. Header Field Position and Interpretation . . . . . . . . . 25 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 26 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6.1. The Authentication-Results Header Field . . . . . . . . . 28 6.2. "Email Authentication Methods" Registry Description . . . 28 6.3. "Email Authentication Methods" Registry Update . . . . . . 28 + 6.3.1. 'header.a' for DKIM . . . . . . . . . . . . . . . . . 29 + 6.3.2. 'header.s' for DKIM . . . . . . . . . . . . . . . . . 29 6.4. "Email Authentication Property Types" Registry . . . . . . 29 6.5. "Email Authentication Result Names" Description . . . . . 29 - 6.6. "Email Authentication Result Names" Update . . . . . . . . 29 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 6.6. "Email Authentication Result Names" Update . . . . . . . . 30 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 30 - 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 31 + 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 32 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 32 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 32 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 32 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 32 - 7.7. Attacks against Authentication Methods . . . . . . . . . . 32 + 7.7. Attacks against Authentication Methods . . . . . . . . . . 33 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 33 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 33 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 33 - 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33 + 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . . 34 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 35 - Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 37 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 36 + Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 38 Appendix B. Authentication-Results Examples . . . . . . . . . . . 38 - B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 38 + B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 39 B.2. Nearly Trivial Case; Service Provided, but No Authentication Done . . . . . . . . . . . . . . . . . . . 39 B.3. Service Provided, Authentication Done . . . . . . . . . . 40 B.4. Service Provided, Several Authentications Done, Single MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.5. Service Provided, Several Authentications Done, Different MTAs . . . . . . . . . . . . . . . . . . . . . . 42 B.6. Service Provided, Multi-tiered Authentication Done . . . . 44 B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 45 Appendix C. Operational Considerations about Message Authentication . . . . . . . . . . . . . . . . . . . 46 Appendix D. Changes Since RFC7601 . . . . . . . . . . . . . . . . 47 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 47 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48 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 @@ -171,26 +173,24 @@ o DomainKeys ([DOMAINKEYS]) (Historic) o Sender ID ([SENDERID]) (Experimental) 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. - This specification is not intended to be restricted to domain-based - authentication schemes, but the existing schemes in that family have - proven to be a good starting point for implementations. The goal 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 for each. + 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 + for each. Although SPF defined a header field called "Received-SPF" and the historic DomainKeys defined one called "DomainKey-Status" for this purpose, those header fields are specific to the conveyance of their respective results only and thus are insufficient to satisfy the requirements enumerated below. In addition, many SPF implementations have adopted the header field specified here at least as an option, and DomainKeys has been obsoleted by DKIM. 1.1. Purpose @@ -205,23 +205,23 @@ results to end users or to use those data to apply more or less stringent content checks based on authentication results; 2. Provide a common location within a message for this data; 3. Create an extensible framework for reporting new authentication methods as they emerge. In particular, the mere presence of this header field does not mean its contents are valid. Rather, the header field is reporting - assertions made by one or more authentication schemes (supposedly) - applied somewhere upstream. For an MUA or downstream filter to treat - the assertions as actually valid, there must be an assessment of the + assertions made by one or more authentication schemes applied + somewhere upstream. For an MUA or downstream filter to treat the + assertions as actually valid, there must be an assessment of the trust relationship among such agents, the validating MTA, and the mechanism for conveying the information. 1.2. Trust Boundary This document makes several references to the "trust boundary" of an administrative management domain (ADMD). Given the diversity among existing mail environments, a precise definition of this term isn't possible. @@ -278,21 +278,21 @@ 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]. 1.5.2. Internationalized Email In this document, there are references to messages formatted to support Email Address Internationalization (EAI). Reference material for this can be found in [RFC6530], [RFC6531], and [RFC6532]. Generally speaking, these documents allow UTF-8 in most places that - free-form text can be found, and U-labels where domain names can be + free-form text can be found and U-labels where domain names can be used, and this document extends Authentication-Results accordingly. 1.5.3. Security "Guidelines for Writing RFC Text on Security Considerations" ([SECURITY]) discusses authentication and authorization and the conflation of the two concepts. The use of those terms within the context of recent message security work has given rise to slightly different definitions, and this document reflects those current usages, as follows: @@ -314,21 +314,22 @@ 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 proposal groups them both into a single header field. + 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.) o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that actually enacts delivery of a message to a user's inbox or other final delivery. @@ -380,34 +382,35 @@ 1.6. Trust Environment This header field permits one or more message validation mechanisms to communicate output to one or more separate assessment mechanisms. These mechanisms operate within a unified trust boundary that defines an Administrative Management Domain (ADMD). An ADMD contains one or more entities that perform validation and generate the header field and one or more that consume it for some type of assessment. The field often contains no integrity or validation mechanism of its own, so its presence must be trusted implicitly. Hence, valid use of the - header field requires removing any occurrences of it that are present - when the message enters the ADMD. This ensures that later - occurrences have been added within the trust boundary of the ADMD. + header field requires removing any occurrences of it that claim to be + associated with the ADMD when the message enters the ADMD. This + ensures that later occurrences have been added within the trust + boundary of the ADMD. The authserv-id token defined in Section 2.2 can be used to reference an entire ADMD or a specific validation engine within an ADMD. Although the labeling scheme is left as an operational choice, some guidance for selecting a token is provided in later sections of this document. 2. Definition and Format of the Header Field This section gives a general overview of the format of the header - field being defined and then provides more formal specification. + field being defined and then provides a formal specification. 2.1. General Description The header field specified here is called Authentication-Results. It is a Structured Header Field as defined in Internet Message Format ([MAIL]), and thus all of the related definitions in that document apply. This header field is added at the top of the message as it transits MTAs that do authentication checks, so some idea of how far away the @@ -506,40 +510,42 @@ [CFWS] ; the value extracted from the message property defined ; by the "ptype.property" construction "local-part" is defined in Section 3.4.1 of [MAIL], as modified by [RFC6531]. "CFWS" is defined in Section 3.2.2 of [MAIL]. "domain-name" is as defined in Section 3.5 of [DKIM] where the "d=" - tag is defined, with "sob-domain" as modified by by [RFC6531]. + tag is defined, with "sub-domain" as modified by [RFC6531]. - "Keyword" is defined in Section 4.1.2 of [SMTP]. When used in - "result" above, it is further constrained by the necessity of being - enumerated in Section 2.7. + "Keyword" is defined in Section 4.1.2 of [SMTP]. It is further + constrained by the necessity of being registered in the IANA registry + relevant to the context in which it is used. See Section 2.7, + Section 2.3, and Section 6. "value" is as defined in Section 5.1 of [MIME]. See Section 2.5 for a description of the authserv-id element. If the value portion of a "pvalue" construction identifies something intended to be an email identity, then it MUST use the right hand portion of that ABNF definition. The list of commands eligible for use with the "smtp" ptype can be found in Section 4.1 of [SMTP]. The "propspec" may be omitted if, for example, the method was unable - to extract any properties to do its evaluation yet has a result to - report. + to extract any properties to do its evaluation yet still has a result + to report. It may also be omitted if the agent generating this + result wishes not to reveal such properties to downstream agents. Where an SMTP command name is being reported as a "property", the agent generating the header field represents that command by converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). A "ptype" value of "policy" indicates a policy decision about the message not specific to a property of the message that could be extracted. See Section 2.4 for details. @@ -607,21 +613,21 @@ For example, a DKIM signature is not required to include the Subject header field in the set of fields that are signed. An ADMD receiving such a message might decide that such a signature is unacceptable, even if it passes, because the content of the Subject header field could be altered post-signing without invalidating the signature. Such an ADMD could replace the DKIM "pass" result with a "policy" result and then also include the following in the corresponding Authentication-Result field: - ... dkim=fail policy.dkim-rules=unsigned-subject ... + ... dkim=policy policy.dkim-rules=unsigned-subject ... In this case, the property is "dkim-rules", indicating some local check by that name took place and that check returned a result of "unsigned-subject". These are arbitrary names selected by (and presumably used within) the ADMD making use of them, so they are not normally registered with IANA or otherwise specified apart from setting syntax restrictions that allow for easy parsing within the rest of the header field. This ptype existed in the original specification for this header @@ -652,22 +658,22 @@ For simplicity and scalability, the authentication service identifier SHOULD be a common token used throughout the ADMD. Common practice is to use the DNS domain name used by or within that ADMD, sometimes called the "organizational domain", but this is not strictly necessary. For tracing and debugging purposes, the authentication identifier can instead be the specific hostname of the MTA performing the authentication check whose result is being reported. Moreover, some - implementations define a substructure to the identifier; these are - outside of the scope of this specification. + implementations define a substructure to the identifier; such + structures are outside of the scope of this specification. Note, however, that using a local, relative identifier like a flat hostname, rather than a hierarchical and globally unique ADMD identifier like a DNS domain name, makes configuration more difficult for large sites. The hierarchical identifier permits aggregating related, trusted systems together under a single, parent identifier, which in turn permits assessing the trust relationship with a single reference. The alternative is a flat namespace requiring individually listing each trusted system. Since consumers will use the identifier to determine whether to use the contents of the header @@ -1009,24 +1015,24 @@ the parameters associated with them are not documented in RFCs. Therefore, they are subject to change at any time and not suitable for production use. Any MTA, MUA, or downstream filter intended for production use SHOULD ignore or delete any Authentication-Results header field that includes an experimental (unknown) method identifier. 2.7.7. Extension Result Codes Additional result codes (extension results) might be defined in the - future by later revisions or extensions to this specification. - Result codes MUST be registered with the Internet Assigned Numbers - Authority (IANA) and preferably published in an RFC. See Section 6 - for further details. + future by later revisions or extensions to this specification. Non- + experimental result codes MUST be registered with the Internet + Assigned Numbers Authority (IANA) and preferably published in an RFC. + See Section 6 for further details. Experimental results MUST only be used within ADMDs that have explicitly consented to use them. These results and the parameters associated with them are not formally documented. Therefore, they are subject to change at any time and not suitable for production use. Any MTA, MUA, or downstream filter intended for production use SHOULD ignore or delete any Authentication-Results header field that includes an extension result. 3. The "iprev" Authentication Method @@ -1101,21 +1107,21 @@ Each "method" MUST refer to an authentication method declared in the IANA registry or an extension method as described in Section 2.7.6, and each "result" MUST refer to a result code declared in the IANA registry or an extension result code as defined in Section 2.7.7. See Section 6 for further information about the registered methods and result codes. An MTA compliant with this specification adds this header field (after performing one or more message authentication tests) to - indicate which MTA or ADMD performed the test, which test got + indicate which MTA or ADMD performed the test, which test was applied, and what the result was. If an MTA applies more than one such test, it adds this header field either once per test or once indicating all of the results. An MTA MUST NOT add a result to an existing header field. An MTA MAY add this header field containing only the authentication identifier portion and the "none" token (see Section 2.2) to indicate explicitly that no message authentication schemes were applied prior to delivery of this message. @@ -1159,23 +1165,23 @@ this header field unless specifically configured to do so by the user or administrator. That is, this interpretation should not be "on by default". Naturally then, users or administrators ought not activate such a feature unless (1) they are certain the header field will be validly added by an agent within the ADMD that accepts the mail that is ultimately read by the MUA, and (2) instances of the header field that appear to originate within the ADMD but are actually added by foreign MTAs will be removed before delivery. Furthermore, MUAs and downstream filters SHOULD NOT interpret this - header field unless the authentication service identifier it bears - appears to be one used within its own ADMD as configured by the user - or administrator. + header field unless the authentication service identifier of the + header field is used within the ADMD as configured by the user or + administrator. MUAs and downstream filters MUST ignore any result reported using a "result" not specified in the IANA "Result Code" registry or a "ptype" not listed in the "Email Authentication Property Types" registry for such values as defined in Section 6. Moreover, such agents MUST ignore a result indicated for any "method" they do not specifically support. An MUA SHOULD NOT reveal these results to end users, absent careful human factors design considerations and testing, for the presentation @@ -1219,31 +1225,31 @@ The same MAY also be done for local policy decisions overriding the results of the authentication methods (e.g., the "policy" result codes described in Section 2.7). Such rejections at the SMTP protocol level are not possible if local policy is enforced at the MUA and not the MTA. 5. Removing Existing Header Fields - For security reasons, any MTA conforming to this specification MUST - delete any discovered instance of this header field that claims, by - virtue of its authentication service identifier, to have been added - within its trust boundary but that did not come directly from another - trusted MTA. For example, an MTA for example.com receiving a message - MUST delete or otherwise obscure any instance of this header field - bearing an authentication service identifier indicating that the - header field was added within example.com prior to adding its own - header fields. This could mean each MTA will have to be equipped - with a list of internal MTAs known to be compliant (and hence - trustworthy). + To mitigate the impact of forged header fields, any MTA conforming to + this specification MUST delete any discovered instance of this header + field that claims, by virtue of its authentication service + identifier, to have been added within its trust boundary but that did + not come directly from another trusted MTA. For example, an MTA for + example.com receiving a message MUST delete or otherwise obscure any + instance of this header field bearing an authentication service + identifier indicating that the header field was added within + example.com prior to adding its own header fields. This could mean + each MTA will have to be equipped with a list of internal MTAs known + to be compliant (and hence trustworthy). For messages that are EAI-formatted messages, this test is done after converting A-labels into U-labels. For simplicity and maximum security, a border MTA could remove all instances of this header field on mail crossing into its trust boundary. However, this may conflict with the desire to access authentication results performed by trusted external service providers. It may also invalidate signed messages whose signatures cover external instances of this header field. A more robust border @@ -1303,25 +1309,28 @@ Author/Change controller: IETF Specification document(s): [this document] Related information: none 6.2. "Email Authentication Methods" Registry Description No changes are made to the description of this registry. 6.3. "Email Authentication Methods" Registry Update - The following entries are added: + The following two entries are added. + +6.3.1. 'header.a' for DKIM Method: dkim Definition: [this document] + ptype: header property: a Description: value of signature "a" tag Status: active Version: 1 @@ -1318,20 +1327,24 @@ ptype: header property: a Description: value of signature "a" tag Status: active Version: 1 +6.3.2. 'header.s' for DKIM + + "header.s" for DKIM: + Method: dkim Definition: [this document] ptype: header property: s Description: value of signature "s" tag @@ -1544,22 +1557,22 @@ after mailbox delivery, MUAs are advised in Section 4.1 to ignore such instances within MIME attachments. Moreover, when extracting a message digest to separate mail store messages or other media, such header fields should be removed so that they will never be interpreted improperly by MUAs that might later consume them. 7.11. Reverse Mapping Although Section 3 of this memo includes explicit support for the "iprev" method, its value as an authentication mechanism is limited. - Implementers of both this proposal and agents that use the data it - relays are encouraged to become familiar with the issues raised by + Implementers of both this specification and agents that use the data + it relays are encouraged to become familiar with the issues raised by [DNSOP-REVERSE] when deciding whether or not to include support for "iprev". 8. References 8.1. Normative References [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, @@ -1757,22 +1770,22 @@ field. One suggestion is to include a Priority header field, on messages that don't already have such a header field, containing a value that reflects the strength of the authentication that was accomplished, e.g., "low" for weak or no authentication, "normal" or "high" for good or strong authentication. Some modern MUAs can already filter based on the content of this header field. However, there is keen interest in having MUAs make some kind of graphical representation of this header field's meaning to end users. Until this capability is added (i.e., while this - proposal and its successors are being adopted), other interim means - of conveying authentication results may be necessary. + specification and its successors continue to be adopted), other + interim means of conveying authentication results may be necessary. Appendix B. Authentication-Results Examples This section presents some examples of the use of this header field to indicate authentication results. B.1. Trivial Case; Header Field Not Present The trivial case: @@ -1890,21 +1903,21 @@ 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.com, producing "pass" results from the SPF and Sender ID + example.net, producing "pass" results from the SPF and Sender ID checks. 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; @@ -1953,25 +1966,28 @@ 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 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 and Sender - ID tests failed since example.com has not granted example.net + 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 because the sending user had a private key matching one of - example.com's published public keys and used it to sign the message. + 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; dkim=pass reason="good signature" header.i=@mail-router.example.net; dkim=fail reason="bad signature" @@ -2138,24 +2154,27 @@ Rather, it facilitates those cases in which information produced by one stage of analysis needs to be transported with the message to the next stage. Appendix D. Changes Since RFC7601 o Added IANA registration for DKIM "a" and "s" properties. o Include EAI guidance. + o Adjust some ABNF tokens and names for easier inclusion by other + documents. + Appendix E. Acknowledgments The author wishes to acknowledge the following individuals for their - review and constructive criticism of this document: Seth Blank, John - Levine, Scott Kitterman + review and constructive criticism of this document: Seth Blank, Tim + Draegen, John Levine, Scott Kitterman, and Alessandro Vesely. Author's Address Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 United States Email: superuser@gmail.com