rfc7601.txt | draft-kucherawy-dmarc-rfc7601bis.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) M. Kucherawy | Individual submission M. Kucherawy | |||
Request for Comments: 7601 August 2015 | ||||
Obsoletes: 7001, 7410 | Obsoletes: 7601 (if approved) | |||
Category: Standards Track | Intended status: Standards Track | |||
ISSN: 2070-1721 | Expires: July 9, 2019 | |||
Message Header Field for Indicating Message Authentication Status | Message Header Field for Indicating Message Authentication Status | |||
draft-ietf-dmarc-rfc7601bis-05 | ||||
Abstract | Abstract | |||
This document specifies a message header field called Authentication- | This document specifies a message header field called Authentication- | |||
Results for use with electronic mail messages to indicate the results | Results for use with electronic mail messages to indicate the results | |||
of message authentication efforts. Any receiver-side software, such | of message authentication efforts. Any receiver-side software, such | |||
as mail filters or Mail User Agents (MUAs), can use this header field | 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 | to relay that information in a convenient and meaningful way to users | |||
or to make sorting and filtering decisions. | or to make sorting and filtering decisions. | |||
Status of This Memo | This document obsoletes [RFC7601]. | |||
This is an Internet Standards Track document. | Status of this Memo | |||
This document is a product of the Internet Engineering Task Force | This Internet-Draft is submitted in full conformance with the | |||
(IETF). It represents the consensus of the IETF community. It has | provisions of BCP 78 and BCP 79. | |||
received public review and has been approved for publication by the | ||||
Internet Engineering Steering Group (IESG). Further information on | ||||
Internet Standards is available in Section 2 of RFC 5741. | ||||
Information about the current status of this document, any errata, | Internet-Drafts are working documents of the Internet Engineering | |||
and how to provide feedback on it may be obtained at | Task Force (IETF). Note that other groups may also distribute | |||
http://www.rfc-editor.org/info/rfc7601. | 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 9, 2019. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . 6 | 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 | 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 6 | 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 | |||
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . 7 | 1.5.2. Internationalized Email . . . . . . . . . . . . . . . 7 | |||
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . 7 | 1.5.3. Security . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8 | 1.5.4. Email Architecture . . . . . . . . . . . . . . . . . . 8 | |||
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 8 | 1.5.5. Other Terms . . . . . . . . . . . . . . . . . . . . . 9 | |||
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9 | ||||
2. Definition and Format of the Header Field . . . . . . . . . . 9 | 2. Definition and Format of the Header Field . . . . . . . . . . 9 | |||
2.1. General Description . . . . . . . . . . . . . . . . . . . 9 | 2.1. General Description . . . . . . . . . . . . . . . . . . . 10 | |||
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10 | 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10 | |||
2.3. Property Types (ptypes) and Properties . . . . . . . . . 12 | 2.3. Property Types (ptypes) and Properties . . . . . . . . . . 13 | |||
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13 | 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 14 | |||
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 | 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 | |||
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15 | 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 16 | |||
2.7. Defined Methods and Result Values . . . . . . . . . . . . 15 | 2.7. Defined Methods and Result Values . . . . . . . . . . . . 16 | |||
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 | 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 | |||
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18 | 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18 | |||
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 | 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20 | 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20 | |||
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 21 | 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 21 | |||
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21 | 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 22 | |||
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 22 | 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 23 | |||
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 | 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 23 | |||
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.1. Header Field Position and Interpretation . . . . . . . . . 26 | |||
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 26 | 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 27 | |||
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 | 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 27 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
6.1. The Authentication-Results Header Field . . . . . . . . . 27 | 6.1. The Authentication-Results Header Field . . . . . . . . . 29 | |||
6.2. "Email Authentication Methods" Registry Description . . . 28 | 6.2. "Email Authentication Methods" Registry Description . . . 29 | |||
6.3. "Email Authentication Methods" Registry Update . . . . . 29 | 6.3. "Email Authentication Methods" Registry Update . . . . . . 30 | |||
6.4. "Email Authentication Property Types" Registry . . . . . 30 | 6.3.1. 'header.a' for DKIM . . . . . . . . . . . . . . . . . 31 | |||
6.5. "Email Authentication Result Names" Description . . . . . 31 | 6.3.2. 'header.s' for DKIM . . . . . . . . . . . . . . . . . 32 | |||
6.6. "Email Authentication Result Names" Update . . . . . . . 32 | 6.4. "Email Authentication Property Types" Registry | |||
6.7. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . 33 | Description . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 6.5. "Email Authentication Property Types" Registry Update . . 33 | |||
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 33 | 6.6. "Email Authentication Result Names" Registry | |||
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 35 | Description . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35 | 6.7. "Email Authentication Result Names" Registry Update . . . 33 | |||
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 35 | 6.8. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . . 34 | |||
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 36 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 36 | 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 34 | |||
7.7. Attacks against Authentication Methods . . . . . . . . . 36 | 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 36 | |||
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36 | 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 36 | |||
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 36 | 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 36 | |||
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 37 | 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 37 | |||
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 37 | 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 37 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 | 7.7. Attacks against Authentication Methods . . . . . . . . . . 37 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 37 | 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 37 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 38 | 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 37 | |||
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 42 | 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 38 | |||
Appendix B. Authentication-Results Examples . . . . . . . . . . 42 | 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 38 | |||
B.1. Trivial Case; Header Field Not Present . . . . . . . . . 42 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 | ||||
8.2. Informative References . . . . . . . . . . . . . . . . . . 39 | ||||
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 42 | ||||
Appendix B. Authentication-Results Examples . . . . . . . . . . . 43 | ||||
B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 43 | ||||
B.2. Nearly Trivial Case; Service Provided, but No | B.2. Nearly Trivial Case; Service Provided, but No | |||
Authentication Done . . . . . . . . . . . . . . . . . . . 43 | Authentication Done . . . . . . . . . . . . . . . . . . . 44 | |||
B.3. Service Provided, Authentication Done . . . . . . . . . . 44 | B.3. Service Provided, Authentication Done . . . . . . . . . . 45 | |||
B.4. Service Provided, Several Authentications Done, Single | B.4. Service Provided, Several Authentications Done, Single | |||
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
B.5. Service Provided, Several Authentications Done, Different | B.5. Service Provided, Several Authentications Done, | |||
MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 46 | Different MTAs . . . . . . . . . . . . . . . . . . . . . . 47 | |||
B.6. Service Provided, Multi-tiered Authentication Done . . . 48 | B.6. Service Provided, Multi-tiered Authentication Done . . . . 49 | |||
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 49 | B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 50 | |||
Appendix C. Operational Considerations about Message | Appendix C. Operational Considerations about Message | |||
Authentication . . . . . . . . . . . . . . . . . . . 50 | Authentication . . . . . . . . . . . . . . . . . . . 51 | |||
Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 51 | Appendix D. Changes since RFC7601 . . . . . . . . . . . . . . . . 52 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53 | Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 53 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
1. Introduction | 1. Introduction | |||
This document describes a header field called Authentication-Results | This document describes a header field called Authentication-Results | |||
for electronic mail messages that presents the results of a message | for electronic mail messages that presents the results of a message | |||
authentication effort in a machine-readable format. The intent of | authentication effort in a machine-readable format. The intent of | |||
the header field is to create a place to collect such data when | the header field is to create a place to collect such data when | |||
message authentication mechanisms are in use so that a Mail User | message authentication mechanisms are in use so that a Mail User | |||
Agent (MUA) and downstream filters can make filtering decisions and/ | Agent (MUA) and downstream filters can make filtering decisions | |||
or provide a recommendation to the user as to the validity of the | and/or provide a recommendation to the user as to the validity of the | |||
message's origin and possibly the safety and integrity of its | message's origin and possibly the safety and integrity of its | |||
content. | content. | |||
This document revises the original definition found in [RFC5451] | ||||
based upon various authentication protocols in current use and | ||||
incorporates errata logged since the publication of the original | ||||
specification. | ||||
End users are not expected to be direct consumers of this header | End users are not expected to be direct consumers of this header | |||
field. This header field is intended for consumption by programs | field. This header field is intended for consumption by programs | |||
that will then use such data or render it in a human-usable form. | that will then use such data or render it in a human-usable form. | |||
This document specifies the format of this header field and discusses | This document specifies the format of this header field and discusses | |||
the implications of its presence or absence. However, it does not | the implications of its presence or absence. However, it does not | |||
discuss how the data contained in the header field ought to be used, | 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 | such as what filtering decisions are appropriate or how an MUA might | |||
render those results, as these are local policy and/or user interface | render those results, as these are local policy and/or user interface | |||
design questions that are not appropriate for this document. | design questions that are not appropriate for this document. | |||
skipping to change at page 4, line 36 | skipping to change at page 5, line 4 | |||
o reverse IP address name validation ("iprev", defined in Section 3) | o reverse IP address name validation ("iprev", defined in Section 3) | |||
o Require-Recipient-Valid-Since Header Field and SMTP Service | o Require-Recipient-Valid-Since Header Field and SMTP Service | |||
Extension ([RRVS]) | Extension ([RRVS]) | |||
o S/MIME Signature Verification ([SMIME-REG]) | o S/MIME Signature Verification ([SMIME-REG]) | |||
o Vouch By Reference ([VBR]) | o Vouch By Reference ([VBR]) | |||
o DomainKeys ([DOMAINKEYS]) (Historic) | o DomainKeys ([DOMAINKEYS]) (Historic) | |||
o Sender ID ([SENDERID]) (Experimental) | o Sender ID ([SENDERID]) (Experimental) | |||
There exist registries for tokens used within this header field that | There exist registries for tokens used within this header field that | |||
refer to the specifications listed above. Section 6 describes the | refer to the specifications listed above. Section 6 describes the | |||
registries and their contents and specifies the process by which | registries and their contents and specifies the process by which | |||
entries are added or updated. It also updates the existing contents | entries are added or updated. It also updates the existing contents | |||
to match the current states of these specifications. | to match the current states of these specifications. | |||
This specification is not intended to be restricted to domain-based | The goal of this work is to give current and future authentication | |||
authentication schemes, but the existing schemes in that family have | schemes a common framework within which to deliver their results to | |||
proven to be a good starting point for implementations. The goal is | downstream agents and discourage the creation of unique header fields | |||
to give current and future authentication schemes a common framework | for each. | |||
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 | Although SPF defined a header field called "Received-SPF" and the | |||
historic DomainKeys defined one called "DomainKey-Status" for this | historic DomainKeys defined one called "DomainKey-Status" for this | |||
purpose, those header fields are specific to the conveyance of their | purpose, those header fields are specific to the conveyance of their | |||
respective results only and thus are insufficient to satisfy the | respective results only and thus are insufficient to satisfy the | |||
requirements enumerated below. In addition, many SPF implementations | requirements enumerated below. In addition, many SPF implementations | |||
have adopted the header field specified here at least as an option, | have adopted the header field specified here at least as an option, | |||
and DomainKeys has been obsoleted by DKIM. | and DomainKeys has been obsoleted by DKIM. | |||
1.1. Purpose | 1.1. Purpose | |||
skipping to change at page 5, line 32 | skipping to change at page 5, line 44 | |||
results to end users or to use those data to apply more or less | results to end users or to use those data to apply more or less | |||
stringent content checks based on authentication results; | stringent content checks based on authentication results; | |||
2. Provide a common location within a message for this data; | 2. Provide a common location within a message for this data; | |||
3. Create an extensible framework for reporting new authentication | 3. Create an extensible framework for reporting new authentication | |||
methods as they emerge. | methods as they emerge. | |||
In particular, the mere presence of this header field does not mean | In particular, the mere presence of this header field does not mean | |||
its contents are valid. Rather, the header field is reporting | its contents are valid. Rather, the header field is reporting | |||
assertions made by one or more authentication schemes (supposedly) | assertions made by one or more authentication schemes applied | |||
applied somewhere upstream. For an MUA or downstream filter to treat | somewhere upstream. For an MUA or downstream filter to treat the | |||
the assertions as actually valid, there must be an assessment of the | assertions as actually valid, there must be an assessment of the | |||
trust relationship among such agents, the validating MTA, and the | trust relationship among such agents, the validating MTA, the paths | |||
mechanism for conveying the information. | between them, and the mechanism for conveying the information. | |||
1.2. Trust Boundary | 1.2. Trust Boundary | |||
This document makes several references to the "trust boundary" of an | This document makes several references to the "trust boundary" of an | |||
administrative management domain (ADMD). Given the diversity among | administrative management domain (ADMD). Given the diversity among | |||
existing mail environments, a precise definition of this term isn't | existing mail environments, a precise definition of this term isn't | |||
possible. | possible. | |||
Simply put, a transfer from the producer of the header field to the | Simply put, a transfer from the producer of the header field to the | |||
consumer must occur within a context that permits the consumer to | consumer must occur within a context that permits the consumer to | |||
skipping to change at page 6, line 51 | skipping to change at page 7, line 15 | |||
their discretion. | their discretion. | |||
1.5. Definitions | 1.5. Definitions | |||
This section defines various terms used throughout this document. | This section defines various terms used throughout this document. | |||
1.5.1. Key Words | 1.5.1. Key Words | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [KEYWORDS]. | document are to be interpreted as described in BCP 14 [RFC2119] | |||
[RFC8174] when, and only when, they appear in all capitals, as shown | ||||
here. | ||||
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" | "Guidelines for Writing RFC Text on Security Considerations" | |||
([SECURITY]) discusses authentication and authorization and the | ([SECURITY]) discusses authentication and authorization and the | |||
conflation of the two concepts. The use of those terms within the | conflation of the two concepts. The use of those terms within the | |||
context of recent message security work has given rise to slightly | context of recent message security work has given rise to slightly | |||
different definitions, and this document reflects those current | different definitions, and this document reflects those current | |||
usages, as follows: | usages, as follows: | |||
o "Authorization" is the establishment of permission to use a | o "Authorization" is the establishment of permission to use a | |||
resource or represent an identity. In this context, authorization | resource or represent an identity. In this context, authorization | |||
indicates that a message from a particular ADMD arrived via a | indicates that a message from a particular ADMD arrived via a | |||
route the ADMD has explicitly approved. | route the ADMD has explicitly approved. | |||
o "Authentication" is the assertion of validity of a piece of data | 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 | about a message (such as the sender's identity) or the message in | |||
its entirety. | its entirety. | |||
As examples: SPF and Sender ID are authorization mechanisms in that | As examples: SPF and Sender ID are authorization mechanisms in that | |||
they express a result that shows whether or not the ADMD that | they express a result that shows whether the ADMD that apparently | |||
apparently sent the message has explicitly authorized the connecting | sent the message has explicitly authorized the connecting Simple Mail | |||
Simple Mail Transfer Protocol ([SMTP]) client to relay messages on | Transfer Protocol ([SMTP]) client to relay messages on its behalf, | |||
its behalf, but they do not actually validate any other property of | but they do not actually validate any other property of the message | |||
the message itself. By contrast, DKIM is agnostic as to the routing | itself. By contrast, DKIM is agnostic as to the routing of a message | |||
of a message but uses cryptographic signatures to authenticate | but uses cryptographic signatures to authenticate agents, assign | |||
agents, assign (some) responsibility for the message (which implies | (some) responsibility for the message (which implies authorization), | |||
authorization), and ensure that the listed portions of the message | and ensure that the listed portions of the message were not modified | |||
were not modified in transit. Since the signatures are not tied to | in transit. Since the signatures are not tied to SMTP connections, | |||
SMTP connections, they can be added by either the ADMD of origin, | they can be added by either the ADMD of origin, intermediate ADMDs | |||
intermediate ADMDs (such as a mailing list server), other handling | (such as a mailing list server), other handling agents, or any | |||
agents, or any combination. | combination. | |||
Rather than create a separate header field for each class of | 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.3. Email Architecture | 1.5.4. Email Architecture | |||
o A "border MTA" is an MTA that acts as a gateway between the | o A "border MTA" is an MTA that acts as a gateway between the | |||
general Internet and the users within an organizational boundary. | general Internet and the users within an organizational boundary. | |||
(See also Section 1.2.) | (See also Section 1.2.) | |||
o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that | 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 | actually enacts delivery of a message to a user's inbox or other | |||
final delivery. | final delivery. | |||
o An "intermediate MTA" is any MTA that is not a delivery MTA and is | o An "intermediate MTA" is any MTA that is not a delivery MTA and is | |||
skipping to change at page 8, line 39 | skipping to change at page 9, line 15 | |||
authentication schemes takes place at a border MTA or a delivery MTA. | authentication schemes takes place at a border MTA or a delivery MTA. | |||
This specification is written with that assumption in mind. However, | This specification is written with that assumption in mind. However, | |||
there are some sites at which the entire mail infrastructure consists | there are some sites at which the entire mail infrastructure consists | |||
of a single host. In such cases, such terms as "border MTA" and | 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 | "delivery MTA" might well apply to the same machine or even the very | |||
same agent. It is also possible that some message authentication | same agent. It is also possible that some message authentication | |||
tests could take place on an intermediate MTA. Although this | tests could take place on an intermediate MTA. Although this | |||
document doesn't specifically describe such cases, they are not meant | document doesn't specifically describe such cases, they are not meant | |||
to be excluded. | to be excluded. | |||
1.5.4. Other Terms | 1.5.5. Other Terms | |||
In this document, the term "producer" refers to any component that | In this document, the term "producer" refers to any component that | |||
adds this header field to messages it is handling, and "consumer" | adds this header field to messages it is handling, and "consumer" | |||
refers to any component that identifies, extracts, and parses the | refers to any component that identifies, extracts, and parses the | |||
header field to use as part of a handling decision. | header field to use as part of a handling decision. | |||
1.6. Trust Environment | 1.6. Trust Environment | |||
This header field permits one or more message validation mechanisms | This header field permits one or more message validation mechanisms | |||
to communicate output to one or more separate assessment mechanisms. | to communicate output to one or more separate assessment mechanisms. | |||
These mechanisms operate within a unified trust boundary that defines | These mechanisms operate within a unified trust boundary that defines | |||
an Administrative Management Domain (ADMD). An ADMD contains one or | an Administrative Management Domain (ADMD). An ADMD contains one or | |||
more entities that perform validation and generate the header field | more entities that perform validation and generate the header field | |||
and one or more that consume it for some type of assessment. The | and one or more that consume it for some type of assessment. The | |||
field often contains no integrity or validation mechanism of its own, | field often contains no integrity or validation mechanism of its own, | |||
so its presence must be trusted implicitly. Hence, valid use of the | so its presence must be trusted implicitly. Hence, valid use of the | |||
header field requires removing any occurrences of it that are present | header field requires removing any occurrences of it that claim to be | |||
when the message enters the ADMD. This ensures that later | associated with the ADMD when the message enters the ADMD. This | |||
occurrences have been added within the trust boundary of the ADMD. | 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 | 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. | an entire ADMD or a specific validation engine within an ADMD. | |||
Although the labeling scheme is left as an operational choice, some | Although the labeling scheme is left as an operational choice, some | |||
guidance for selecting a token is provided in later sections of this | guidance for selecting a token is provided in later sections of this | |||
document. | document. | |||
2. Definition and Format of the Header Field | 2. Definition and Format of the Header Field | |||
This section gives a general overview of the format of the header | 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 | 2.1. General Description | |||
The header field specified here is called Authentication-Results. It | The header field specified here is called Authentication-Results. It | |||
is a Structured Header Field as defined in Internet Message Format | is a Structured Header Field as defined in Internet Message Format | |||
([MAIL]), and thus all of the related definitions in that document | ([MAIL]), and thus all of the related definitions in that document | |||
apply. | apply. | |||
This header field is added at the top of the message as it transits | 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 | MTAs that do authentication checks, so some idea of how far away the | |||
skipping to change at page 10, line 7 | skipping to change at page 10, line 33 | |||
supporting data can include a "reason" string and one or more | supporting data can include a "reason" string and one or more | |||
"property=value" statements indicating which message properties were | "property=value" statements indicating which message properties were | |||
evaluated to reach that conclusion. | evaluated to reach that conclusion. | |||
The header field can appear more than once in a single message, more | The header field can appear more than once in a single message, more | |||
than one result can be represented in a single header field, or a | than one result can be represented in a single header field, or a | |||
combination of these can be applied. | combination of these can be applied. | |||
2.2. Formal Definition | 2.2. Formal Definition | |||
Formally, the header field is specified as follows using Augmented | Formally, the header field is specified as shown below using | |||
Backus-Naur Form ([ABNF]): | Augmented Backus-Naur Form ([ABNF]). Examples of valid header fields | |||
with explanations of their semantics can be found in Appendix B. | ||||
authres-header = "Authentication-Results:" [CFWS] authserv-id | authres-header-field = "Authentication-Results:" authres-payload | |||
authres-payload = "Authentication-Results:" [CFWS] authserv-id | ||||
[ CFWS authres-version ] | [ CFWS authres-version ] | |||
( no-result / 1*resinfo ) [CFWS] CRLF | ( no-result / 1*resinfo ) [CFWS] CRLF | |||
authserv-id = value | authserv-id = value | |||
; see below for a description of this element | ; see below for a description of this element | |||
authres-version = 1*DIGIT [CFWS] | authres-version = 1*DIGIT [CFWS] | |||
; indicates which version of this specification is in use; | ; indicates which version of this specification is in use; | |||
; this specification is version "1", and the absence of a | ; this specification is version "1", and the absence of a | |||
; version implies this version of the specification | ; version implies this version of the specification | |||
skipping to change at page 11, line 22 | skipping to change at page 12, line 4 | |||
; the message body, or was some other property evaluated by | ; the message body, or was some other property evaluated by | |||
; the receiving MTA; expected to be one of the "property | ; the receiving MTA; expected to be one of the "property | |||
; types" explicitly defined as valid, or an extension | ; types" explicitly defined as valid, or an extension | |||
; ptype, as defined below | ; ptype, as defined below | |||
property = special-smtp-verb / Keyword | property = special-smtp-verb / Keyword | |||
; indicates more specifically than "ptype" what the | ; indicates more specifically than "ptype" what the | |||
; source of the evaluated property is; the exact meaning | ; source of the evaluated property is; the exact meaning | |||
; is specific to the method whose result is being reported | ; is specific to the method whose result is being reported | |||
; and is defined more clearly below | ; and is defined more clearly below | |||
special-smtp-verb = "mailfrom" / "rcptto" | special-smtp-verb = "mailfrom" / "rcptto" | |||
; special cases of [SMTP] commands that are made up | ; special cases of [SMTP] commands that are made up | |||
; of multiple words | ; of multiple words | |||
pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) | pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) | |||
[CFWS] | [CFWS] | |||
; the value extracted from the message property defined | ; the value extracted from the message property defined | |||
; by the "ptype.property" construction | ; by the "ptype.property" construction | |||
"local-part" is defined in Section 3.4.1 of [MAIL], and "CFWS" is | "local-part" is defined in Section 3.4.1 of [MAIL], as modified by | |||
defined in Section 3.2.2 of [MAIL]. | [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]. | "Keyword" is defined in Section 4.1.2 of [SMTP]. It is further | |||
constrained by the necesity of being registered in the IANA registry | ||||
relevant to the context in which it it is used. See Section 2.7, and | ||||
Section 2.3, and Section 6. | ||||
The "value" is as defined in Section 5.1 of [MIME], with "quoted- | ||||
string" updated as specified in [RFC6532]. | ||||
The "domain-name" is as defined in Section 3.5 of [DKIM]. | The "domain-name" is as defined in Section 3.5 of [DKIM]. | |||
The "Keyword" used in "result" above is further constrained by the | The "Keyword" used in "result" above is further constrained by the | |||
necessity of being enumerated in Section 2.7. | necessity of being enumerated in Section 2.7. | |||
See Section 2.5 for a description of the authserv-id element. | See Section 2.5 for a description of the authserv-id element. | |||
If the value portion of a "pvalue" construction identifies something | If the value portion of a "pvalue" construction identifies something | |||
intended to be an email identity, then it MUST use the right hand | intended to be an email identity, then it MUST use the right hand | |||
portion of that ABNF definition. | portion of that ABNF definition. | |||
The list of commands eligible for use with the "smtp" ptype can be | The list of commands eligible for use with the "smtp" ptype can be | |||
found in Section 4.1 of [SMTP]. | found in Section 4.1 of [SMTP]. | |||
The "propspec" may be omitted if, for example, the method was unable | 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 | to extract any properties to do its evaluation yet still has a result | |||
report. | 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 | Where an SMTP command name is being reported as a "property", the | |||
agent generating the header field represents that command by | agent generating the header field represents that command by | |||
converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" | converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" | |||
becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). | becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). | |||
A "ptype" value of "policy" indicates a policy decision about the | A "ptype" value of "policy" indicates a policy decision about the | |||
message not specific to a property of the message that could be | message not specific to a property of the message that could be | |||
extracted. See Section 2.4 for details. | extracted. See Section 2.4 for details. | |||
Examples of complete messages using this header field can be found in | Examples of complete messages using this header field can be found in | |||
Appendix B. | Appendix B. | |||
2.3. Property Types (ptypes) and Properties | 2.3. Property Types (ptypes) and Properties | |||
The "ptype" in the ABNF above indicates the general type of property | The "ptype" in the ABNF above indicates the general type of property | |||
being described by the result being reported, upon which the reported | being described by the result being reported, upon which the reported | |||
result was based. Coupled with the "property", which is more | result was based. Coupled with the "property", which is more | |||
specific, they indicate from which particular part of the message the | specific, they indicate from where the reported data were extracted. | |||
reported data were extracted. | This can include a particular part of the message header or body, | |||
some part of the SMTP session, a secondary output of an | ||||
authentication method (apart from its pure result), or some other | ||||
aspect of the message's handling. | ||||
Combinations of ptypes and properties are registered and described in | Combinations of ptypes and properties are registered and described in | |||
the "Email Authentication Methods" registry, coupled with the | the "Email Authentication Methods" registry, coupled with the | |||
authentication methods with which they are used. This is further | authentication methods with which they are used. This is further | |||
described in Section 6. | described in Section 6. | |||
Legal values of "ptype" are as defined in the IANA "Email | Legal values of "ptype" are as defined in the IANA "Email | |||
Authentication Property Types" registry, created by [RFC7410]. The | Authentication Property Types" registry, created by [RFC7410]. The | |||
initial values and what they typically indicate are as follows, based | initial values and what they typically indicate are as follows, based | |||
on [RFC7001]: | on [RFC7001]: | |||
skipping to change at page 13, line 39 | skipping to change at page 14, line 29 | |||
For example, a DKIM signature is not required to include the Subject | 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 | header field in the set of fields that are signed. An ADMD receiving | |||
such a message might decide that such a signature is unacceptable, | such a message might decide that such a signature is unacceptable, | |||
even if it passes, because the content of the Subject header field | even if it passes, because the content of the Subject header field | |||
could be altered post-signing without invalidating the signature. | could be altered post-signing without invalidating the signature. | |||
Such an ADMD could replace the DKIM "pass" result with a "policy" | Such an ADMD could replace the DKIM "pass" result with a "policy" | |||
result and then also include the following in the corresponding | result and then also include the following in the corresponding | |||
Authentication-Result field: | 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 | In this case, the property is "dkim-rules", indicating some local | |||
check by that name took place and that check returned a result of | check by that name took place and that check returned a result of | |||
"unsigned-subject". These are arbitrary names selected by (and | "unsigned-subject". These are arbitrary names selected by (and | |||
presumably used within) the ADMD making use of them, so they are not | presumably used within) the ADMD making use of them, so they are not | |||
normally registered with IANA or otherwise specified apart from | normally registered with IANA or otherwise specified apart from | |||
setting syntax restrictions that allow for easy parsing within the | setting syntax restrictions that allow for easy parsing within the | |||
rest of the header field. | rest of the header field. | |||
This ptype existed in the original specification for this header | This ptype existed in the original specification for this header | |||
skipping to change at page 14, line 18 | skipping to change at page 15, line 6 | |||
2.5. Authentication Identifier Field | 2.5. Authentication Identifier Field | |||
Every Authentication-Results header field has an authentication | Every Authentication-Results header field has an authentication | |||
service identifier field (authserv-id above). Specifically, this is | service identifier field (authserv-id above). Specifically, this is | |||
any string intended to identify the authentication service within the | any string intended to identify the authentication service within the | |||
ADMD that conducted authentication checks on the message. This | ADMD that conducted authentication checks on the message. This | |||
identifier is intended to be machine-readable and not necessarily | identifier is intended to be machine-readable and not necessarily | |||
meaningful to users. | 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 | Since agents consuming this field will use this identifier to | |||
determine whether its contents are of interest (and are safe to use), | determine whether its contents are of interest (and are safe to use), | |||
the uniqueness of the identifier MUST be guaranteed by the ADMD that | the uniqueness of the identifier MUST be guaranteed by the ADMD that | |||
generates it and MUST pertain to that ADMD. MUAs or downstream | generates it and MUST pertain to that ADMD. MUAs or downstream | |||
filters SHOULD use this identifier to determine whether or not the | filters SHOULD use this identifier to determine whether or not the | |||
data contained in an Authentication-Results header field ought to be | data contained in an Authentication-Results header field ought to be | |||
used or ignored. | used or ignored. | |||
For simplicity and scalability, the authentication service identifier | For simplicity and scalability, the authentication service identifier | |||
SHOULD be a common token used throughout the ADMD. Common practice | 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 | is to use the DNS domain name used by or within that ADMD, sometimes | |||
called the "organizational domain", but this is not strictly | called the "organizational domain", but this is not strictly | |||
necessary. | necessary. | |||
For tracing and debugging purposes, the authentication identifier can | For tracing and debugging purposes, the authentication identifier can | |||
instead be the specific hostname of the MTA performing the | instead be the specific hostname of the MTA performing the | |||
authentication check whose result is being reported. Moreover, some | authentication check whose result is being reported. Moreover, some | |||
implementations define a substructure to the identifier; these are | implementations define a substructure to the identifier; such | |||
outside of the scope of this specification. | structures are outside of the scope of this specification. | |||
Note, however, that using a local, relative identifier like a flat | Note, however, that using a local, relative identifier like a flat | |||
hostname, rather than a hierarchical and globally unique ADMD | hostname, rather than a hierarchical and globally unique ADMD | |||
identifier like a DNS domain name, makes configuration more difficult | identifier like a DNS domain name, makes configuration more difficult | |||
for large sites. The hierarchical identifier permits aggregating | for large sites. The hierarchical identifier permits aggregating | |||
related, trusted systems together under a single, parent identifier, | related, trusted systems together under a single, parent identifier, | |||
which in turn permits assessing the trust relationship with a single | which in turn permits assessing the trust relationship with a single | |||
reference. The alternative is a flat namespace requiring | reference. The alternative is a flat namespace requiring | |||
individually listing each trusted system. Since consumers will use | individually listing each trusted system. Since consumers will use | |||
the identifier to determine whether to use the contents of the header | the identifier to determine whether to use the contents of the header | |||
skipping to change at page 17, line 8 | skipping to change at page 17, line 44 | |||
is unrecoverable, such as a required header field being absent. A | is unrecoverable, such as a required header field being absent. A | |||
later attempt is unlikely to produce a final result. | later attempt is unlikely to produce a final result. | |||
DKIM results are reported using a ptype of "header". The property, | DKIM results are reported using a ptype of "header". The property, | |||
however, represents one of the tags found in the DKIM-Signature | however, represents one of the tags found in the DKIM-Signature | |||
header field rather than a distinct header field. For example, the | header field rather than a distinct header field. For example, the | |||
ptype-property combination "header.d" refers to the content of the | ptype-property combination "header.d" refers to the content of the | |||
"d" (signing domain) tag from within the signature header field, and | "d" (signing domain) tag from within the signature header field, and | |||
not a distinct header field called "d". | 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 | The ability to report different DKIM results for a message with | |||
multiple signatures is described in [RFC6008]. | multiple signatures is described in [RFC6008]. | |||
[DKIM] advises that if a message fails verification, it is to be | [DKIM] advises that if a message fails verification, it is to be | |||
treated as an unsigned message. A report of "fail" here permits the | 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 | receiver of the report to decide how to handle the failure. A report | |||
of "neutral" or "none" preempts that choice, ensuring the message | of "neutral" or "none" preempts that choice, ensuring the message | |||
will be treated as if it had not been signed. | will be treated as if it had not been signed. | |||
Section 3.1 of [DOMAINKEYS] describes a process by which the sending | Section 3.1 of [DOMAINKEYS] describes a process by which the sending | |||
skipping to change at page 18, line 11 | skipping to change at page 18, line 32 | |||
included with any [MAIL]-style comments removed; moreover, the local- | included with any [MAIL]-style comments removed; moreover, the local- | |||
part of the address and the "@" character are removed if it has not | part of the address and the "@" character are removed if it has not | |||
been authenticated in some way. | been authenticated in some way. | |||
2.7.2. SPF and Sender ID | 2.7.2. SPF and Sender ID | |||
SPF and Sender ID use the "spf" and "sender-id" method names, | SPF and Sender ID use the "spf" and "sender-id" method names, | |||
respectively. The result values for SPF are defined in Section 2.6 | respectively. The result values for SPF are defined in Section 2.6 | |||
of [SPF], and those definitions are included here by reference: | of [SPF], and those definitions are included here by reference: | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| Code | Meaning | | | Code | Meaning | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| none | [RFC7208], Section 2.6.1 | | | none | [SPF], Section 2.6.1 | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| pass | [RFC7208], Section 2.6.3 | | | pass | [SPF], Section 2.6.3 | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| fail | [RFC7208], Section 2.6.4 | | | fail | [SPF], Section 2.6.4 | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| softfail | [RFC7208], Section 2.6.5 | | | softfail | [SPF], Section 2.6.5 | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| policy | RFC 7601, Section 2.4 | | | policy | [this document], Section 2.4 | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| neutral | [RFC7208], Section 2.6.2 | | | neutral | [SPF], Section 2.6.2 | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| temperror | [RFC7208], Section 2.6.6 | | | temperror | [SPF], Section 2.6.6 | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
| permerror | [RFC7208], Section 2.6.7 | | | permerror | [SPF], Section 2.6.7 | | |||
+-----------+--------------------------------+ | +-----------+------------------------------+ | |||
These result codes are used in the context of this specification to | These result codes are used in the context of this specification to | |||
reflect the result returned by the component conducting SPF | reflect the result returned by the component conducting SPF | |||
evaluation. | evaluation. | |||
For SPF, the ptype used is "smtp", and the property is either | For SPF, the ptype used is "smtp", and the property is either | |||
"mailfrom" or "helo", since those values are the ones SPF can | "mailfrom" or "helo", since those values are the ones SPF can | |||
evaluate. (If the SMTP client issued the EHLO command instead of | evaluate. (If the SMTP client issued the EHLO command instead of | |||
HELO, the property used is "helo".) | 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 "sender-id" method is described in [SENDERID]. For this method, | |||
the ptype used is "header" and the property will be the name of the | the ptype used is "header" and the property will be the name of the | |||
header field from which the Purported Responsible Address (see [PRA]) | header field from which the Purported Responsible Address (see [PRA]) | |||
was extracted -- namely, one of "Resent-Sender", "Resent-From", | was extracted -- namely, one of "Resent-Sender", "Resent-From", | |||
"Sender", or "From". | "Sender", or "From". | |||
The results for Sender ID are listed and described in Section 4.2 of | The results for Sender ID are listed and described in Section 4.2 of | |||
[SENDERID], but for the purposes of this specification, the SPF | [SENDERID], but for the purposes of this specification, the SPF | |||
definitions enumerated above are used instead. Also, [SENDERID] | definitions enumerated above are used instead. Also, [SENDERID] | |||
specifies result codes that use mixed case, but they are typically | specifies result codes that use mixed case, but they are used all | |||
used all lowercase in this context. | lowercase in this context. | |||
For both methods, an additional result of "policy" is defined, which | For both methods, an additional result of "policy" is defined, which | |||
means the client was authorized to inject or relay mail on behalf of | means the client was authorized to inject or relay mail on behalf of | |||
the sender's DNS domain according to the authentication method's | the sender's DNS domain according to the authentication method's | |||
algorithm, but local policy dictates that the result is unacceptable. | algorithm, but local policy dictates that the result is unacceptable. | |||
For example, "policy" might be used if SPF returns a "pass" result, | 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 | but a local policy check matches the sending DNS domain to one found | |||
in an explicit list of unacceptable DNS domains (e.g., spammers). | in an explicit list of unacceptable DNS domains (e.g., spammers). | |||
If the retrieved sender policies used to evaluate SPF and Sender ID | If the retrieved sender policies used to evaluate SPF and Sender ID | |||
skipping to change at page 20, line 43 | skipping to change at page 21, line 21 | |||
The result of AUTH is reported using a ptype of "smtp" and a property | The result of AUTH is reported using a ptype of "smtp" and a property | |||
of either: | of either: | |||
o "auth", in which case the value is the authorization identity | o "auth", in which case the value is the authorization identity | |||
generated by the exchange initiated by the AUTH command; or | generated by the exchange initiated by the AUTH command; or | |||
o "mailfrom", in which case the value is the mailbox identified by | 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, | If both identities are available, both can be reported. For example, | |||
consider this command issued by a client that has completed session | consider this command issued by a client that has completed session | |||
authentication with the AUTH command resulting in an authorized | authentication with the AUTH command resulting in an authorized | |||
identity of "client@c.example": | identity of "client@c.example": | |||
MAIL FROM:<alice@a.example> AUTH=<bob@b.example> | MAIL FROM:<alice@a.example> AUTH=<bob@b.example> | |||
This could result in a "resinfo" construction like so: | This could result in a "resinfo" construction like so: | |||
; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example | ; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example | |||
skipping to change at page 21, line 19 | skipping to change at page 22, line 4 | |||
Result codes were also registered in other RFCs as follows: | Result codes were also registered in other RFCs as follows: | |||
o Vouch By Reference (in [AR-VBR], represented by "vbr"); | o Vouch By Reference (in [AR-VBR], represented by "vbr"); | |||
o Authorized Third-Party Signatures (in [ATPS], represented by | o Authorized Third-Party Signatures (in [ATPS], represented by | |||
"dkim-atps"); | "dkim-atps"); | |||
o Author Domain Signing Practices (in [ADSP], represented by "dkim- | o Author Domain Signing Practices (in [ADSP], represented by "dkim- | |||
adsp"); | adsp"); | |||
o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs"); | o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs"); | |||
o S/MIME (in [SMIME-REG], represented by "smime"). | o S/MIME (in [SMIME-REG], represented by "smime"). | |||
Note that in an EAI-formatted message, "vbr.mv" and "vbr.md", which | ||||
are already registered, can be expressed in UTF-8. | ||||
2.7.6. Extension Methods | 2.7.6. Extension Methods | |||
Additional authentication method identifiers (extension methods) may | Additional authentication method identifiers (extension methods) may | |||
be defined in the future by later revisions or extensions to this | be defined in the future by later revisions or extensions to this | |||
specification. These method identifiers are registered with the | specification. These method identifiers are registered with the | |||
Internet Assigned Numbers Authority (IANA) and, preferably, published | Internet Assigned Numbers Authority (IANA) and, preferably, published | |||
in an RFC. See Section 6 for further details. | in an RFC. See Section 6 for further details. | |||
Extension methods can be defined for the following reasons: | Extension methods can be defined for the following reasons: | |||
skipping to change at page 22, line 4 | skipping to change at page 22, line 39 | |||
Authentication method implementers are encouraged to provide adequate | Authentication method implementers are encouraged to provide adequate | |||
information, via message header field comments if necessary, to allow | information, via message header field comments if necessary, to allow | |||
an MUA developer to understand or relay ancillary details of | an MUA developer to understand or relay ancillary details of | |||
authentication results. For example, if it might be of interest to | authentication results. For example, if it might be of interest to | |||
relay what data was used to perform an evaluation, such information | relay what data was used to perform an evaluation, such information | |||
could be relayed as a comment in the header field, such as: | could be relayed as a comment in the header field, such as: | |||
Authentication-Results: example.com; | Authentication-Results: example.com; | |||
foo=pass bar.baz=blob (2 of 3 tests OK) | foo=pass bar.baz=blob (2 of 3 tests OK) | |||
Experimental method identifiers MUST only be used within ADMDs that | Experimental method identifiers MUST only be used within ADMDs that | |||
have explicitly consented to use them. These method identifiers and | have explicitly consented to use them. These method identifiers and | |||
the parameters associated with them are not documented in RFCs. | the parameters associated with them are not documented formally. | |||
Therefore, they are subject to change at any time and not suitable | Therefore, they are subject to change at any time and not suitable | |||
for production use. Any MTA, MUA, or downstream filter intended for | for production use. Any MTA, MUA, or downstream filter intended for | |||
production use SHOULD ignore or delete any Authentication-Results | production use SHOULD ignore or delete any Authentication-Results | |||
header field that includes an experimental (unknown) method | header field that includes an experimental (unknown) method | |||
identifier. | identifier. | |||
2.7.7. Extension Result Codes | 2.7.7. Extension Result Codes | |||
Additional result codes (extension results) might be defined in the | Additional result codes (extension results) might be defined in the | |||
future by later revisions or extensions to this specification. | future by later revisions or extensions to this specification. Non- | |||
Result codes MUST be registered with the Internet Assigned Numbers | experimental result codes MUST be registered with the Internet | |||
Authority (IANA) and preferably published in an RFC. See Section 6 | Assigned Numbers Authority (IANA) and preferably published in an RFC. | |||
for further details. | See Section 6 for further details. | |||
Experimental results MUST only be used within ADMDs that have | Experimental results MUST only be used within ADMDs that have | |||
explicitly consented to use them. These results and the parameters | explicitly consented to use them. These results and the parameters | |||
associated with them are not formally documented. Therefore, they | associated with them are not formally documented. Therefore, they | |||
are subject to change at any time and not suitable for production | are subject to change at any time and not suitable for production | |||
use. Any MTA, MUA, or downstream filter intended for production use | use. Any MTA, MUA, or downstream filter intended for production use | |||
SHOULD ignore or delete any Authentication-Results header field that | SHOULD ignore or delete any Authentication-Results header field that | |||
includes an extension result. | includes an extension result. | |||
3. The "iprev" Authentication Method | 3. The "iprev" Authentication Method | |||
skipping to change at page 24, line 14 | skipping to change at page 25, line 5 | |||
Each "method" MUST refer to an authentication method declared in the | Each "method" MUST refer to an authentication method declared in the | |||
IANA registry or an extension method as described in Section 2.7.6, | 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 | 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. | registry or an extension result code as defined in Section 2.7.7. | |||
See Section 6 for further information about the registered methods | See Section 6 for further information about the registered methods | |||
and result codes. | and result codes. | |||
An MTA compliant with this specification adds this header field | An MTA compliant with this specification adds this header field | |||
(after performing one or more message authentication tests) to | (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 | 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 | 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 | indicating all of the results. An MTA MUST NOT add a result to an | |||
existing header field. | existing header field. | |||
An MTA MAY add this header field containing only the authentication | An MTA MAY add this header field containing only the authentication | |||
identifier portion and the "none" token (see Section 2.2) to indicate | identifier portion and the "none" token (see Section 2.2) to indicate | |||
explicitly that no message authentication schemes were applied prior | explicitly that no message authentication schemes were applied prior | |||
to delivery of this message. | to delivery of this message. | |||
skipping to change at page 25, line 23 | skipping to change at page 26, line 19 | |||
this header field unless specifically configured to do so by the user | this header field unless specifically configured to do so by the user | |||
or administrator. That is, this interpretation should not be "on by | or administrator. That is, this interpretation should not be "on by | |||
default". Naturally then, users or administrators ought not activate | default". Naturally then, users or administrators ought not activate | |||
such a feature unless (1) they are certain the header field will be | 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 | 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 | 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 | that appear to originate within the ADMD but are actually added by | |||
foreign MTAs will be removed before delivery. | foreign MTAs will be removed before delivery. | |||
Furthermore, MUAs and downstream filters SHOULD NOT interpret this | Furthermore, MUAs and downstream filters SHOULD NOT interpret this | |||
header field unless the authentication service identifier it bears | header field unless the authentication service identifier of the | |||
appears to be one used within its own ADMD as configured by the user | header field is used within the ADMD as configured by the user or | |||
or administrator. | administrator. | |||
MUAs and downstream filters MUST ignore any result reported using a | MUAs and downstream filters MUST ignore any result reported using a | |||
"result" not specified in the IANA "Result Code" registry or a | "result" not specified in the IANA "Result Code" registry or a | |||
"ptype" not listed in the "Email Authentication Property Types" | "ptype" not listed in the "Email Authentication Property Types" | |||
registry for such values as defined in Section 6. Moreover, such | registry for such values as defined in Section 6. Moreover, such | |||
agents MUST ignore a result indicated for any "method" they do not | agents MUST ignore a result indicated for any "method" they do not | |||
specifically support. | specifically support. The exception to this is experimental methods | |||
as discussed in Section 2.7.6. | ||||
An MUA SHOULD NOT reveal these results to end users, absent careful | An MUA SHOULD NOT reveal these results to end users, absent careful | |||
human factors design considerations and testing, for the presentation | human factors design considerations and testing, for the presentation | |||
of trust-related materials. For example, an attacker could register | of trust-related materials. For example, an attacker could register | |||
examp1e.com (note the digit "1" (one)) and send signed mail to | examp1e.com (note the digit "1" (one)) and send signed mail to | |||
intended victims; a verifier would detect that the signature was | intended victims; a verifier would detect that the signature was | |||
valid and report a "pass" even though it's clear the DNS domain name | valid and report a "pass" even though it's clear the DNS domain name | |||
was intended to mislead. See Section 7.2 for further discussion. | was intended to mislead. See Section 7.2 for further discussion. | |||
As stated in Section 2.1, this header field MUST be treated as though | As stated in Section 2.1, this header field MUST be treated as though | |||
skipping to change at page 26, line 9 | skipping to change at page 27, line 6 | |||
Note that there are a few message handlers that are only capable of | Note that there are a few message handlers that are only capable of | |||
appending new header fields to a message. Strictly speaking, these | appending new header fields to a message. Strictly speaking, these | |||
handlers are not compliant with this specification. They can still | handlers are not compliant with this specification. They can still | |||
add the header field to carry authentication details, but any signal | add the header field to carry authentication details, but any signal | |||
about where in the handling chain the work was done may be lost. | about where in the handling chain the work was done may be lost. | |||
Consumers SHOULD be designed such that this can be tolerated, | Consumers SHOULD be designed such that this can be tolerated, | |||
especially from a producer known to have this limitation. | especially from a producer known to have this limitation. | |||
MUAs SHOULD ignore instances of this header field discovered within | MUAs SHOULD ignore instances of this header field discovered within | |||
message/rfc822 MIME attachments. | message/rfc822 MIME attachments. They are likely to contain the | |||
results of authentication checks done in the past, possibly long ago, | ||||
and have no contemporary value. Due caution to this needs to be | ||||
taken when choosing to consume them. | ||||
Further discussion of these topics can be found in Section 7 below. | Further discussion of these topics can be found in Section 7 below. | |||
4.2. Local Policy Enforcement | 4.2. Local Policy Enforcement | |||
Some sites have a local policy that considers any particular | Some sites have a local policy that considers any particular | |||
authentication policy's non-recoverable failure results (typically | authentication policy's non-recoverable failure results (typically | |||
"fail" or similar) as justification for rejecting the message. In | "fail" or similar) as justification for rejecting the message. In | |||
such cases, the border MTA SHOULD issue an SMTP rejection response to | such cases, the border MTA SHOULD issue an SMTP rejection response to | |||
the message, rather than adding this header field and allowing the | the message, rather than adding this header field and allowing the | |||
skipping to change at page 26, line 35 | skipping to change at page 27, line 35 | |||
The same MAY also be done for local policy decisions overriding the | The same MAY also be done for local policy decisions overriding the | |||
results of the authentication methods (e.g., the "policy" result | results of the authentication methods (e.g., the "policy" result | |||
codes described in Section 2.7). | codes described in Section 2.7). | |||
Such rejections at the SMTP protocol level are not possible if local | Such rejections at the SMTP protocol level are not possible if local | |||
policy is enforced at the MUA and not the MTA. | policy is enforced at the MUA and not the MTA. | |||
5. Removing Existing Header Fields | 5. Removing Existing Header Fields | |||
For security reasons, any MTA conforming to this specification MUST | To mitigate the impact of forged header fields, any MTA conforming to | |||
delete any discovered instance of this header field that claims, by | this specification MUST delete any discovered instance of this header | |||
virtue of its authentication service identifier, to have been added | field that claims, by virtue of its authentication service | |||
within its trust boundary but that did not come directly from another | identifier, to have been added within its trust boundary but that did | |||
trusted MTA. For example, an MTA for example.com receiving a message | not come directly from another trusted MTA. For example, an MTA for | |||
MUST delete or otherwise obscure any instance of this header field | example.com receiving a message MUST delete or otherwise obscure any | |||
bearing an authentication service identifier indicating that the | instance of this header field bearing an authentication service | |||
header field was added within example.com prior to adding its own | identifier indicating that the header field was added within | |||
header fields. This could mean each MTA will have to be equipped | example.com prior to adding its own header fields. This could mean | |||
with a list of internal MTAs known to be compliant (and hence | each internal MTA will need to be configured with a list of other | |||
trustworthy). | known, trusted MTAs that are thus expected to be using that same | |||
identifier. | ||||
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 | For simplicity and maximum security, a border MTA could remove all | |||
instances of this header field on mail crossing into its trust | instances of this header field on mail crossing into its trust | |||
boundary. However, this may conflict with the desire to access | boundary. However, this may conflict with the desire to access | |||
authentication results performed by trusted external service | authentication results performed by trusted external service | |||
providers. It may also invalidate signed messages whose signatures | providers. It may also invalidate signed messages whose signatures | |||
cover external instances of this header field. A more robust border | cover external instances of this header field. A more robust border | |||
MTA could allow a specific list of authenticating MTAs whose | MTA could allow a specific list of authenticating MTAs whose | |||
information is to be admitted, removing the header field originating | information is to be admitted, removing the header field originating | |||
from all others. | from all others. | |||
skipping to change at page 27, line 32 | skipping to change at page 28, line 36 | |||
could invalidate one or more signatures on the message if they | could invalidate one or more signatures on the message if they | |||
covered the header field to be removed. This behavior can be | covered the header field to be removed. This behavior can be | |||
desirable since there's little value in validating the signature on a | desirable since there's little value in validating the signature on a | |||
message with forged header fields. However, signing agents MAY | message with forged header fields. However, signing agents MAY | |||
therefore elect to omit these header fields from signing to avoid | therefore elect to omit these header fields from signing to avoid | |||
this situation. | this situation. | |||
An MTA SHOULD remove any instance of this header field bearing a | An MTA SHOULD remove any instance of this header field bearing a | |||
version (express or implied) that it does not support. However, an | version (express or implied) that it does not support. However, an | |||
MTA MUST remove such a header field if the [SMTP] connection relaying | MTA MUST remove such a header field if the [SMTP] connection relaying | |||
the message is not from a trusted internal MTA. This means the MTA | the message is not from a trusted internal MTA. (As discussed above, | |||
needs to be able to understand versions of this header field at least | this too can result in invalidation of signatures.) This means the | |||
as late as the ones understood by the MUAs or other consumers within | MTA needs to be able to understand versions of this header field at | |||
its ADMD. | least as late as the ones understood by the MUAs or other consumers | |||
within its ADMD. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
IANA has registered the defined header field and created tables as | IANA has registered the defined header field and created registries | |||
described below. These registry actions were originally defined by | as described below. These registry actions were originally defined | |||
[RFC5451] and updated by [RFC6577] and [RFC7001]. The created | by [RFC5451] and updated by [RFC6577] and [RFC7001]. The created | |||
registries are being further updated here to increase their | registries were further updated in [RFC7601] to make them more | |||
completeness. | complete. | |||
Each registry has two related sections below. The first describes | ||||
the registry and its update procedures, which are unchanged from | ||||
[RFC7601]. The second enumerates changes to entries that are | ||||
relevant to this document. | ||||
6.1. The Authentication-Results Header Field | 6.1. The Authentication-Results Header Field | |||
[RFC5451] added the Authentication-Results header field to the IANA | The Authentication-Results header field was added to the IANA | |||
"Permanent Message Header Field Names" registry, per the procedure | "Permanent Message Header Field Names" registry, per the procedure | |||
found in [IANA-HEADERS]. That entry has been updated to reference | found in [IANA-HEADERS]. That entry will be updated to reference | |||
this document. The following is the registration template: | this document. The following is the registration template: | |||
Header field name: Authentication-Results | Header field name: Authentication-Results | |||
Applicable protocol: mail ([MAIL]) | Applicable protocol: mail ([MAIL]) | |||
Status: Standard | Status: Standard | |||
Author/Change controller: IETF | Author/Change controller: IETF | |||
Specification document(s): RFC 7601 | Specification document(s): [this document] | |||
Related information: none | Related information: none | |||
6.2. "Email Authentication Methods" Registry Description | 6.2. "Email Authentication Methods" Registry Description | |||
Names of message authentication methods supported by this | Names of message authentication methods supported by this | |||
specification have been registered with IANA, with the exception of | specification have been registered with IANA, with the exception of | |||
experimental names as described in Section 2.7.6. Along with each | experimental names as described in Section 2.7.6. Along with each | |||
method is recorded the properties that accompany the method's result. | method is recorded the properties that accompany the method's result. | |||
The "Email Authentication Parameters" group, and within it the "Email | The "Email Authentication Parameters" group, and within it the "Email | |||
Authentication Methods" registry, were created by [RFC5451] for this | Authentication Methods" registry, were created by [RFC5451] for this | |||
purpose. [RFC6577] added a "status" field for each entry. [RFC7001] | purpose. [RFC6577] added a "status" field for each entry. [RFC7001] | |||
amended the rules governing that registry and also added a "version" | amended the rules governing that registry and also added a "version" | |||
field to the registry. | field to the registry. | |||
The reference for that registry has been updated to reference this | The reference for that registry will be updated to reference this | |||
document. | document. | |||
New entries are assigned only for values that have received Expert | New entries are assigned only for values that have received Expert | |||
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be | Review, per [IANA-CONSIDERATIONS]. The designated expert shall be | |||
appointed by the IESG. The designated expert has discretion to | appointed by the IESG. The designated expert has discretion to | |||
request that a publication be referenced if a clear, concise | request that a publication be referenced if a clear, concise | |||
definition of the authentication method cannot be provided such that | definition of the authentication method cannot be provided such that | |||
interoperability is assured. Registrations should otherwise be | interoperability is assured. Registrations should otherwise be | |||
permitted. The designated expert can also handle requests to mark | permitted. The designated expert can also handle requests to mark | |||
any current registration as "deprecated". | any current registration as "deprecated". | |||
skipping to change at page 29, line 26 | skipping to change at page 30, line 36 | |||
The "Definition" field will typically refer to a permanent document, | The "Definition" field will typically refer to a permanent document, | |||
or at least some descriptive text, where additional information about | or at least some descriptive text, where additional information about | |||
the entry being added can be found. This might in turn reference the | the entry being added can be found. This might in turn reference the | |||
document where the method is defined so that all of the semantics | document where the method is defined so that all of the semantics | |||
around creating or interpreting an Authentication-Results header | around creating or interpreting an Authentication-Results header | |||
field using this method, ptype, and property can be understood. | field using this method, ptype, and property can be understood. | |||
6.3. "Email Authentication Methods" Registry Update | 6.3. "Email Authentication Methods" Registry Update | |||
The following changes have been made to this registry per this | The following entries in this registry are to be updated to replace | |||
document: | [RFC7601] with this document: | |||
1. The "Defined" field has been renamed "Definition", to be | +------------+--------+----------------------------------+ | |||
consistent with the other registries in this group. | | 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 | | ||||
+------------+--------+----------------------------------+ | ||||
2. The entry for the "dkim" method, "header" ptype, and "b" property | In addition, two new entries are added to this registry, as follows: | |||
now reference [RFC6008] as the defining document, and the | ||||
reference has be removed from the description. | ||||
3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf" | 6.3.1. 'header.a' for DKIM | |||
method entries have had their "Definition" fields changed to | ||||
refer to this document, as this document contains a complete | ||||
description of the registry and these corresponding values. | ||||
4. All "smime" entries have had their "Definition" fields changed to | Method: dkim | |||
[SMIME-REG]. | ||||
5. The "value" field of the "smime" entry using property "smime- | Definition: [this document] | |||
part" has been changed to read: "The MIME body part reference | ||||
that contains the S/MIME signature. See Section 3.2.1 of RFC | ||||
7281 for full syntax." | ||||
6. The single entry for the "auth" method was intended to reflect | ||||
the identity indicated by the "AUTH" parameter to the SMTP "MAIL | ||||
FROM" command verb. However, there is also an "AUTH" command | ||||
verb. To clarify this ambiguity, the entry for the "auth" method | ||||
has had its "property" field changed to "mailfrom", and its | ||||
"Definition" field changed to this document. | ||||
7. The following entry has been added: | ptype: header | |||
Method: auth | property: a | |||
Definition: this document (RFC 7601) | Description: value of signature "a" tag | |||
ptype: smtp | Status: active | |||
property: auth | Version: 1 | |||
Value: identity confirmed by the AUTH command | 6.3.2. 'header.s' for DKIM | |||
Status: active | Method: dkim | |||
Version: 1 | Definition: [this document] | |||
8. The values of the "domainkeys" entries for ptype "header" have | ptype: header | |||
been updated as follows: | ||||
from: contents of the [MAIL] From: header field, after removing | property: s | |||
comments, and removing the local-part and following "@" if not | ||||
authenticated | ||||
sender: contents of the [MAIL] Sender: header field, after | Description: value of signature "s" tag | |||
removing comments, and removing the local-part and following | ||||
"@" if not authenticated | ||||
9. For all entries for "dkim-adsp" and "domainkeys", their Status | Status: active | |||
values have been changed to "deprecated", reflecting the fact | ||||
that the corresponding specifications now have Historic status. | ||||
Their "Definition" fields have also been modified to include a | ||||
reference to this document. | ||||
6.4. "Email Authentication Property Types" Registry | Version: 1 | |||
6.4. "Email Authentication Property Types" Registry Description | ||||
[RFC7410] created the "Email Authentication Property Types" registry. | [RFC7410] created the "Email Authentication Property Types" registry. | |||
Entries in this registry are subject to the Expert Review rules as | Entries in this registry are subject to the Expert Review rules as | |||
described in [IANA-CONSIDERATIONS]. Each entry in the registry | described in [IANA-CONSIDERATIONS]. Each entry in the registry | |||
requires the following values: | requires the following values: | |||
ptype: The name of the ptype being registered, which must fit within | ptype: The name of the ptype being registered, which must fit within | |||
the ABNF described in Section 2.2. | the ABNF described in Section 2.2. | |||
skipping to change at page 31, line 21 | skipping to change at page 32, line 45 | |||
"ptype" is meant to cover. | "ptype" is meant to cover. | |||
For new entries, the Designated Expert needs to assure that the | For new entries, the Designated Expert needs to assure that the | |||
description provided for the new entry adequately describes the | description provided for the new entry adequately describes the | |||
intended use. An example would be helpful to include in the entry's | intended use. An example would be helpful to include in the entry's | |||
defining document, if any, although entries in the "Email | defining document, if any, although entries in the "Email | |||
Authentication Methods" registry or the "Email Authentication Result | Authentication Methods" registry or the "Email Authentication Result | |||
Names" registry might also serve as examples of intended use. | Names" registry might also serve as examples of intended use. | |||
As this is a complete restatement of the definition and rules for | As this is a complete restatement of the definition and rules for | |||
this registry, IANA has updated this registry to show Section 2.3 of | this registry, IANA will update this registry to show Section 2.3 of | |||
this document as the current definitions for the "body", "header", | this document as the current definitions for the "body", "header", | |||
"policy", and "smtp" entries of that registry. References to | "policy", and "smtp" entries of that registry. References to other | |||
[RFC7001] and [RFC7410] have been removed. | documents will be removed. | |||
6.5. "Email Authentication Result Names" Description | 6.5. "Email Authentication Property Types" Registry Update | |||
All current entries in this registry are to be updated to replace | ||||
[RFC7601] with this document. | ||||
6.6. "Email Authentication Result Names" Registry Description | ||||
Names of message authentication result codes supported by this | Names of message authentication result codes supported by this | |||
specification must be registered with IANA, with the exception of | specification must be registered with IANA, with the exception of | |||
experimental codes as described in Section 2.7.7. A registry was | experimental codes as described in Section 2.7.7. | |||
created by [RFC5451] for this purpose. [RFC6577] added the "status" | ||||
column and [RFC7001] updated the rules governing that registry. | ||||
New entries are assigned only for values that have received Expert | New entries are assigned only for values that have received Expert | |||
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be | Review, per [IANA-CONSIDERATIONS]. The designated expert shall be | |||
appointed by the IESG. The designated expert has discretion to | appointed by the IESG. The designated expert has discretion to | |||
request that a publication be referenced if a clear, concise | request that a publication be referenced if a clear, concise | |||
definition of the authentication result cannot be provided such that | definition of the authentication result cannot be provided such that | |||
interoperability is assured. Registrations should otherwise be | interoperability is assured. Registrations should otherwise be | |||
permitted. The designated expert can also handle requests to mark | permitted. The designated expert can also handle requests to mark | |||
any current registration as "deprecated". | any current registration as "deprecated". | |||
skipping to change at page 32, line 14 | skipping to change at page 33, line 44 | |||
Specification: either free form text explaining the meaning of this | Specification: either free form text explaining the meaning of this | |||
method-code combination, or a reference to such a definition. | method-code combination, or a reference to such a definition. | |||
Status: the status of this entry, which is either: | Status: the status of this entry, which is either: | |||
active: The entry is in current use. | active: The entry is in current use. | |||
deprecated: The entry is no longer in current use. | deprecated: The entry is no longer in current use. | |||
6.6. "Email Authentication Result Names" Update | 6.7. "Email Authentication Result Names" Registry Update | |||
This document includes a complete description of the registry, | ||||
obsoleting [RFC7001]. Accordingly, the following changes have been | ||||
made to this registry per this document: | ||||
o The "Defined" field has been removed. | ||||
o The "Meaning" field has been renamed "Specification", as described | ||||
above. | ||||
o The "Auth Method" field now appears before the "Code" field. | ||||
o For easier searching, the table has been arranged such that it is | ||||
sorted first by Auth Method, then by Code within each Auth Method | ||||
grouping. | ||||
o All entries for the "dkim", "domainkeys", "spf", "sender-id", | ||||
"auth", and "iprev" methods have had their "Specification" fields | ||||
replaced as follows: | ||||
dkim: Section 2.7.1 of this document (RFC 7601) | ||||
domainkeys: Section 2.7.1 of this document (RFC 7601) | ||||
spf: for "hardfail", Section 2.4.2 of [RFC5451]; for all others, | ||||
Section 2.7.2 of this document (RFC 7601) | ||||
sender-id: for "hardfail", Section 2.4.2 of [RFC5451]; for all | ||||
others, Section 2.7.2 of this document (RFC 7601) | ||||
auth: Section 2.7.4 of this document (RFC 7601) | The following entries in this registry are to be updated to reflect | |||
new Specifications as follows: | ||||
iprev: Section 2.7.3 of this document (RFC 7601) | o All "auth" method result codes ("fail", "none", "pass", | |||
"permerror", "temperror") are now specified in Section 2.7.4 of | ||||
this document. | ||||
o All entries for "dkim-adsp" that were missing an explicit | o All "dkim" method result names ("fail", "neutral", "none", "pass", | |||
reference to a defining document now reference [ADSP] in their | "permerror", "policy", "temperror") are now specified in | |||
"Specification" fields. | Section 2.7.1 of this document. | |||
o All entries for "dmarc" have had their "Specification" fields | o All "iprev" method result names ("fail", "pass", "permerror", | |||
changed to reference Section 11.2 of [DMARC]. | "temperror") are now specified in Section 2.7.3 of this document. | |||
o All entries for "dkim-adsp" and "domainkeys" have had their Status | o The "sender-id" and "spf" method result names "fail", "neutral", | |||
values changed to "deprecated", reflecting the fact that the | "none", "pass", "permerror", "policy", "softfail", and "temperror" | |||
corresponding specifications now have Historic status. Their | are now specified in Section 2.7.2 of this document. The | |||
"Specification" fields have also been modified to include a | registrations for result name "hardfail" are not updated. | |||
reference to this document. | ||||
6.7. SMTP Enhanced Status Codes | 6.8. SMTP Enhanced Status Codes | |||
The entry for X.7.25 in the "Enumerated Status Codes" sub-registry of | The entry for X.7.25 in the "Enumerated Status Codes" sub-registry of | |||
the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes | the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes | |||
Registry" has been updated to refer to this document instead of | Registry" is to be updated to refer only to Section 3.3 of [AUTH-ESC] | |||
[RFC7001]. | as that is where that registration was done. | |||
7. Security Considerations | 7. Security Considerations | |||
The following security considerations apply when adding or processing | The following security considerations apply when adding or processing | |||
the Authentication-Results header field: | the Authentication-Results header field: | |||
7.1. Forged Header Fields | 7.1. Forged Header Fields | |||
An MUA or filter that accesses a mailbox whose messages are handled | An MTA not applying the filtering discussed in Section 5 exposes MUAs | |||
by a non-conformant MTA, and understands Authentication-Results | to false conclusions based on forged header fields. A malicious user | |||
header fields, could potentially make false conclusions based on | or agent could forge a header field using the DNS domain of a | |||
forged header fields. A malicious user or agent could forge a header | receiving ADMD as the authserv-id token in the value of the header | |||
field using the DNS domain of a receiving ADMD as the authserv-id | field and, with the rest of the value, claim that the message was | |||
token in the value of the header field and, with the rest of the | properly authenticated. The non-conformant MTA would fail to strip | |||
value, claim that the message was properly authenticated. The non- | the forged header field, and the MUA could inappropriately trust it. | |||
conformant MTA would fail to strip the forged header field, and the | ||||
MUA could inappropriately trust it. | ||||
For this reason, it is best not to have processing of the | For this reason, it is best not to have processing of the | |||
Authentication-Results header field enabled by default; instead, it | Authentication-Results header field enabled by default; instead, it | |||
should be ignored, at least for the purposes of enacting filtering | should be ignored, at least for the purposes of enacting filtering | |||
decisions, unless specifically enabled by the user or administrator | decisions, unless specifically enabled by the user or administrator | |||
after verifying that the border MTA is compliant. It is acceptable | after verifying that the border MTA is compliant. It is acceptable | |||
to have an MUA aware of this specification but have an explicit list | to have an MUA aware of this specification but have an explicit list | |||
of hostnames whose Authentication-Results header fields are | of hostnames whose Authentication-Results header fields are | |||
trustworthy; however, this list should initially be empty. | trustworthy; however, this list should initially be empty. | |||
skipping to change at page 36, line 32 | skipping to change at page 37, line 32 | |||
If an attack becomes known against an authentication method, clearly | If an attack becomes known against an authentication method, clearly | |||
then the agent verifying that method can be fooled into thinking an | then the agent verifying that method can be fooled into thinking an | |||
inauthentic message is authentic, and thus the value of this header | inauthentic message is authentic, and thus the value of this header | |||
field can be misleading. It follows that any attack against the | field can be misleading. It follows that any attack against the | |||
authentication methods supported by this document is also a security | authentication methods supported by this document is also a security | |||
consideration here. | consideration here. | |||
7.8. Intentionally Malformed Header Fields | 7.8. Intentionally Malformed Header Fields | |||
It is possible for an attacker to add an Authentication-Results | As with any other header field found in the message, it is possible | |||
header field that is extraordinarily large or otherwise malformed in | for an attacker to add an Authentication-Results header field that is | |||
an attempt to discover or exploit weaknesses in header field parsing | extraordinarily large or otherwise malformed in an attempt to | |||
code. Implementers must thoroughly verify all such header fields | discover or exploit weaknesses in header field parsing code. | |||
received from MTAs and be robust against intentionally as well as | Implementers must thoroughly verify all such header fields received | |||
from MTAs and be robust against intentionally as well as | ||||
unintentionally malformed header fields. | unintentionally malformed header fields. | |||
7.9. Compromised Internal Hosts | 7.9. Compromised Internal Hosts | |||
An internal MUA or MTA that has been compromised could generate mail | An internal MUA or MTA that has been compromised could generate mail | |||
with a forged From header field and a forged Authentication-Results | with a forged From header field and a forged Authentication-Results | |||
header field that endorses it. Although it is clearly a larger | header field that endorses it. Although it is clearly a larger | |||
concern to have compromised internal machines than it is to prove the | concern to have compromised internal machines than it is to prove the | |||
value of this header field, this risk can be mitigated by arranging | value of this header field, this risk can be mitigated by arranging | |||
that internal MTAs will remove this header field if it claims to have | that internal MTAs will remove this header field if it claims to have | |||
skipping to change at page 37, line 15 | skipping to change at page 38, line 16 | |||
7.10. Encapsulated Instances | 7.10. Encapsulated Instances | |||
MIME messages can contain attachments of type "message/rfc822", which | MIME messages can contain attachments of type "message/rfc822", which | |||
contain other messages. Such an encapsulated message can also | contain other messages. Such an encapsulated message can also | |||
contain an Authentication-Results header field. Although the | contain an Authentication-Results header field. Although the | |||
processing of these is outside of the intended scope of this document | processing of these is outside of the intended scope of this document | |||
(see Section 1.3), some early guidance to MUA developers is | (see Section 1.3), some early guidance to MUA developers is | |||
appropriate here. | appropriate here. | |||
Since MTAs are unlikely to strip Authentication-Results header fields | Since MTAs are unlikely to strip Authentication-Results header fields | |||
after mailbox delivery, MUAs are advised in Section 4.1 to ignore | after mailbox delivery, MUAs are warned in Section 4.1 to ignore such | |||
such instances within MIME attachments. Moreover, when extracting a | instances within MIME attachments. Moreover, when extracting a | |||
message digest to separate mail store messages or other media, such | message digest to separate mail store messages or other media, such | |||
header fields should be removed so that they will never be | header fields should be removed so that they will never be | |||
interpreted improperly by MUAs that might later consume them. | interpreted improperly by MUAs that might later consume them. | |||
7.11. Reverse Mapping | 7.11. Reverse Mapping | |||
Although Section 3 of this memo includes explicit support for the | Although Section 3 of this memo includes explicit support for the | |||
"iprev" method, its value as an authentication mechanism is limited. | "iprev" method, its value as an authentication mechanism is limited. | |||
Implementers of both this proposal and agents that use the data it | Implementers of both this specification and agents that use the data | |||
relays are encouraged to become familiar with the issues raised by | it relays are encouraged to become familiar with the issues raised by | |||
[DNSOP-REVERSE] when deciding whether or not to include support for | [DNSOP-REVERSE] when deciding whether or not to include support for | |||
"iprev". | "iprev". | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, | Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ | |||
DOI 10.17487/RFC5234, January 2008, | RFC5234, January 2008, | |||
<http://www.rfc-editor.org/info/rfc5234>. | <http://www.rfc-editor.org/info/rfc5234>. | |||
[IANA-HEADERS] | [IANA-HEADERS] | |||
Klyne, G., Nottingham, M., and J. Mogul, "Registration | Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
Procedures for Message Header Fields", BCP 90, RFC 3864, | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
DOI 10.17487/RFC3864, September 2004, | DOI 10.17487/RFC3864, September 2004, | |||
<http://www.rfc-editor.org/info/rfc3864>. | <http://www.rfc-editor.org/info/rfc3864>. | |||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, | ||||
DOI 10.17487/RFC2119, March 1997, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, | [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, | |||
DOI 10.17487/RFC5322, October 2008, | DOI 10.17487/RFC5322, October 2008, | |||
<http://www.rfc-editor.org/info/rfc5322>. | <http://www.rfc-editor.org/info/rfc5322>. | |||
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part One: Format of Internet Message | Extensions (MIME) Part One: Format of Internet Message | |||
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | |||
<http://www.rfc-editor.org/info/rfc2045>. | <http://www.rfc-editor.org/info/rfc2045>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | ||||
RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for | ||||
Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, | ||||
February 2012, <https://www.rfc-editor.org/info/rfc6530>. | ||||
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized | ||||
Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, | ||||
<https://www.rfc-editor.org/info/rfc6531>. | ||||
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized | ||||
Email Headers", RFC 6532, DOI 10.17487/RFC6532, | ||||
February 2012, <https://www.rfc-editor.org/info/rfc6532>. | ||||
[RFC7601] Kucherawy, M., "Message Header Field for Indicating | ||||
Message Authentication Status", RFC 7601, DOI 10.17487/ | ||||
RFC7601, August 2015, | ||||
<https://www.rfc-editor.org/info/rfc7601>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | |||
DOI 10.17487/RFC5321, October 2008, | DOI 10.17487/RFC5321, October 2008, | |||
<http://www.rfc-editor.org/info/rfc5321>. | <http://www.rfc-editor.org/info/rfc5321>. | |||
8.2. Informative References | 8.2. Informative References | |||
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, | [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, | |||
"DomainKeys Identified Mail (DKIM) Author Domain Signing | "DomainKeys Identified Mail (DKIM) Author Domain Signing | |||
Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August | Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, | |||
2009, <http://www.rfc-editor.org/info/rfc5617>. | August 2009, <http://www.rfc-editor.org/info/rfc5617>. | |||
[AR-VBR] Kucherawy, M., "Authentication-Results Registration for | [AR-VBR] Kucherawy, M., "Authentication-Results Registration for | |||
Vouch by Reference Results", RFC 6212, | Vouch by Reference Results", RFC 6212, DOI 10.17487/ | |||
DOI 10.17487/RFC6212, April 2011, | RFC6212, April 2011, | |||
<http://www.rfc-editor.org/info/rfc6212>. | <http://www.rfc-editor.org/info/rfc6212>. | |||
[ATPS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) | [ATPS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) | |||
Authorized Third-Party Signatures", RFC 6541, | Authorized Third-Party Signatures", RFC 6541, | |||
DOI 10.17487/RFC6541, February 2012, | DOI 10.17487/RFC6541, February 2012, | |||
<http://www.rfc-editor.org/info/rfc6541>. | <http://www.rfc-editor.org/info/rfc6541>. | |||
[AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service | [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service | |||
Extension for Authentication", RFC 4954, | Extension for Authentication", RFC 4954, DOI 10.17487/ | |||
DOI 10.17487/RFC4954, July 2007, | RFC4954, July 2007, | |||
<http://www.rfc-editor.org/info/rfc4954>. | <http://www.rfc-editor.org/info/rfc4954>. | |||
[AUTH-ESC] | [AUTH-ESC] | |||
Kucherawy, M., "Email Authentication Status Codes", | Kucherawy, M., "Email Authentication Status Codes", | |||
RFC 7372, DOI 10.17487/RFC7372, September 2014, | RFC 7372, DOI 10.17487/RFC7372, September 2014, | |||
<http://www.rfc-editor.org/info/rfc7372>. | <http://www.rfc-editor.org/info/rfc7372>. | |||
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., | [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., | |||
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, | "DomainKeys Identified Mail (DKIM) Signatures", STD 76, | |||
RFC 6376, DOI 10.17487/RFC6376, September 2011, | RFC 6376, DOI 10.17487/RFC6376, September 2011, | |||
skipping to change at page 39, line 36 | skipping to change at page 41, line 11 | |||
for Delivery Status Notifications", RFC 3464, | for Delivery Status Notifications", RFC 3464, | |||
DOI 10.17487/RFC3464, January 2003, | DOI 10.17487/RFC3464, January 2003, | |||
<http://www.rfc-editor.org/info/rfc3464>. | <http://www.rfc-editor.org/info/rfc3464>. | |||
[EMAIL-ARCH] | [EMAIL-ARCH] | |||
Crocker, D., "Internet Mail Architecture", RFC 5598, | Crocker, D., "Internet Mail Architecture", RFC 5598, | |||
DOI 10.17487/RFC5598, July 2009, | DOI 10.17487/RFC5598, July 2009, | |||
<http://www.rfc-editor.org/info/rfc5598>. | <http://www.rfc-editor.org/info/rfc5598>. | |||
[IANA-CONSIDERATIONS] | [IANA-CONSIDERATIONS] | |||
Narten, T. and H. Alvestrand, "Guidelines for Writing an | Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
DOI 10.17487/RFC5226, May 2008, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<http://www.rfc-editor.org/info/rfc5226>. | <http://www.rfc-editor.org/info/rfc8126>. | |||
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | |||
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | |||
<http://www.rfc-editor.org/info/rfc3501>. | <http://www.rfc-editor.org/info/rfc3501>. | |||
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | |||
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | |||
<http://www.rfc-editor.org/info/rfc1939>. | <http://www.rfc-editor.org/info/rfc1939>. | |||
[PRA] Lyon, J., "Purported Responsible Address in E-Mail | [PRA] Lyon, J., "Purported Responsible Address in E-Mail | |||
Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, | Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, | |||
<http://www.rfc-editor.org/info/rfc4407>. | <http://www.rfc-editor.org/info/rfc4407>. | |||
[RFC5451] Kucherawy, M., "Message Header Field for Indicating | [RFC5451] Kucherawy, M., "Message Header Field for Indicating | |||
Message Authentication Status", RFC 5451, | Message Authentication Status", RFC 5451, DOI 10.17487/ | |||
DOI 10.17487/RFC5451, April 2009, | RFC5451, April 2009, | |||
<http://www.rfc-editor.org/info/rfc5451>. | <https://www.rfc-editor.org/info/rfc5451>. | |||
[RFC6008] Kucherawy, M., "Authentication-Results Registration for | [RFC6008] Kucherawy, M., "Authentication-Results Registration for | |||
Differentiating among Cryptographic Results", RFC 6008, | Differentiating among Cryptographic Results", RFC 6008, | |||
DOI 10.17487/RFC6008, September 2010, | DOI 10.17487/RFC6008, September 2010, | |||
<http://www.rfc-editor.org/info/rfc6008>. | <https://www.rfc-editor.org/info/rfc6008>. | |||
[RFC6577] Kucherawy, M., "Authentication-Results Registration Update | [RFC6577] Kucherawy, M., "Authentication-Results Registration Update | |||
for Sender Policy Framework (SPF) Results", RFC 6577, | for Sender Policy Framework (SPF) Results", RFC 6577, | |||
DOI 10.17487/RFC6577, March 2012, | DOI 10.17487/RFC6577, March 2012, | |||
<http://www.rfc-editor.org/info/rfc6577>. | <https://www.rfc-editor.org/info/rfc6577>. | |||
[RFC7001] Kucherawy, M., "Message Header Field for Indicating | [RFC7001] Kucherawy, M., "Message Header Field for Indicating | |||
Message Authentication Status", RFC 7001, | Message Authentication Status", RFC 7001, DOI 10.17487/ | |||
DOI 10.17487/RFC7001, September 2013, | RFC7001, September 2013, | |||
<http://www.rfc-editor.org/info/rfc7001>. | <https://www.rfc-editor.org/info/rfc7001>. | |||
[RFC7410] Kucherawy, M., "A Property Types Registry for the | [RFC7410] Kucherawy, M., "A Property Types Registry for the | |||
Authentication-Results Header Field", RFC 7410, | Authentication-Results Header Field", RFC 7410, | |||
DOI 10.17487/RFC7410, December 2014, | DOI 10.17487/RFC7410, December 2014, | |||
<http://www.rfc-editor.org/info/rfc7410>. | <http://www.rfc-editor.org/info/rfc7410>. | |||
[RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage | ||||
Update to DomainKeys Identified Mail (DKIM)", RFC 8301, | ||||
DOI 10.17487/RFC8301, January 2018, | ||||
<https://www.rfc-editor.org/info/rfc8301>. | ||||
[RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- | [RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- | |||
Since Header Field and SMTP Service Extension", RFC 7293, | Since Header Field and SMTP Service Extension", RFC 7293, | |||
DOI 10.17487/RFC7293, July 2014, | DOI 10.17487/RFC7293, July 2014, | |||
<http://www.rfc-editor.org/info/rfc7293>. | <http://www.rfc-editor.org/info/rfc7293>. | |||
[SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC | [SECURITY] | |||
Rescorla, E. and B. Korver, "Guidelines for Writing RFC | ||||
Text on Security Considerations", BCP 72, RFC 3552, | Text on Security Considerations", BCP 72, RFC 3552, | |||
DOI 10.17487/RFC3552, July 2003, | DOI 10.17487/RFC3552, July 2003, | |||
<http://www.rfc-editor.org/info/rfc3552>. | <http://www.rfc-editor.org/info/rfc3552>. | |||
[SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", | [SENDERID] | |||
Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", | ||||
RFC 4406, DOI 10.17487/RFC4406, April 2006, | RFC 4406, DOI 10.17487/RFC4406, April 2006, | |||
<http://www.rfc-editor.org/info/rfc4406>. | <http://www.rfc-editor.org/info/rfc4406>. | |||
[SMIME-REG] | [SMIME-REG] | |||
Melnikov, A., "Authentication-Results Registration for | Melnikov, A., "Authentication-Results Registration for | |||
S/MIME Signature Verification", RFC 7281, | S/MIME Signature Verification", RFC 7281, DOI 10.17487/ | |||
DOI 10.17487/RFC7281, June 2014, | RFC7281, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7281>. | <http://www.rfc-editor.org/info/rfc7281>. | |||
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for | [SPF] Kitterman, S., "Sender Policy Framework (SPF) for | |||
Authorizing Use of Domains in Email, Version 1", RFC 7208, | Authorizing Use of Domains in Email, Version 1", RFC 7208, | |||
DOI 10.17487/RFC7208, April 2014, | DOI 10.17487/RFC7208, April 2014, | |||
<http://www.rfc-editor.org/info/rfc7208>. | <http://www.rfc-editor.org/info/rfc7208>. | |||
[VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By | [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By | |||
Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, | Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, | |||
<http://www.rfc-editor.org/info/rfc5518>. | <http://www.rfc-editor.org/info/rfc5518>. | |||
skipping to change at page 42, line 22 | skipping to change at page 43, line 10 | |||
field. One suggestion is to include a Priority header field, on | field. One suggestion is to include a Priority header field, on | |||
messages that don't already have such a header field, containing a | messages that don't already have such a header field, containing a | |||
value that reflects the strength of the authentication that was | value that reflects the strength of the authentication that was | |||
accomplished, e.g., "low" for weak or no authentication, "normal" or | accomplished, e.g., "low" for weak or no authentication, "normal" or | |||
"high" for good or strong authentication. | "high" for good or strong authentication. | |||
Some modern MUAs can already filter based on the content of this | Some modern MUAs can already filter based on the content of this | |||
header field. However, there is keen interest in having MUAs make | header field. However, there is keen interest in having MUAs make | |||
some kind of graphical representation of this header field's meaning | some kind of graphical representation of this header field's meaning | |||
to end users. Until this capability is added (i.e., while this | to end users. Until this capability is added (i.e., while this | |||
proposal and its successors are being adopted), other interim means | specification and its successors continue to be adopted), other | |||
of conveying authentication results may be necessary. | interim means of conveying authentication results may be necessary. | |||
Appendix B. Authentication-Results Examples | Appendix B. Authentication-Results Examples | |||
This section presents some examples of the use of this header field | This section presents some examples of the use of this header field | |||
to indicate authentication results. | to indicate authentication results. | |||
B.1. Trivial Case; Header Field Not Present | B.1. Trivial Case; Header Field Not Present | |||
The trivial case: | The trivial case: | |||
skipping to change at page 45, line 43 | skipping to change at page 46, line 43 | |||
receiving DNS domain name is used as the authserv-id. Furthermore, | receiving DNS domain name is used as the authserv-id. Furthermore, | |||
the sender authenticated herself/himself to the MTA via a method | 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 Sender ID checks were done and | |||
passed. The MUA could extract and relay this extra information if | passed. The MUA could extract and relay this extra information if | |||
desired. | desired. | |||
Two Authentication-Results header fields are not required since the | Two Authentication-Results header fields are not required since the | |||
same host did all of the checking. The authenticating agent could | same host did all of the checking. The authenticating agent could | |||
have consolidated all the results into one header field. | have consolidated all the results into one header field. | |||
This example illustrates a scenario in which a remote user on a dial- | This example illustrates a scenario in which a remote user on a | |||
up connection (example.net) sends mail to a border MTA (example.com) | dial-up connection (example.net) sends mail to a border MTA | |||
using SMTP authentication to prove identity. The dial-up provider | (example.com) using SMTP authentication to prove identity. The | |||
has been explicitly authorized to relay mail as example.com, | dial-up provider has been explicitly authorized to relay mail as | |||
producing "pass" results from the SPF and Sender ID checks. | example.net, producing "pass" results from the SPF and Sender ID | |||
checks. | ||||
B.5. Service Provided, Several Authentications Done, Different MTAs | B.5. Service Provided, Several Authentications Done, Different MTAs | |||
A message that was relayed inbound by two different MTAs that conform | A message that was relayed inbound by two different MTAs that conform | |||
to this specification and applied multiple message authentication | to this specification and applied multiple message authentication | |||
checks: | checks: | |||
Authentication-Results: example.com; | Authentication-Results: example.com; | |||
sender-id=fail header.from=example.com; | sender-id=fail header.from=example.com; | |||
dkim=pass (good signature) header.d=example.com | dkim=pass (good signature) header.d=example.com | |||
skipping to change at page 47, line 18 | skipping to change at page 48, line 16 | |||
which the MUA may choose to render. Also noteworthy here is the fact | 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 | that there is a DKIM signature added by example.com that assured the | |||
integrity of the lower Authentication-Results field. | integrity of the lower Authentication-Results field. | |||
Since different hosts did the two sets of authentication checks, the | Since different hosts did the two sets of authentication checks, the | |||
header fields cannot be consolidated in this example. | header fields cannot be consolidated in this example. | |||
This example illustrates more typical transmission of mail into | This example illustrates more typical transmission of mail into | |||
example.com from a user on a dial-up connection example.net. The | 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 | 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 | authentication at the border MTA using SMTP AUTH. The SPF test | |||
ID tests failed since example.com has not granted example.net | 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 | authority to relay mail on its behalf. However, the DKIM test passed | |||
because the sending user had a private key matching one of | 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 | B.6. Service Provided, Multi-tiered Authentication Done | |||
A message that had authentication done at various stages, one of | A message that had authentication done at various stages, one of | |||
which was outside the receiving ADMD: | which was outside the receiving ADMD: | |||
Authentication-Results: example.com; | Authentication-Results: example.com; | |||
dkim=pass reason="good signature" | dkim=pass reason="good signature" | |||
header.i=@mail-router.example.net; | header.i=@mail-router.example.net; | |||
dkim=fail reason="bad signature" | dkim=fail reason="bad signature" | |||
skipping to change at page 48, line 45 | skipping to change at page 49, line 45 | |||
t=1188964191; c=simple/simple; | t=1188964191; c=simple/simple; | |||
h=From:Date:To:Message-Id:Subject; | h=From:Date:To:Message-Id:Subject; | |||
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; | bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; | |||
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= | b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= | |||
From: sender@newyork.example.com | From: sender@newyork.example.com | |||
Date: Fri, Feb 15 2002 16:54:30 -0800 | Date: Fri, Feb 15 2002 16:54:30 -0800 | |||
To: meetings@example.net | To: meetings@example.net | |||
Message-Id: <12345.abc@newyork.example.com> | Message-Id: <12345.abc@newyork.example.com> | |||
Subject: here's a sample | Subject: here's a sample | |||
Example 6: Headers Reporting Results from Multiple MTAs in | Example 6: Headers Reporting Results from Multiple MTAs in Different | |||
Different ADMDs | ADMDs | |||
In this example, we see multi-tiered authentication with an extended | In this example, we see multi-tiered authentication with an extended | |||
trust boundary. | trust boundary. | |||
The message was sent from someone at example.com's New York office | The message was sent from someone at example.com's New York office | |||
(newyork.example.com) to a mailing list managed at an intermediary. | (newyork.example.com) to a mailing list managed at an intermediary. | |||
The message was signed at the origin using DKIM. | The message was signed at the origin using DKIM. | |||
The message was sent to a mailing list service provider called | The message was sent to a mailing list service provider called | |||
example.net, which is used by example.com. There, | example.net, which is used by example.com. There, | |||
meetings@example.net is expanded to a long list of recipients, one of | meetings@example.net is expanded to a long list of recipients, one of | |||
whom is at the Chicago office. In this example, we will assume that | whom is at the Chicago office. In this example, we will assume that | |||
the trust boundary for chicago.example.com includes the mailing list | the trust boundary for chicago.example.com includes the mailing list | |||
server at example.net. | server at example.net. | |||
The mailing list server there first authenticated the message and | The mailing list server there first authenticated the message and | |||
skipping to change at page 50, line 25 | skipping to change at page 51, line 25 | |||
1. Service operators prefer to resolve the handling of problem | 1. Service operators prefer to resolve the handling of problem | |||
messages as close to the border of the ADMD as possible. This | messages as close to the border of the ADMD as possible. This | |||
enables, for example, rejection of messages at the SMTP level | enables, for example, rejection of messages at the SMTP level | |||
rather than generating a DSN internally. Thus, doing any of the | rather than generating a DSN internally. Thus, doing any of the | |||
authentication or reputation work exclusively at the MUA or | authentication or reputation work exclusively at the MUA or | |||
intermediate MTA renders this desire unattainable. | intermediate MTA renders this desire unattainable. | |||
2. Border MTAs are more likely to have direct access to external | 2. Border MTAs are more likely to have direct access to external | |||
sources of authentication or reputation information since modern | sources of authentication or reputation information since modern | |||
MUAs are more likely to be heavily firewalled. Thus, some MUAs | MUAs inside of an ADMD are more likely to be heavily firewalled. | |||
might not even be able to complete the task of performing | Thus, some MUAs might not even be able to complete the task of | |||
authentication or reputation evaluations without complex proxy | performing authentication or reputation evaluations without | |||
configurations or similar burdens. | complex proxy configurations or similar burdens. | |||
3. MUAs rely upon the upstream MTAs within their trust boundaries to | 3. MUAs rely upon the upstream MTAs within their trust boundaries to | |||
make correct (as much as is possible) evaluations about the | make correct (as much as is possible) evaluations about the | |||
message's envelope, header, and content. Thus, MUAs don't need | message's envelope, header, and content. Thus, MUAs don't need | |||
to know how to do the work that upstream MTAs do; they only need | to know how to do the work that upstream MTAs do; they only need | |||
the results of that work. | the results of that work. | |||
4. Evaluations about the quality of a message, from simple token | 4. Evaluations about the quality of a message, from simple token | |||
matching (e.g., a list of preferred DNS domains) to cryptanalysis | matching (e.g., a list of preferred DNS domains) to cryptographic | |||
(e.g., public/private key work), do have a cost and thus need to | verification (e.g., public/private key work), do have a cost and | |||
be minimized. To that end, performing those tests at the border | thus need to be minimized. To that end, performing those tests | |||
MTA is far preferred to doing that work at each MUA that handles | at the border MTA is far preferred to doing that work at each MUA | |||
a message. If an ADMD's environment adheres to common messaging | that handles a message. If an ADMD's environment adheres to | |||
protocols, a reputation query or an authentication check | common messaging protocols, a reputation query or an | |||
performed by a border MTA would return the same result as the | authentication check performed by a border MTA would return the | |||
same query performed by an MUA. By contrast, in an environment | same result as the same query performed by an MUA. By contrast, | |||
where the MUA does the work, a message arriving for multiple | in an environment where the MUA does the work, a message arriving | |||
recipients would thus cause authentication or reputation | for multiple recipients would thus cause authentication or | |||
evaluation to be done more than once for the same message (i.e., | reputation evaluation to be done more than once for the same | |||
at each MUA), causing needless amplification of resource use and | message (i.e., at each MUA), causing needless amplification of | |||
creating a possible denial-of-service attack vector. | resource use and creating a possible denial-of-service attack | |||
vector. | ||||
5. Minimizing change is good. As new authentication and reputation | 5. Minimizing change is good. As new authentication and reputation | |||
methods emerge, the list of methods supported by this header | methods emerge, the list of methods supported by this header | |||
field would presumably be extended. If MUAs simply consume the | field would presumably be extended. If MUAs simply consume the | |||
contents of this header field rather than actually attempt to do | contents of this header field rather than actually attempt to do | |||
authentication and/or reputation work, then MUAs only need to | authentication and/or reputation work, then MUAs only need to | |||
learn to parse this header field once; emergence of new methods | learn to parse this header field once; emergence of new methods | |||
requires only a configuration change at the MUAs and software | requires only a configuration change at the MUAs and software | |||
changes at the MTAs (which are presumably fewer in number). When | changes at the MTAs (which are presumably fewer in number). When | |||
choosing to implement these functions in MTAs vs. MUAs, the | choosing to implement these functions in MTAs vs. MUAs, the | |||
skipping to change at page 51, line 37 | skipping to change at page 52, line 37 | |||
delivery process has completed. This seriously diminishes the | delivery process has completed. This seriously diminishes the | |||
value of this work when done elsewhere than at MTAs. | value of this work when done elsewhere than at MTAs. | |||
Many operational choices are possible within an ADMD, including the | Many operational choices are possible within an ADMD, including the | |||
venue for performing authentication and/or reputation assessment. | venue for performing authentication and/or reputation assessment. | |||
The current specification does not dictate any of those choices. | The current specification does not dictate any of those choices. | |||
Rather, it facilitates those cases in which information produced by | Rather, it facilitates those cases in which information produced by | |||
one stage of analysis needs to be transported with the message to the | one stage of analysis needs to be transported with the message to the | |||
next stage. | next stage. | |||
Appendix D. Changes since RFC 7001 | Appendix D. Changes since RFC7601 | |||
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 Added IANA registration for DKIM "a" and "s" properties. | |||
o Corrected the "smime-part" prose. | o Include EAI guidance. | |||
o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the | o Adjust some ABNF tokes and names for easier inclusion by other | |||
Received fields. | documents. | |||
o Made minor editorial adjustments. | o Made minor editorial adjustments. | |||
Acknowledgments | Appendix E. Acknowledgments | |||
The author wishes to acknowledge the following individuals for their | The author wishes to acknowledge the following individuals for their | |||
review and constructive criticism of this document: Stephane | review and constructive criticism of this document: Seth Blank, Tim | |||
Bortzmeyer, Scott Kitterman, John Levine, Tom Petch, and Pete | Draegen, Scott Kitterman, John Levine, and Alessandro Vesely. | |||
Resnick. | ||||
Author's Address | Author's Address | |||
Murray S. Kucherawy | Murray S. Kucherawy | |||
270 Upland Drive | 270 Upland Drive | |||
San Francisco, CA 94127 | San Francisco, CA 94127 | |||
United States | United States | |||
Email: superuser@gmail.com | Email: superuser@gmail.com | |||
End of changes. 126 change blocks. | ||||
422 lines changed or deleted | 443 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |