--- 1/draft-ietf-dmarc-rfc7601bis-00.txt 2018-03-20 11:13:46.753283563 -0700 +++ 2/draft-ietf-dmarc-rfc7601bis-01.txt 2018-03-20 11:13:46.849285824 -0700 @@ -1,19 +1,19 @@ DMARC Working Group M. Kucherawy -Internet-Draft February 7, 2018 +Internet-Draft March 20, 2018 Obsoletes: 7601 (if approved) Intended status: Standards Track -Expires: August 11, 2018 +Expires: September 21, 2018 Message Header Field for Indicating Message Authentication Status - draft-ietf-dmarc-rfc7601bis-00 + draft-ietf-dmarc-rfc7601bis-01 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 August 11, 2018. + This Internet-Draft will expire on September 21, 2018. 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 @@ -51,83 +51,84 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 - 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7 - 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 8 - 1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 9 + 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.5. Authentication Identifier Field . . . . . . . . . . . . . 14 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15 2.7. Defined Methods and Result Values . . . . . . . . . . . . 16 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 - 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 + 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 - 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 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 - 4. Adding the Header Field to a Message . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 26 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 6.1. The Authentication-Results Header Field . . . . . . . . . 27 - 6.2. "Email Authentication Methods" Registry Description . . . 28 - 6.3. "Email Authentication Methods" Registry Update . . . . . . 28 - 6.4. "Email Authentication Property Types" Registry . . . . . . 28 - 6.5. "Email Authentication Result Names" Description . . . . . 28 - 6.6. "Email Authentication Result Names" Update . . . . . . . . 28 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 28 - 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 30 + 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 27 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 6.1. The Authentication-Results Header Field . . . . . . . . . 28 + 6.2. "Email Authentication Methods" Registry . . . . . . . . . 28 + 6.3. "Email Authentication Methods" Registry . . . . . . . . . 28 + 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 + 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 29 + 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 31 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31 - 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 31 - 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 31 - 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 31 - 7.7. Attacks against Authentication Methods . . . . . . . . . . 31 + 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.8. Intentionally Malformed Header Fields . . . . . . . . . . 32 - 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 32 - 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 32 - 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 32 + 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 33 + 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 33 + 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 34 - Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 36 - Appendix B. Authentication-Results Examples . . . . . . . . . . . 37 - B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 37 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 35 + Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 37 + Appendix B. Authentication-Results Examples . . . . . . . . . . . 38 + B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 38 B.2. Nearly Trivial Case; Service Provided, but No - Authentication Done . . . . . . . . . . . . . . . . . . . 38 - B.3. Service Provided, Authentication Done . . . . . . . . . . 39 + Authentication Done . . . . . . . . . . . . . . . . . . . 39 + B.3. Service Provided, Authentication Done . . . . . . . . . . 40 B.4. Service Provided, Several Authentications Done, Single - MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.5. Service Provided, Several Authentications Done, - Different MTAs . . . . . . . . . . . . . . . . . . . . . . 41 - B.6. Service Provided, Multi-tiered Authentication Done . . . . 43 - B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 44 + 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 . . . . . . . . . . . . . . . . . . . 45 - Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 46 - Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 48 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48 + Authentication . . . . . . . . . . . . . . . . . . . 46 + Appendix D. Changes Since RFC7601 . . . . . . . . . . . . . . . . 47 + Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 47 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 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 @@ -271,21 +272,30 @@ 1.5. Definitions This section defines various terms used throughout this document. 1.5.1. Key Words 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. Security +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 + 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: o "Authorization" is the establishment of permission to use a resource or represent an identity. In this context, authorization @@ -306,21 +316,21 @@ 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. -1.5.3. Email Architecture +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. o An "intermediate MTA" is any MTA that is not a delivery MTA and is @@ -353,21 +363,21 @@ authentication schemes takes place at a border MTA or a delivery MTA. This specification is written with that assumption in mind. However, there are some sites at which the entire mail infrastructure consists of a single host. In such cases, such terms as "border MTA" and "delivery MTA" might well apply to the same machine or even the very same agent. It is also possible that some message authentication tests could take place on an intermediate MTA. Although this document doesn't specifically describe such cases, they are not meant to be excluded. -1.5.4. Other Terms +1.5.5. Other Terms In this document, the term "producer" refers to any component that adds this header field to messages it is handling, and "consumer" refers to any component that identifies, extracts, and parses the header field to use as part of a handling decision. 1.6. Trust Environment This header field permits one or more message validation mechanisms to communicate output to one or more separate assessment mechanisms. @@ -490,31 +500,33 @@ special-smtp-verb = "mailfrom" / "rcptto" ; special cases of [SMTP] commands that are made up ; of multiple words pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) [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], and "CFWS" is - defined in Section 3.2.2 of [MAIL]. + "local-part" is defined in Section 3.4.1 of [MAIL], as modified by + [RFC6531]. - "Keyword" is defined in Section 4.1.2 of [SMTP]. + "CFWS" is defined in Section 3.2.2 of [MAIL]. - The "value" is as defined in Section 5.1 of [MIME]. + "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]. - The "domain-name" is as defined in Section 3.5 of [DKIM]. + "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. - The "Keyword" used in "result" above is further constrained by the - necessity of being enumerated in Section 2.7. + "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]. @@ -620,20 +632,23 @@ 2.5. Authentication Identifier Field Every Authentication-Results header field has an authentication service identifier field (authserv-id above). Specifically, this is any string intended to identify the authentication service within the ADMD that conducted authentication checks on the message. This identifier is intended to be machine-readable and not necessarily meaningful to users. + Note that in an EAI-formatted message, this identifier may be + expressed in UTF-8. + Since agents consuming this field will use this identifier to determine whether its contents are of interest (and are safe to use), the uniqueness of the identifier MUST be guaranteed by the ADMD that generates it and MUST pertain to that ADMD. MUAs or downstream filters SHOULD use this identifier to determine whether or not the data contained in an Authentication-Results header field ought to be used or ignored. For simplicity and scalability, the authentication service identifier SHOULD be a common token used throughout the ADMD. Common practice @@ -751,20 +766,30 @@ is unrecoverable, such as a required header field being absent. A later attempt is unlikely to produce a final result. DKIM results are reported using a ptype of "header". The property, 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. + 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 @@ -806,20 +831,23 @@ These result codes are used in the context of this specification to reflect the result returned by the component conducting SPF evaluation. 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 "mailfrom" value can be + expressed in UTF-8. + 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 typically @@ -903,21 +931,22 @@ such as a permanent directory service lookup error. A later attempt is not likely to produce a final result. The result of AUTH is reported using a ptype of "smtp" and a property of either: o "auth", in which case the value is the authorization identity generated by the exchange initiated by the AUTH command; or o "mailfrom", in which case the value is the mailbox identified by - the AUTH parameter used with the MAIL FROM command. + the AUTH parameter used with the MAIL FROM command. Note that in + an EAI-formatted message, these values can be expressed in UTF-8. If both identities are available, both can be reported. For example, consider this command issued by a client that has completed session authentication with the AUTH command resulting in an authorized identity of "client@c.example": MAIL FROM: AUTH= This could result in a "resinfo" construction like so: @@ -936,20 +965,23 @@ o Authorized Third-Party Signatures (in [ATPS], represented by "dkim-atps"); o Author Domain Signing Practices (in [ADSP], represented by "dkim- adsp"); o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs"); o S/MIME (in [SMIME-REG], represented by "smime"). + Note that "vbr.mv" and "vbr.md", which are already registered, are + permitted to be UTF-8 in an EAI-formatted message. + 2.7.6. Extension Methods Additional authentication method identifiers (extension methods) may be defined in the future by later revisions or extensions to this specification. These method identifiers are registered with the Internet Assigned Numbers Authority (IANA) and, preferably, published in an RFC. See Section 6 for further details. Extension methods can be defined for the following reasons: @@ -1201,20 +1231,23 @@ 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 MTA could allow a specific list of authenticating MTAs whose information is to be admitted, removing the header field originating from all others. @@ -1264,27 +1297,40 @@ found in [IANA-HEADERS]. That entry will be updated to reference this document. The following is the registration template: Header field name: Authentication-Results Applicable protocol: mail ([MAIL]) Status: Standard Author/Change controller: IETF Specification document(s): [this document] Related information: none -6.2. "Email Authentication Methods" Registry Description +6.2. "Email Authentication Methods" Registry No changes are made to this registry. -6.3. "Email Authentication Methods" Registry Update +6.3. "Email Authentication Methods" Registry - No changes are made to this registry. + The following entry is added: + + Method: dkim + + Definition: [RFC7601] + ptype: header + + property: a + + Description: value of signature "a" tag + + Status: active + + Version: 1 6.4. "Email Authentication Property Types" Registry [RFC7410] created the "Email Authentication Property Types" registry. No changes are made to this registry. However, it should be noted that Section 2.3 contains slightly different language than prior versions of this document, allowing a broader space from which to extract meaningful identifiers and report them through this mechanism. @@ -1498,20 +1544,25 @@ 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, . + [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", STD 76, + RFC 6376, DOI 10.17487/RFC6376, September 2011, + . + [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, @@ -1529,35 +1580,52 @@ [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, . + [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for + Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, + February 2012, . + + [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized + Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, + . + + [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized + Email Headers", RFC 6532, DOI 10.17487/RFC6532, + February 2012, . + [RFC6577] Kucherawy, M., "Authentication-Results Registration Update for Sender Policy Framework (SPF) Results", RFC 6577, DOI 10.17487/RFC6577, March 2012, . [RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, DOI 10.17487/ RFC7001, September 2013, . [RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/ RFC7601, August 2015, . + [RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage + Update to DomainKeys Identified Mail (DKIM)", RFC 8301, + DOI 10.17487/RFC8301, January 2018, + . + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . 8.2. Informative References [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August 2009, . @@ -1575,25 +1643,20 @@ [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/ RFC4954, July 2007, . [AUTH-ESC] Kucherawy, M., "Email Authentication Status Codes", RFC 7372, DOI 10.17487/RFC7372, September 2014, . - [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., - "DomainKeys Identified Mail (DKIM) Signatures", STD 76, - RFC 6376, DOI 10.17487/RFC6376, September 2011, - . - [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, @@ -2055,86 +2118,30 @@ delivery process has completed. This seriously diminishes the value of this work when done elsewhere than at MTAs. Many operational choices are possible within an ADMD, including the venue for performing authentication and/or reputation assessment. The current specification does not dictate any of those choices. 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 RFC 7001 - - o Applied RFC 7410. - - o Updated all references to RFC 4408 with RFC 7208. - - o Added section explaining "property" values. (Addressed Erratum - #4201.) - - o Did some minor text reorganization. - - o Gave registry history -- enough that this is now the authoritative - registry definition. - - o Added text explaining each of the method-ptype-property tuples - registered by this document. - - o Changed the meaning of the "Defined" column of the methods - registry to be the place where each entry was created and - described; it is expected that this will then refer to the - method's defining document. Provided IANA with corresponding - update instructions. - - o Cleaned up registry structure and content, and replaced all - references to RFC 7001 with pointers to this document. - - o Added references: [DMARC], [PRA], [RFC6008], [RFC6577], [RRVS], - [SMIME-REG]. - - o Added description of values that can be extracted from SMTP AUTH - sessions and an example. - - o Provided much more complete descriptions of reporting DomainKeys - results. - - o Added more detail about Sender ID. - - o Marked all ADSP and DomainKeys entries as deprecated since their - defining documents are as well. - - o Reworked some text around ignoring unknown ptypes. - - o Completely described the ptypes registry. - - o Mentioned that EHLO is mapped to HELO for SPF. - - o RFC 7208 uses all-lowercase result strings now, so adjusted prose - accordingly. - - o Updated list of supported methods, and mentioned the registries - immediately below. - - o Mentioned that when a local-part is removed, the "@" goes with it. - - o Referred to RFC 7328 in the "iprev" definition. - - o Corrected the "smime-part" prose. +Appendix D. Changes Since RFC7601 - o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the - Received fields. + o Added IANA registration for DKIM "a" property. - o Made minor editorial adjustments. + o Include EAI guidance. Appendix E. Acknowledgments The author wishes to acknowledge the following individuals for their - review and constructive criticism of this document: TBD + review and constructive criticism of this document: Seth Blank, John + Levine, Scott Kitterman Author's Address Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 United States Email: superuser@gmail.com