rfc5451.txt | draft-kucherawy-rfc5451bis.txt | |||
---|---|---|---|---|
Network Working Group M. Kucherawy | Individual submission M. Kucherawy | |||
Request for Comments: 5451 Sendmail, Inc. | ||||
Obsoletes: 5451, 6577 | ||||
(if approved) | ||||
Intended status: Standards Track | ||||
Expires: September 13, 2013 | ||||
Message Header Field for Indicating Message Authentication Status | Message Header Field for Indicating Message Authentication Status | |||
draft-kucherawy-rfc5451bis-02 | ||||
Abstract | ||||
This document specifies a header field for use with electronic mail | ||||
messages to indicate the results of message authentication efforts. | ||||
Any receiver-side software, such as mail filters or Mail User Agents | ||||
(MUAs), can use this header field to relay that information in a | ||||
convenient and meaningful way to users, or make sorting and filtering | ||||
decisions. | ||||
This document is a candidate for Internet Standard status. [RFC | ||||
Editor: Please delete this notation, as I imagine it will be | ||||
indicated some other way.] | ||||
Status of This Memo | Status of This Memo | |||
This document specifies an Internet standards track protocol for the | This Internet-Draft is submitted in full conformance with the | |||
Internet community, and requests discussion and suggestions for | provisions of BCP 78 and BCP 79. | |||
improvements. Please refer to the current edition of the "Internet | ||||
Official Protocol Standards" (STD 1) for the standardization state | Internet-Drafts are working documents of the Internet Engineering | |||
and status of this protocol. Distribution of this memo is unlimited. | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | ||||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
This Internet-Draft will expire on September 13, 2013. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2013 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 in effect on the date of | Provisions Relating to IETF Documents | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
Abstract | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | ||||
This memo defines a new header field for use with electronic mail | described in the Simplified BSD License. | |||
messages to indicate the results of message authentication efforts. | ||||
Any receiver-side software, such as mail filters or Mail User Agents | ||||
(MUAs), may use this message header field to relay that information | ||||
in a convenient way to users or to make sorting and filtering | ||||
decisions. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 5 | 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 6 | 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 7 | |||
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 7 | 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 8 | |||
2. Definition and Format of the Header Field . . . . . . . . . . 8 | 2. Definition and Format of the Header Field . . . . . . . . . . 8 | |||
2.1. General Description . . . . . . . . . . . . . . . . . . . 8 | 2.1. General Description . . . . . . . . . . . . . . . . . . . 8 | |||
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 8 | 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 | |||
2.3. Authentication Identifier Field . . . . . . . . . . . . . 10 | 2.3. Authentication Identifier Field . . . . . . . . . . . . . 11 | |||
2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 12 | 2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 12 | |||
2.4.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 12 | 2.4.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 12 | |||
2.4.2. SPF and Sender-ID Results . . . . . . . . . . . . . . 13 | 2.4.2. SPF and Sender-ID Results . . . . . . . . . . . . . . 13 | |||
2.4.3. "iprev" Results . . . . . . . . . . . . . . . . . . . 14 | 2.4.3. "iprev" Results . . . . . . . . . . . . . . . . . . . 14 | |||
2.4.4. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 14 | 2.4.4. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 15 | |||
2.4.5. Extension Result Codes . . . . . . . . . . . . . . . . 15 | 2.4.5. Extension Result Codes . . . . . . . . . . . . . . . . 16 | |||
2.5. Authentication Methods . . . . . . . . . . . . . . . . . . 15 | 2.5. Authentication Methods . . . . . . . . . . . . . . . . . . 16 | |||
2.5.1. Definition of Initial Methods . . . . . . . . . . . . 16 | 2.5.1. Definition of Initial Methods . . . . . . . . . . . . 16 | |||
2.5.2. Extension Methods . . . . . . . . . . . . . . . . . . 16 | 2.5.2. Extension Methods . . . . . . . . . . . . . . . . . . 17 | |||
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 17 | 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 17 | |||
4. Adding the Header Field to A Message . . . . . . . . . . . . . 18 | 4. Adding the Header Field to A Message . . . . . . . . . . . . . 19 | |||
4.1. Header Field Position and Interpretation . . . . . . . . . 19 | 4.1. Header Field Position and Interpretation . . . . . . . . . 20 | |||
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 20 | 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 21 | |||
5. Removing the Header Field . . . . . . . . . . . . . . . . . . 20 | 5. Removing the Header Field . . . . . . . . . . . . . . . . . . 21 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | |||
6.1. The Authentication-Results Header Field . . . . . . . . . 22 | 6.1. The Authentication-Results Header Field . . . . . . . . . 22 | |||
6.2. Email Authentication Method Name Registry . . . . . . . . 22 | 6.2. Email Authentication Method Name Registry . . . . . . . . 23 | |||
6.3. Email Authentication Result Name Registry . . . . . . . . 24 | 6.3. Email Authentication Result Name Registry . . . . . . . . 23 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 26 | 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 24 | |||
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 27 | 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 25 | |||
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 28 | 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 26 | |||
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 28 | 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 26 | |||
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 28 | 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 26 | |||
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 28 | 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 26 | |||
7.7. Attacks against Authentication Methods . . . . . . . . . . 28 | 7.7. Attacks against Authentication Methods . . . . . . . . . . 26 | |||
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 29 | 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 27 | |||
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 29 | 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 27 | |||
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 29 | 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 27 | |||
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 29 | 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 27 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 30 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 | |||
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 32 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30 | |||
Appendix B. Authentication-Results Examples . . . . . . . . . . . 33 | Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 30 | |||
B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 33 | Appendix C. Authentication-Results Examples . . . . . . . . . . . 30 | |||
B.2. Nearly Trivial Case; Service Provided, But No | C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 31 | |||
Authentication Done . . . . . . . . . . . . . . . . . . . 34 | C.2. Nearly Trivial Case; Service Provided, But No | |||
B.3. Service Provided, Authentication Done . . . . . . . . . . 35 | Authentication Done . . . . . . . . . . . . . . . . . . . 31 | |||
B.4. Service Provided, Several Authentications Done, Single | C.3. Service Provided, Authentication Done . . . . . . . . . . 32 | |||
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | C.4. Service Provided, Several Authentications Done, Single | |||
B.5. Service Provided, Several Authentications Done, | MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 37 | C.5. Service Provided, Several Authentications Done, | |||
B.6. Service Provided, Multi-Tiered Authentication Done . . . . 39 | Different MTAs . . . . . . . . . . . . . . . . . . . . . . 34 | |||
Appendix C. Operational Considerations about Message | C.6. Service Provided, Multi-Tiered Authentication Done . . . . 36 | |||
Authentication . . . . . . . . . . . . . . . . . . . 41 | Appendix D. Operational Considerations about Message | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 43 | Authentication . . . . . . . . . . . . . . . . . . . 37 | |||
Appendix E. Changes since RFC5451 . . . . . . . . . . . . . . . . 39 | ||||
1. Introduction | 1. Introduction | |||
This memo defines a new header field for electronic mail messages | [AR-ORIG] defined a new header field for electronic mail messages | |||
that presents the results of a message authentication effort in a | that presents the results of a message authentication effort in a | |||
machine-readable format. The intent is to create a place to collect | machine-readable format. This document revises that definition based | |||
such data when message authentication mechanisms are in use so that a | on current use of various authentication protocols in use today and | |||
Mail User Agent (MUA) and downstream filters can make filtering | incorporates errate logged since the publication of the original | |||
decisions and/or provide a recommendation to the user as to the | specification. | |||
validity of the message's origin and possibly the integrity of its | ||||
The intent of the header field is to create a place to collect such | ||||
data when message authentication mechanisms are in use so that a Mail | ||||
User Agent (MUA) and downstream filters can make filtering decisions | ||||
and/or provide a recommendation to the user as to the validity of the | ||||
message's origin and possibly the safety and integrity of its | ||||
content. | content. | |||
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 or render such data in a human-usable form. | that will then use or render such data in a human-usable form. | |||
This memo defines both the format of this new header field and | This document specifies both the format of this header field and | |||
discusses the implications of its presence or absence. However, it | discusses the implications of its presence or absence. However, it | |||
does not discuss how the data contained in the header field should be | does not discuss how the data contained in the header field ought to | |||
used (i.e. what filtering decisions are appropriate, or how an MUA | be used (i.e. what filtering decisions are appropriate, or how an MUA | |||
might render these results) as these are local policy and/or user | might render those results) as these are local policy and/or user | |||
interface design questions that are not appropriate for this memo. | interface design questions that are not appropriate for this | |||
document. | ||||
At the time of publication of this memo, [AUTH], [DKIM], | At the time of publication of this document, [ADSP], [AUTH], [DKIM], | |||
[DOMAINKEYS], [SENDERID], and [SPF] are published DNS domain-level | [SPF], and [VBR] are published DNS domain-level email authentication | |||
email authentication methods in common use. This proposal is not | methods in common use. [DOMAINKEYS] is also referenced here, though | |||
intended to be restricted to domain-based authentication, but this | it has "Historic" status as it is no longer common. This proposal is | |||
has proven to be a good starting point for implementations. As | not intended to be restricted to domain-based authentication, but | |||
this has proven to be a good starting point for implementations. As | ||||
various methods emerge, it is necessary to prepare for their | various methods emerge, it is necessary to prepare for their | |||
appearance and encourage convergence in the area of interfacing | appearance and encourage convergence in the area of interfacing | |||
verifiers to filters and MUAs. | verifiers to filters and MUAs. | |||
Although [SPF] defined a header field called Received-SPF and | Although [SPF] defined a header field called Received-SPF and | |||
[DOMAINKEYS] defined one called DomainKey-Status for this purpose, | [DOMAINKEYS] defined one called DomainKey-Status for this purpose, | |||
those header fields are specific to the conveyance of their | 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. | requirements enumerated below. In addition, many SPF implementations | |||
have adopted the header field specified below, and DomainKeys has | ||||
been obsoleted by DKIM. | ||||
1.1. Purpose | 1.1. Purpose | |||
The header field defined in this memo is expected to serve several | The header field defined in this document is expected to serve | |||
purposes: | several purposes: | |||
1. Convey the results of various message authentication checks being | 1. Convey the results of various message authentication checks being | |||
applied by upstream filters and Mail Transfer Agents (MTAs) to | applied by upstream filters and Mail Transfer Agents (MTAs) to | |||
MUAs and downstream filters within the same "trust domain", as | MUAs and downstream filters within the same "trust domain", as | |||
such agents may wish to render those results to end users or use | such agents may wish to render those results to end users or use | |||
that data to apply more or less stringent content checks based on | that data to apply more or less stringent content checks based on | |||
authentication results; | 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 should not be | In particular, the mere presence of this header field should not be | |||
construed as meaning that its data is valid, but rather that it is | construed as meaning that its data is valid, but rather that it is | |||
asserting validity based on one or more authentication schemes | asserting some kind of validity based on one or more authentication | |||
somewhere upstream. For an MUA or downstream filter to treat the | schemes applied somewhere upstream. For an MUA or downstream filter | |||
assertions as actually valid, there must be an assessment of the | to treat the assertions as actually valid, there must be an | |||
trust relationship between such agents and the validating MTA. | assessment of the trust relationship between such agents and the | |||
validating MTA. | ||||
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 creator of the header field to the | Simply put, a transfer from the creator of the header field to the | |||
consumer must occur within a context of trust that the creator's | consumer must occur within a context of trust that the creator's | |||
skipping to change at page 5, line 10 | skipping to change at page 6, line 7 | |||
all hosts that do not deliberately provide some kind of messaging | all hosts that do not deliberately provide some kind of messaging | |||
service for the receiving ADMD's users, and "internal" includes those | service for the receiving ADMD's users, and "internal" includes those | |||
hosts that do. By this definition, the hosts within a "trust | hosts that do. By this definition, the hosts within a "trust | |||
boundary" may lie entirely within a receiving ADMD's direct control, | boundary" may lie entirely within a receiving ADMD's direct control, | |||
or they can include hosts managed by another ADMD (such as an ISP or | or they can include hosts managed by another ADMD (such as an ISP or | |||
commercial filtering service) but that also provide services for the | commercial filtering service) but that also provide services for the | |||
former. | former. | |||
1.3. Processing Scope | 1.3. Processing Scope | |||
This proposal is intended to address the needs of authenticating | This specification is intended to address the needs of authenticating | |||
messages or properties of messages during their actual transport. It | messages or properties of messages during their actual transport. It | |||
is not meant to address the security of messages that might be | is not meant to address the security of messages that might be | |||
encapsulated within other messages, such as a message/rfc822 [MIME] | encapsulated within other messages, such as a message/rfc822 [MIME] | |||
part within a message. | part within a message. | |||
1.4. Requirements | 1.4. Requirements | |||
This memo establishes no new requirements on existing protocols or | This document establishes no new requirements on existing protocols | |||
servers. | or servers. | |||
In particular, this memo establishes no requirement on MTAs to reject | In particular, this document establishes no requirement on MTAs to | |||
or filter arriving messages that do not pass authentication checks. | reject or filter arriving messages that do not pass authentication | |||
The data conveyed by the defined header field's contents are for the | checks. The data conveyed by the specified header field's contents | |||
information of MUAs and filters and should be used at their | are for the information of MUAs and filters and are to be used at | |||
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. General | 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 [KEYWORDS]. | |||
1.5.2. Security | 1.5.2. Security | |||
[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 [SENDERID] are authorization mechanisms in | As examples: [SPF] and [SENDERID] are authorization mechanisms in | |||
that they express a result that shows whether or not the ADMD that | that they express a result that shows whether or not the ADMD that | |||
apparently sent the message has explicitly authorized the connecting | apparently sent the message has explicitly authorized the connecting | |||
[SMTP] client to relay messages on its behalf but do not actually | [SMTP] client to relay messages on its behalf, but do not actually | |||
validate any property of the message itself. By contrast, [DKIM] is | validate any property of the message itself. By contrast, [DKIM] is | |||
agnostic as to the routing of a message but uses cryptographic | agnostic as to the routing of a message but uses cryptographic | |||
signatures to authenticate agents claiming responsibility for the | signatures to authenticate agents claiming responsibility for the | |||
message (which implies authorization) and ensure it was not modified | message (which implies authorization) and ensure it was not modified | |||
in transit. Since the signatures are not tied to SMTP connections, | in transit. Since the signatures are not tied to SMTP connections, | |||
they can be added by either the ADMD of origin, intermediate ADMDs | they can be added by either the ADMD of origin, intermediate ADMDs | |||
(such as a mailing list server), or both. | (such as a mailing list server), or both. | |||
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 proposal groups them both into a single header field. | |||
skipping to change at page 7, line 29 | skipping to change at page 8, line 6 | |||
V | V | |||
+-----+ +-----+ +------------------+ +------------+ | +-----+ +-----+ +------------------+ +------------+ | |||
| MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | | | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | | |||
+-----+ +-----+ +------------------+ +------------+ | +-----+ +-----+ +------------------+ +------------+ | |||
Generally, it is assumed that the work of applying message | Generally, it is assumed that the work of applying message | |||
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" may 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 from this specification. | to be excluded. | |||
See [EMAIL-ARCH] for further discussion on general email system | See [EMAIL-ARCH] for further discussion on general email system | |||
architecture, and Appendix C of this memo for discussion about the | architecture, and Appendix D of this document for discussion about | |||
common aspects of email authentication in current environments. | the common aspects of email authentication in current environments. | |||
1.6. Trust Environment | 1.6. Trust Environment | |||
This new header field permits one or more message validation | This header field permits one or more message validation mechanisms | |||
mechanisms to communicate its output to one or more separate | to communicate output to one or more separate assessment mechanisms. | |||
assessment mechanisms. These mechanisms operate within a unified | These mechanisms operate within a unified trust boundary that defines | |||
trust boundary that defines an Administrative Management Domain | an Administrative Management Domain (ADMD). An ADMD contains one or | |||
(ADMD). An ADMD contains one or more entities that perform | more entities that perform validation and generate the header field, | |||
validation and generate the header field, and one or more that | and one or more that consume it for some type of assessment. The | |||
consume it for some type of assessment. The field contains no | field contains no integrity or validation mechanism of its own, so | |||
integrity or validation mechanism of its own, so its presence must be | its presence must be trusted implicitly. Hence, use of the header | |||
trusted implicitly. Hence, use of the header field depends upon | field depends upon ensuring that mail entering the ADMD has instances | |||
ensuring that mail entering the ADMD has instances of the header | of the header field claiming to be valid within its boundaries | |||
field claiming to be valid within its boundaries removed, so that | removed, so that occurrences of such header fields can be used safely | |||
occurrences of such header fields can be used safely by consumers. | by consumers. | |||
The "authserv-id" token defined in Section 2.2 can be used to label | The "authserv-id" token defined in Section 2.2 can be used to label | |||
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 within this proposal. | guidance for selecting a token is provided in later sections of this | |||
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 more formal specification. | |||
2.1. General Description | 2.1. General Description | |||
The new header field being defined here is called "Authentication- | The header field specified here is called "Authentication-Results". | |||
Results". It is a Structured Header Field as defined in [MAIL] and | It is a Structured Header Field as defined in [MAIL] and thus all of | |||
thus all of the related definitions in that document apply. | the related definitions in that document apply. | |||
This new header field SHOULD be added at the top of the message as it | This new header field SHOULD be added at the top of the message as it | |||
transits MTAs that do authentication checks so some idea of how far | transits MTAs that do authentication checks so some idea of how far | |||
away the checks were done can be inferred. It therefore should be | away the checks were done can be inferred. It therefore should also | |||
treated as a Trace Field as defined in [MAIL], and thus all of the | be treated as a Trace Field as defined in [MAIL], and thus all of the | |||
related definitions in that document apply. | related definitions in that document apply. | |||
The value of the header field (after removing [MAIL] comments) | The value of the header field (after removing [MAIL] comments) | |||
consists of an authentication identifier, an optional version, and | consists of an authentication identifier, an optional version, and | |||
then a series of "method=result" statements indicating which | then a series of "method=result" statements indicating which | |||
authentication method(s) were applied and their respective results, | authentication method(s) were applied and their respective results, | |||
and then, for each applied method, an optional "reason" string plus | and then, for each applied method, an optional "reason" string, plus | |||
optional "property=value" statements indicating which message | optional "property=value" statements indicating which message | |||
properties were evaluated to reach that conclusion. | properties were evaluated to reach that conclusion. | |||
The header field MAY appear more than once in a single message, or | The header field MAY appear more than once in a single message, or | |||
more than one result MAY be represented in a single header field, or | more than one result MAY be represented in a single header field, or | |||
a combination of these MAY be applied. | a combination of these MAY be applied. | |||
2.2. Formal Definition | 2.2. Formal Definition | |||
Formally, the header field is specified as follows using [ABNF]: | Formally, the header field is specified as follows using [ABNF]: | |||
skipping to change at page 9, line 4 | skipping to change at page 9, line 30 | |||
Formally, the header field is specified as follows using [ABNF]: | Formally, the header field is specified as follows using [ABNF]: | |||
authres-header = "Authentication-Results:" [CFWS] authserv-id | authres-header = "Authentication-Results:" [CFWS] authserv-id | |||
[ CFWS version ] | [ CFWS version ] | |||
( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF | ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF | |||
; the special case of "none" is used to indicate that no | ; the special case of "none" is used to indicate that no | |||
; message authentication is performed | ; message authentication is performed | |||
authserv-id = dot-atom | authserv-id = dot-atom | |||
; see below for a description of this element | ; see below for a description of this element | |||
version = 1*DIGIT [CFWS] | 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"; 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 | |||
resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] | resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] | |||
*( CFWS propspec ) | *( CFWS propspec ) | |||
methodspec = [CFWS] method [CFWS] "=" [CFWS] result | methodspec = [CFWS] method [CFWS] "=" [CFWS] result | |||
; indicates which authentication method was evaluated | ; indicates which authentication method was evaluated | |||
; and what its output was | ||||
reasonspec = "reason" [CFWS] "=" [CFWS] value | reasonspec = "reason" [CFWS] "=" [CFWS] value | |||
; a free-form comment on the reason the given result | ; a free-form comment on the reason the given result | |||
; was returned | ; was returned | |||
propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue | propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue | |||
; an indication of which properties of the message | ; an indication of which properties of the message | |||
; were evaluated by the authentication scheme being | ; were evaluated by the authentication scheme being | |||
; applied to yield the reported result and would be | ; applied to yield the reported result, and would be | |||
; useful to reveal to end users as authenticated | ; useful to reveal to end users as authenticated | |||
method = dot-atom [ [CFWS] "/" [CFWS] version ] | method = dot-atom [ [CFWS] "/" [CFWS] version ] | |||
; a method indicates which method's result is | ; a method indicates which method's result is | |||
; represented by "result", and is one of the methods | ; represented by "result", and is one of the methods | |||
; explicitly defined as valid in this document | ; explicitly defined as valid in this document | |||
; or is an extension method as defined below | ; or is an extension method as defined below | |||
result = dot-atom | result = dot-atom | |||
; indicates the results of the attempt to authenticate | ; indicates the results of the attempt to authenticate | |||
; the message; see below for details | ; the message; see below for details | |||
skipping to change at page 9, line 48 | skipping to change at page 10, line 27 | |||
; from a message header field, or was some property of | ; from a message header field, or was some property of | |||
; the message body, or some other property evaluated by | ; the message body, or some other property evaluated by | |||
; the receiving MTA | ; the receiving MTA | |||
property = dot-atom | property = dot-atom | |||
; if "ptype" is "smtp", this indicates which [SMTP] | ; if "ptype" is "smtp", this indicates which [SMTP] | |||
; command provided the value that was evaluated by the | ; command provided the value that was evaluated by the | |||
; authentication scheme being applied; if "ptype" is | ; authentication scheme being applied; if "ptype" is | |||
; "header", this indicates from which header field the | ; "header", this indicates from which header field the | |||
; value being evaluated was extracted; if "ptype" is | ; value being evaluated was extracted; if "ptype" is | |||
; "body", this indicates the offset into the body at which | ; "body", this indicates where in the message body | |||
; content of interest was detected; if "ptype" is "policy" | ; a value being evaluated can be found (e.g., a specific | |||
; then this indicates the name of the policy that caused | ; offset into the message or a MIME part); | |||
; this header field to be added (see below) | ; if "ptype" is "policy" then this indicates the name | |||
; of the policy that caused this header field to be | ||||
; added (see below) | ||||
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; if the value | ; by the "ptype.property" construction; if the value | |||
; identifies something intended to be an e-mail identity, | ; identifies something intended to be an e-mail identity, | |||
; then it MUST use the right hand portion of this ABNF | ; then it MUST use the right hand portion of this ABNF | |||
; definition | ; definition | |||
The "local-part" is as defined in Section 3.4.1, and "dot-atom" is | The "local-part" is as defined in Section 3.4.1, and "dot-atom" is | |||
defined in Section 3.2.3, of [MAIL]. | defined in Section 3.2.3, of [MAIL]. | |||
skipping to change at page 10, line 49 | skipping to change at page 11, line 32 | |||
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. For example, if a method would normally report a | extracted. For example, if a method would normally report a | |||
"ptype.property" of "header.From" and no From: header field was | "ptype.property" of "header.From" and no From: header field was | |||
present, the method can use "policy" to indicate that no conclusion | present, the method can use "policy" to indicate that no conclusion | |||
about the authenticity of the message could be reached. | about the authenticity of the message could be reached. | |||
2.3. Authentication Identifier Field | 2.3. Authentication Identifier Field | |||
Every Authentication-Results header field has an authentication | Every Authentication-Results header field has an authentication | |||
identifier field ("authserv-id" above). This is similar in syntax to | service identifier field ("authserv-id" above). This is similar in | |||
a fully-qualified domain name. | syntax to a fully-qualified domain name. | |||
The authentication identifier field provides a unique identifier that | The authentication service identifier field provides a unique | |||
refers to the authenticating service within a given ADMD. The | identifier that refers to the authenticating service within a given | |||
uniqueness of the identifier MUST be guaranteed by the ADMD that | ADMD. The uniqueness of the identifier MUST be guaranteed by the | |||
generates it and must pertain to exactly that one ADMD. This | ADMD that generates it and MUST pertain to exactly that one ADMD. | |||
identifier is intended to be machine-readable and not necessarily | This identifier is intended to be machine-readable and not | |||
meaningful to users. MUAs or downstream filters SHOULD use this | necessarily meaningful to users. MUAs or downstream filters SHOULD | |||
identifier to determine whether or not the data contained in an | use this identifier to determine whether or not the data contained in | |||
Authentication-Results header field should be used. | an Authentication-Results header field ought to be used or ignored. | |||
For simplicity and scalability, the authentication identifier SHOULD | For simplicity and scalability, the authentication service identifier | |||
be a common token used throughout the ADMD, such as the DNS domain | SHOULD be a common token used throughout the ADMD, such as the DNS | |||
name used by or within that ADMD. | domain name used by or within that ADMD. | |||
For tracing and debugging purposes, the authentication identifier MAY | For tracing and debugging purposes, the authentication identifier MAY | |||
instead be the hostname of the MTA performing the authentication | instead be the hostname of the MTA performing the authentication | |||
check whose result is being reported. This is also useful for | check whose result is being reported. This is also useful for | |||
another purpose, as described in Section 4. Moreover, some | another purpose, as described in Section 4. Moreover, some | |||
implementations have considered appending a delimiter such as "/" and | implementations have considered appending a delimiter such as "/" and | |||
following it with useful transport tracing data such as the [SMTP] | following it with useful transport tracing data such as the [SMTP] | |||
queue ID or a timestamp. | queue ID or a timestamp. | |||
It should be noted, however, that using a local, relative identifier | It should be noted, however, that using a local, relative identifier | |||
like a single hostname, rather than a hierarchical and globally | like a single hostname, rather than a hierarchical and globally | |||
unique ADMD identifier like a DNS domain name, makes configuration | unique ADMD identifier like a DNS domain name, makes configuration | |||
more difficult for large sites. The hierarchical identifier permits | more difficult for large sites. The hierarchical identifier permits | |||
aggregating related, trusted systems together under a single, parent | aggregating related, trusted systems together under a single, parent | |||
identifier, which in turn permits assessing the trust relationship | identifier, which in turn permits assessing the trust relationship | |||
with a single reference. The alternative is a flat namespace | with a single reference. The alternative is a flat namespace | |||
requiring individually listing each trusted system. Since consumers | requiring individually listing each trusted system. Since consumers | |||
must use the identifier to determine whether to use the contents of | will use the identifier to determine whether to use the contents of | |||
the header field: | the header field: | |||
o Changes to the identifier impose a large, centralized | o Changes to the identifier impose a large, centralized | |||
administrative burden. | administrative burden. | |||
o Ongoing administrative changes require constantly updating this | o Ongoing administrative changes require constantly updating this | |||
centralized table, making it difficult to ensure that an MUA or | centralized table, making it difficult to ensure that an MUA or | |||
downstream filter will have access to accurate information for | downstream filter will have access to accurate information for | |||
assessing the usability of the header field's content. In | assessing the usability of the header field's content. In | |||
particular, consumers of the header field will need to know not | particular, consumers of the header field will need to know not | |||
skipping to change at page 12, line 9 | skipping to change at page 12, line 37 | |||
to account for delivery latency or later re-assessment of the | to account for delivery latency or later re-assessment of the | |||
header field's contents. | header field's contents. | |||
Examples of valid authentication identifiers are "example.com", | Examples of valid authentication identifiers are "example.com", | |||
"mail.example.org", "ms1.newyork.example.com", and "example-auth". | "mail.example.org", "ms1.newyork.example.com", and "example-auth". | |||
2.4. Result Values | 2.4. Result Values | |||
Each individual authentication method returns one of a set of | Each individual authentication method returns one of a set of | |||
specific result values. The subsections below define these results | specific result values. The subsections below define these results | |||
for the authentication methods specifically supported by this memo, | for the authentication methods specifically supported by this | |||
and verifiers SHOULD use these values as described below. New | document, and verifiers SHOULD use these values as described below. | |||
methods not specified in this document intended to be supported by | New methods not specified in this document intended to be supported | |||
the header field defined in this memo MUST include a similar result | by the header field defined here MUST include a similar result table | |||
table either in its defining memo or in a supplementary one. | either in its defining document or in a supplementary one. | |||
2.4.1. DKIM and DomainKeys Results | 2.4.1. DKIM and DomainKeys Results | |||
The result values used by [DKIM] and [DOMAINKEYS] are as follows: | The result values used by [DKIM] and [DOMAINKEYS] are as follows: | |||
none: The message was not signed. | none: The message was not signed. | |||
pass: The message was signed, the signature or signatures were | pass: The message was signed, the signature or signatures were | |||
acceptable to the verifier, and the signature(s) passed | acceptable to the verifier, and the signature(s) passed | |||
verification tests. | verification tests. | |||
skipping to change at page 13, line 18 | skipping to change at page 13, line 49 | |||
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. | |||
2.4.2. SPF and Sender-ID Results | 2.4.2. SPF and Sender-ID Results | |||
The result values are used by [SPF] and [SENDERID] as follows: | The result values are used by [SPF] and [SENDERID] as follows: | |||
none: No policy records were published at the sender's DNS domain. | none: No policy records were published at the sender's DNS domain. | |||
neutral: The sender's ADMD has asserted that it cannot or does not | neutral: The sender's ADMD has asserted that it cannot or does not | |||
want to assert whether or not the sending IP address is authorized | want to make a statement as to whether the sending IP address is | |||
to send mail using the sender's DNS domain. | authorized to send mail using the sender's DNS domain. | |||
pass: The client is authorized by the sender's ADMD to inject or | pass: The client is authorized by the sender's ADMD to inject or | |||
relay mail on behalf of the sender's DNS domain. | relay mail on behalf of the sender's DNS domain. | |||
policy: The client is authorized to inject or relay mail on behalf | policy: The client is authorized to inject or relay mail on behalf | |||
of the sender's DNS domain according to the authentication | of the sender's DNS domain according to the authentication | |||
method's algorithm, but local policy dictates that the result is | method's algorithm, but local policy dictates that the result is | |||
unacceptable. | unacceptable. | |||
hardfail: This client is explicitly not authorized to inject or | fail: This client is explicitly not authorized to inject or relay | |||
relay mail using the sender's DNS domain. | mail using the sender's DNS domain. | |||
softfail: The sender's ADMD believes the client was not authorized | softfail: The sender's ADMD believes the client was not authorized | |||
to inject or relay mail using the sender's DNS domain, but is | to inject or relay mail using the sender's DNS domain, but is | |||
unwilling to make a strong assertion to that effect. | unwilling to make a strong assertion to that effect. | |||
temperror: The message could not be verified due to some error that | temperror: The message could not be verified due to some error that | |||
is likely transient in nature, such as a temporary inability to | is likely transient in nature, such as a temporary inability to | |||
retrieve a policy record from DNS. A later attempt may produce a | retrieve a policy record from DNS. A later attempt may produce a | |||
final result. | final result. | |||
skipping to change at page 14, line 36 | skipping to change at page 15, line 22 | |||
temperror: The DNS evaluation could not be completed due to some | temperror: The DNS evaluation could not be completed due to some | |||
error that is likely transient in nature, such as a temporary DNS | error that is likely transient in nature, such as a temporary DNS | |||
error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or | error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or | |||
other error condition resulted. A later attempt may produce a | other error condition resulted. A later attempt may produce a | |||
final result. | final result. | |||
permerror: The DNS evaluation could not be completed because no PTR | permerror: The DNS evaluation could not be completed because no PTR | |||
data are published for the connecting IP address, e.g., a DNS | data are published for the connecting IP address, e.g., a DNS | |||
RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) | RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) | |||
in a reply containing no answers, was returned. This prevented | in a reply containing no answers, was returned. This prevented | |||
completion of the evaluation. | completion of the evaluation. A later attempt is unlikely to | |||
produce a final result. | ||||
There is no "none" for this method since any TCP connection | There is no "none" for this method since any TCP connection | |||
delivering email has an IP address associated with it, so some kind | delivering email has an IP address associated with it, so some kind | |||
of evaluation will always be possible. | of evaluation will always be possible. | |||
For discussion of the format of DNS replies, see [DNS]. | For discussion of the format of DNS replies, see [DNS]. | |||
2.4.4. SMTP AUTH Results | 2.4.4. SMTP AUTH Results | |||
The result values are used by the [AUTH] method are as follows: | The result values are used by the [AUTH] method are as follows: | |||
skipping to change at page 15, line 31 | skipping to change at page 16, line 20 | |||
Note that an agent making use of the data provided by this header | Note that an agent making use of the data provided by this header | |||
field SHOULD consider "fail" and "temperror" to be the synonymous in | field SHOULD consider "fail" and "temperror" to be the synonymous in | |||
terms of message authentication, i.e., the client did not | terms of message authentication, i.e., the client did not | |||
authenticate. | authenticate. | |||
2.4.5. Extension Result Codes | 2.4.5. 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. | |||
Extension results beginning with "x-" will never be defined as | Result codes MUST be registered with the Internet Assigned Numbers | |||
standard fields; such names are reserved for experimental use. | Authority (IANA) and preferably published in an RFC. See Section 6 | |||
Result codes not beginning with "x-" MUST be registered with the | for further details. | |||
Internet Assigned Numbers Authority (IANA) and published in an RFC. | ||||
See Section 6 for further details. | ||||
Implementations reporting new result codes MUST use the "x-" prefix | ||||
until such time as the new method is registered by IANA. | ||||
Extension results MUST only be used within ADMDs that have explicitly | Extension results MUST only be used within ADMDs that have explicitly | |||
consented to use them. These results and the parameters associated | consented to use them. These results and the parameters associated | |||
with them are not documented in RFCs. Therefore, they are subject to | with them are not formally documented. Therefore, they are subject | |||
change at any time and not suitable for production use. Any MTA, MUA | to change at any time and not suitable for production use. Any MTA, | |||
or downstream filter intended for production use SHOULD ignore or | MUA or downstream filter intended for production use SHOULD ignore or | |||
delete any Authentication-Results header field that includes an | delete any Authentication-Results header field that includes an | |||
extension result. | extension result. | |||
2.5. Authentication Methods | 2.5. Authentication Methods | |||
This section defines the supported authentication methods and | This section defines the supported authentication methods and | |||
discusses the proper means for applying experimental and other | discusses the proper means for applying experimental and other | |||
extension methods. | extension methods. | |||
2.5.1. Definition of Initial Methods | 2.5.1. Definition of Initial Methods | |||
As they are currently existing specifications for message | As they are currently existing specifications for message | |||
authentication, it is appropriate to define an authentication method | authentication, it is appropriate to define an authentication method | |||
identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID], and | identifier for each of [ADSP], [ATPS], [AUTH], [DKIM], [DOMAINKEYS], | |||
[SPF]. Therefore, the authentication method identifiers "auth", | [SENDERID], [SPF], and [VBR]. Therefore, the authentication method | |||
"dkim", "domainkeys", "sender-id", and "spf", respectively are hereby | identifiers "dkim-adsp", "dkim-atps", "auth", "dkim", "domainkeys", | |||
defined for MTAs applying those specifications for email message | "sender-id", "spf", and "vbr", respectively are defined for MTAs | |||
authentication. | applying those specifications for email message authentication. | |||
Furthermore, method "iprev" is defined in Section 3. | Furthermore, method "iprev" is defined in Section 3. | |||
See Section 6 for details. | See Section 6 for details. | |||
2.5.2. Extension Methods | 2.5.2. 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. Extension methods beginning with "x-" will never be | specification. Method identifiers MUST be registered with the | |||
defined as standard fields; such names are reserved for experimental | Internet Assigned Numbers Authority (IANA) and, preferably, published | |||
use. Method identifiers not beginning with "x-" MUST be registered | in an RFC. See Section 6 for further details. | |||
with the Internet Assigned Numbers Authority (IANA) and published in | ||||
an RFC. See Section 6 for further details. | ||||
Extension methods may be defined for the following reasons: | Extension methods can be defined for the following reasons: | |||
1. To allow additional information from new authentication systems | 1. To allow additional information from new authentication systems | |||
to be communicated to MUAs or downstream filters. The names of | to be communicated to MUAs or downstream filters. The names of | |||
such identifiers should reflect the name of the method being | such identifiers should reflect the name of the method being | |||
defined, but should not be needlessly long. | defined, but should not be needlessly long. | |||
2. To allow the creation of "sub-identifiers" that indicate | 2. To allow the creation of "sub-identifiers" that indicate | |||
different levels of authentication and differentiate between | different levels of authentication and differentiate between | |||
their relative strengths, e.g., "auth1-weak" and "auth1-strong". | their relative strengths, e.g., "auth1-weak" and "auth1-strong". | |||
Implementations of new methods MUST use the "x-" prefix until such | Authentication method implementers are encouraged to provide adequate | |||
time as the new method is registered by IANA. | ||||
Authentication method implementors are encouraged to provide adequate | ||||
information, via [MAIL] comments if necessary, to allow an MUA | information, via [MAIL] comments if necessary, to allow an MUA | |||
developer to understand or relay ancillary details of authentication | developer to understand or relay anciliary details of authentication | |||
results. For example, if it might be of interest to relay what data | results. For example, if it might be of interest to relay what data | |||
was used to perform an evaluation, such information could be relayed | was used to perform an evaluation, such information could be relayed | |||
as a comment in the header field, such as: | 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 in RFCs. | |||
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 method identifier. | header field that includes an experimental (unknown) method | |||
identifier. | ||||
3. The "iprev" Authentication Method | 3. The "iprev" Authentication Method | |||
This section defines an additional authentication method called | This section defines an additional authentication method called | |||
"iprev". | "iprev". | |||
In general, "iprev" is an attempt to verify that a client appears to | In general, "iprev" is an attempt to verify that a client appears to | |||
be valid based on some DNS queries. Upon receiving a session | be valid based on some DNS queries. Upon receiving a session | |||
initiation of some kind from a client, the IP address of the client | initiation of some kind from a client, the IP address of the client | |||
peer is queried for matching names (i.e., a number-to-name | peer is queried for matching names (i.e., a number-to-name | |||
translation, also known as a "reverse lookup" or a "PTR" record | translation, also known as a "reverse lookup" or a "PTR" record | |||
query). Once that result is acquired, a lookup of each of the names | query). Once that result is acquired, a lookup of each of the names | |||
(i.e., a name-to-number translation, or an "A" or "AAAA" record | (i.e., a name-to-number translation, or an "A" or "AAAA" record | |||
query) thus retrieved is done. The response to this second check | query) thus retrieved is done. The response to this second check | |||
should result in at least one mapping back to the client's IP | should result in at least one mapping back to the client's IP | |||
address. | address. | |||
More algorithmically: if the client peer's IP address is I, the list | Expressed as an algorithm: If the client peer's IP address is I, the | |||
of names to which I maps (after a "PTR" query) is the set N, and the | list of names to which I maps (after a "PTR" query) is the set N, and | |||
union of IP addresses to which each member of N maps (after | the union of IP addresses to which each member of N maps (after | |||
corresponding "A" and "AAAA" queries) is L, then this test is | corresponding "A" and "AAAA" queries) is L, then this test is | |||
successful if I is an element of L. | successful if I is an element of L. | |||
The response to a PTR query could contain multiple names. To prevent | The response to a PTR query could contain multiple names. To prevent | |||
heavy DNS loads, agents performing these queries MUST be implemented | heavy DNS loads, agents performing these queries MUST be implemented | |||
such that the number of names evaluated by generation of | such that the number of names evaluated by generation of | |||
corresponding A or AAAA queries is finite, though it MAY be | corresponding A or AAAA queries is finite, though it MAY be | |||
configurable by an administrator. As an example, Section 5.5 of | configurable by an administrator. As an example, Section 5.5 of | |||
[SPF] chose a limit of 10 for its implementation of this algorithm. | [SPF] chose a limit of 10 for its implementation of this algorithm. | |||
skipping to change at page 18, line 8 | skipping to change at page 18, line 36 | |||
since the ADMD in which the client's PTR claims it belongs has | since the ADMD in which the client's PTR claims it belongs has | |||
confirmed that claim by including corresponding data in its DNS | confirmed that claim by including corresponding data in its DNS | |||
domain. A failure to match constitutes a "fail". There is no case | domain. A failure to match constitutes a "fail". There is no case | |||
in which a "neutral" result can be returned. The remaining | in which a "neutral" result can be returned. The remaining | |||
"temperror" and "permerror" cases refer, respectively, to temporary | "temperror" and "permerror" cases refer, respectively, to temporary | |||
and permanent DNS query errors. | and permanent DNS query errors. | |||
There is some contention regarding the wisdom and reliability of this | There is some contention regarding the wisdom and reliability of this | |||
test. For example, in some regions it can be difficult for this test | test. For example, in some regions it can be difficult for this test | |||
ever to pass because the practice of arranging to match the forward | ever to pass because the practice of arranging to match the forward | |||
and reverse DNS is infrequently observed. Therefore, the actual | and reverse DNS is infrequently observed. Therefore, the precise | |||
implementation details of how a verifier performs an "iprev" test are | implementation details of how a verifier performs an "iprev" test are | |||
not specified here. The verifier MAY report a successful or failed | not specified here. The verifier MAY report a successful or failed | |||
"iprev" test at its discretion having done some kind of check of the | "iprev" test at its discretion having done some kind of check of the | |||
validity of the connection's identity using DNS. It is incumbent | validity of the connection's identity using DNS. It is incumbent | |||
upon an agent making use of the reported "iprev" result to understand | upon an agent making use of the reported "iprev" result to understand | |||
what exactly that particular verifier is attempting to report. | what exactly that particular verifier is attempting to report. | |||
Extensive discussion of reverse DNS mapping and its implications can | Extensive discussion of reverse DNS mapping and its implications can | |||
be found in [DNSOP-REVERSE]. In particular, it recommends that | be found in [DNSOP-REVERSE]. In particular, it recommends that | |||
applications avoid using this test as a means of authentication or | applications avoid using this test as a means of authentication or | |||
security. Its presence in this memo is not an endorsement, but is | security. Its presence in this document is not an endorsement, but | |||
merely acknowledgement that the method remains common and provides | is merely acknowledgement that the method remains common and provides | |||
the means to relay the results of that test. | the means to relay the results of that test. | |||
4. Adding the Header Field to A Message | 4. Adding the Header Field to A Message | |||
This specification makes no attempt to evaluate the relative | This specification makes no attempt to evaluate the relative | |||
strengths of various message authentication methods that may become | strengths of various message authentication methods that may become | |||
available. As such, the order of the presented authentication | available. As such, the order of the presented authentication | |||
methods and results MUST NOT be used either to imply or infer the | methods and results MUST NOT be used either to imply or infer the | |||
importance or strength of any given method over another. Instead, | importance or strength of any given method over another. Instead, | |||
the MUA or downstream filter consuming this header field must | the MUA or downstream filter consuming this header field is to | |||
interpret the result of each method based on its own knowledge of | interpret the result of each method based on its own knowledge of | |||
what that method evaluates. | what that method evaluates. | |||
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 defined in Section 2.5.2, | IANA registry, or an extension method as described in Section 2.5.2, | |||
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.4.5. | registry, or an extension result code as defined in Section 2.4.5. | |||
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 MUST add this header field | An MTA compliant with this specification MUST add 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 applied | indicate which MTA or ADMD performed the test, which test got applied | |||
and what the result was. If an MTA applies more than one such test, | and what the result was. If an MTA applies more than one such test, | |||
it MUST add this header field either once per test, or once | it MUST add 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 to indicate explicitly that no message | identifier portion and the "none" token (see Section 2.2) to indicate | |||
authentication schemes were applied prior to delivery of this | explicitly that no message authentication schemes were applied prior | |||
message. | to delivery of this message. | |||
An MTA adding this header field must take steps to identify it as | An MTA adding this header field MUST take steps to identify it as | |||
legitimate to the MUAs or downstream filters that will ultimately | legitimate to the MUAs or downstream filters that will ultimately | |||
consume its content. One required process to do so is described in | consume its content. One REQUIRED process to do so is described in | |||
Section 5. Further measures may be required in some environments. | Section 5. Further measures may be necessary in some environments. | |||
Some possible solutions are enumerated in Section 7.1. This memo | Some possible solutions are enumerated in Section 7.1. This document | |||
does not mandate any specific solution to this issue as each | does not mandate any specific solution to this issue as each | |||
environment has its own facilities and limitations. | environment has its own facilities and limitations. | |||
For MTAs that add this header field, adding header fields in order | For MTAs that add this header field, adding header fields in order | |||
(at the top), per Section 3.6 of [MAIL], is particularly important. | (at the top), per Section 3.6 of [MAIL], is particularly important. | |||
Moreover, this header field SHOULD be inserted above any other trace | Moreover, this header field SHOULD be inserted above any other trace | |||
header fields such MTAs might prepend. This allows easy detection of | header fields such MTAs might prepend. This allows easy detection of | |||
header fields that can be trusted. | header fields that can be trusted. | |||
End users making direct use of this header field may inadvertently | End users making direct use of this header field might inadvertently | |||
trust information that has not been properly vetted. If, for | trust information that has not been properly vetted. If, for | |||
example, a basic [SPF] result were to be relayed that claims an | example, a basic [SPF] result were to be relayed that claims an | |||
authenticated addr-spec, the local-part of that addr-spec has | authenticated addr-spec, the local-part of that addr-spec has | |||
actually not been authenticated. Thus, an MTA adding this header | actually not been authenticated. Thus, an MTA adding this header | |||
field SHOULD NOT include any data that has not been authenticated by | field SHOULD NOT include any data that has not been authenticated by | |||
the method(s) being applied. Moreover, MUAs SHOULD NOT render to | the method(s) being applied. Moreover, MUAs SHOULD NOT render to | |||
users such information if it is presented by a method known not to | users such information if it is presented by a method known not to | |||
authenticate it. | authenticate it. | |||
4.1. Header Field Position and Interpretation | 4.1. Header Field Position and Interpretation | |||
In order to ensure non-ambiguous results and avoid the impact of | In order to ensure non-ambiguous results and avoid the impact of | |||
false header fields, MUAs and downstream filters SHOULD NOT interpret | false header fields, MUAs and downstream filters SHOULD NOT interpret | |||
this header field unless specifically instructed to do so by the user | this header field unless specifically instructed 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 should not | default". Naturally then, users or administrators ought not activate | |||
activate such a feature unless they are certain the header field will | such a feature unless they are certain the header field will be added | |||
be added by the border MTA that accepts the mail that is ultimately | by the border MTA that accepts the mail that is ultimately read by | |||
read by the MUA, and instances of the header field appearing to be | the MUA, and instances of the header field appearing to originate | |||
from within the ADMD but actually added by foreign MTAs will be | within the ADMD but are actually added by foreign MTAs will be | |||
removed before delivery. | 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 identifier it bears appears to | header field unless the authentication service identifier it bears | |||
be one used within its own ADMD as configured by the user or | appears to be one used within its own ADMD as configured by the user | |||
administrator. | or 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 result code registry, or a "ptype" not | "result" not specified in the result code registry, or a "ptype" not | |||
listed in the corresponding registry for such values as defined in | listed in the corresponding registry for such values as defined in | |||
Section 6. Moreover, such agents MUST ignore a result indicated for | Section 6. Moreover, such agents MUST ignore a result indicated for | |||
any "method" they do not specifically support. | any "method" they do not specifically support. | |||
An MUA SHOULD NOT reveal these results to end users unless the | An MUA SHOULD NOT reveal these results to end users unless the | |||
results are accompanied by, at a minimum, some associated reputation | results are accompanied by, at a minimum, some associated reputation | |||
data about the authenticated origin identifiers within the message. | data about the authenticated origin identifiers within the message. | |||
skipping to change at page 20, line 36 | skipping to change at page 21, line 18 | |||
4.2. Local Policy Enforcement | 4.2. Local Policy Enforcement | |||
If a site's local policy is to consider a non-recoverable failure | If a site's local policy is to consider a non-recoverable failure | |||
result (e.g., "fail" for DKIM, "hardfail" for SPF) for any particular | result (e.g., "fail" for DKIM, "hardfail" for SPF) for any particular | |||
authentication method as justification to reject the message | authentication method as justification to reject the message | |||
completely, the border MTA SHOULD issue an [SMTP] rejection response | completely, the border MTA SHOULD issue an [SMTP] rejection response | |||
to the message rather than adding this header field with the failure | to the message rather than adding this header field with the failure | |||
result and allowing it to proceed toward delivery. This is more | result and allowing it to proceed toward delivery. This is more | |||
desirable than allowing the message to reach an internal host's MTA | desirable than allowing the message to reach an internal host's MTA | |||
or spam filter, thus possibly generating a local rejection such as a | or spam filter, thus possibly generating a local rejection such as a | |||
[DSN] to a forged originator. | [DSN] to a forged originator. Such generated rejections are | |||
colloquially known as "backscatter". | ||||
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.4). | codes described in Section 2.4). | |||
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. Unfortunately, this | policy is enforced at the MUA and not the MTA. | |||
may be a common scenario. | ||||
5. Removing the Header Field | 5. Removing the Header Field | |||
For security reasons, any MTA conforming to this specification MUST | For security reasons, any MTA conforming to this specification MUST | |||
delete any discovered instance of this header field that claims to | delete any discovered instance of this header field that claims, by | |||
have been added within its trust boundary and that did not come from | virtue of its authentication service identifier, to have been added | |||
another trusted MTA. For example, an MTA (border or otherwise) for | within its trust boundary and that did not come directly from another | |||
trusted MTA. For example, an MTA (border or otherwise) for | ||||
example.com receiving a message MUST delete any instance of this | example.com receiving a message MUST delete any instance of this | |||
header field bearing an authentication identifier indicating the | header field bearing an authentication service identifier indicating | |||
header field was added within example.com prior to adding its own | the header field was added within example.com prior to adding its own | |||
header fields. This may mean each MTA will have to be equipped with | header fields. This could mean each MTA will have to be equipped | |||
a list of internal MTAs known to be compliant (and hence | with a list of internal MTAs known to be compliant (and hence | |||
trustworthy). | trustworthy). | |||
For simplicity and maximum security, a border MTA MAY remove all | For simplicity and maximum security, a border MTA MAY 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 should be let in, removing all others. | information should be admitted, removing all others. | |||
As stated in Section 1.2, a formal definition of "trust boundary" is | As stated in Section 1.2, a formal definition of "trust boundary" is | |||
deliberately not made here. It is entirely possible that a border | deliberately not made here. It is entirely possible that a border | |||
MTA for example.com might explicitly trust authentication results | MTA for example.com will explicitly trust authentication results | |||
asserted by upstream host example.net even though they exist in | asserted by upstream host example.net even though they exist in | |||
completely disjoint administrative boundaries. In that case, the | completely disjoint administrative boundaries. In that case, the | |||
border MTA MAY elect not to delete those results; moreover, the | border MTA MAY elect not to delete those results; moreover, the | |||
upstream host doing some authentication work could apply a signing | upstream host doing some authentication work could apply a signing | |||
technology such as [DKIM] on its own results to assure downstream | technology such as [DKIM] on its own results to assure downstream | |||
hosts of their authenticity. An example of this is provided in | hosts of their authenticity. An example of this is provided in | |||
Appendix B. | Appendix C. | |||
Similarly, in the case of messages signed using [DKIM] or other | Similarly, in the case of messages signed using [DKIM] or other | |||
message signing methods that sign header fields, this may invalidate | message signing methods that sign header fields, this removal action | |||
one or more signatures on the message if they covered the header | could invalidate one or more signatures on the message if they | |||
field to be removed at the time of signing. 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 headers. However, signing agents MAY therefore | message with forged header fields. However, signing agents MAY | |||
elect to omit these header fields from signing to avoid this | therefore elect to omit these header fields from signing to avoid | |||
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 if the [SMTP] connection relaying the | MTA MUST remove such a header field if the [SMTP] connection relaying | |||
message is not from a trusted internal MTA. | the message is not from a trusted internal MTA. | |||
6. IANA Considerations | 6. IANA Considerations | |||
IANA has registered a new header field and created two new tables as | IANA has registered the defined header field and created two tables | |||
described below. | as described below. These registry actions were originally defined | |||
by [AR-ORIG] and are repeated here to provide a single, current | ||||
reference. | ||||
6.1. The Authentication-Results Header Field | 6.1. The Authentication-Results Header Field | |||
Per [IANA-HEADERS], the "Authentication-Results" header field has | Per [IANA-HEADERS], the "Authentication-Results" header field has | |||
been added to the IANA Permanent Message Header Field Registry. The | been added to the IANA Permanent Message Header Field Registry. The | |||
following is the registration template: | following is the updated 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 5451 | Specification document(s): [this memo] | |||
Related information: | Related information: | |||
Requesting review of any proposed changes and additions to | Requesting review of any proposed changes and additions to | |||
this field is recommended. | this field is recommended. | |||
6.2. Email Authentication Method Name Registry | 6.2. Email Authentication Method Name Registry | |||
Names of message authentication methods supported by this | Names of message authentication methods supported by this | |||
specification must be registered with IANA, with the exception of | specification are to be registered with IANA, with the exception of | |||
experimental names as described in Section 2.5.2. | experimental names as described in Section 2.5.2. A registry was | |||
created by [AR-ORIG] for this purpose. This document changes the | ||||
registration rules governing this registry. | ||||
New entries are assigned only for values that have received Expert | ||||
Review, per [IANA-CONSIDERATIONS]. The Designated Expert shall be | ||||
appointed by the IESG. The Designated Expert has discretion to | ||||
request that a publication be referenced if a clear, concise | ||||
definition of the authentication method cannot be provided such that | ||||
interoperability is assured. Registrations should otherwise be | ||||
permitted. | ||||
New entries are assigned only for values that have been documented in | ||||
a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. | ||||
Each method must register a name, the specification that defines it, | Each method must register a name, the specification that defines it, | |||
one or more "ptype" values appropriate for use with that method, | and zero or more "ptype" values appropriate for use with that method, | |||
which "property" value(s) should be reported by that method, and a | which "property" value(s) should be reported by that method, and a | |||
description of the "value" to be used with each. | description of the "value" to be used with each. | |||
The initial set of entries in this registry is as follows: | All existing registry entries that reference [AR-ORIG] are to be | |||
updated to eference this document. | ||||
+------------+----------+--------+----------------+--------------------+ | ||||
| Method | Defined | ptype | property | value | | ||||
+------------+----------+--------+----------------+--------------------+ | ||||
| auth | RFC4954 | smtp | auth | AUTH parameter of | | ||||
| | | | | the SMTP MAIL | | ||||
| | | | | command | | ||||
+------------+----------+--------+----------------+--------------------+ | ||||
| dkim | RFC4871 | header | d | value of | | ||||
| | | | | signature "d" tag | | ||||
| | | +----------------+--------------------+ | ||||
| | | | i | value of | | ||||
| | | | | signature "i" tag | | ||||
+------------+----------+--------+----------------+--------------------+ | ||||
| domainkeys | RFC4870 | header | d | value of | | ||||
| | | | | signature "d" tag | | ||||
| | | +----------------+--------------------+ | ||||
| | | | from | value of From | | ||||
| | | | | header field after | | ||||
| | | | | removing comments | | ||||
| | | | | and local-part if | | ||||
| | | | | not authenticated | | ||||
| | | +----------------+--------------------+ | ||||
| | | | sender | value of Sender | | ||||
| | | | | header field after | | ||||
| | | | | removing comments | | ||||
| | | | | and local-part if | | ||||
| | | | | not authenticated | | ||||
+------------+----------+--------+----------------+--------------------+ | ||||
| iprev | this | policy | iprev | client IP address | | ||||
| | document | | | | | ||||
+------------+----------+--------+----------------+--------------------+ | ||||
| sender-id | RFC4406 | header | name of header | value of header | | ||||
| | | | field used by | field used by PRA | | ||||
| | | | the Purported | after removing | | ||||
| | | | Responsible | comments and parts | | ||||
| | | | Address (PRA) | not authenticated | | ||||
+------------+----------+--------+----------------+--------------------+ | ||||
| spf | RFC4408 | smtp | mailfrom | envelope sender | | ||||
| | | | | after removing | | ||||
| | | | | parts not | | ||||
| | | | | authenticated | | ||||
| | +--------+----------------+--------------------+ | ||||
| | | smtp | helo | HELO/EHLO value | | ||||
+------------+----------+--------+----------------+--------------------+ | ||||
6.3. Email Authentication Result Name Registry | 6.3. Email Authentication Result Name Registry | |||
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.4.5. | experimental codes as described in Section 2.4.5. A registry was | |||
created by [AR-ORIG] for this purpose. This document changes the | ||||
New entries are assigned only for result codes that have been | registration rules governing this registry. | |||
documented in a published RFC that has had IETF Review, per | ||||
[IANA-CONSIDERATIONS]. Each code must register a name, the document | ||||
that establishes the registration, the authentication method(s) that | ||||
uses it, and either a definition of the semantics of its use or a | ||||
reference to the place where those semantics are defined. | ||||
The initial set of entries in this registry is as follows: | ||||
+-----------+----------+----------------+------------------------------+ | New entries are assigned only for values that have received Expert | |||
| Code | Defined | Auth Method(s) | Meaning | | Review, per [IANA-CONSIDERATIONS]. The Designated Expert shall be | |||
+-----------+----------+----------------+------------------------------+ | appointed by the IESG. The Designated Expert has discretion to | |||
| none | this | dkim | section 2.4.1 | | request that a publication be referenced if a clear, concise | |||
| | document | domainkeys | | | definition of the authentication result cannot be provided such that | |||
| | +----------------+------------------------------+ | interoperability is assured. Registrations should otherwise be | |||
| | | spf | section 2.4.2 | | permitted. | |||
| | | sender-id | | | ||||
| | +----------------+------------------------------+ | ||||
| | | auth | section 2.4.4 | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
| pass | this | dkim | section 2.4.1 | | ||||
| | document | domainkeys | | | ||||
| | +----------------+------------------------------+ | ||||
| | | spf | section 2.4.2 | | ||||
| | | sender-id | | | ||||
| | +----------------+------------------------------+ | ||||
| | | iprev | section 2.4.3 | | ||||
| | +----------------+------------------------------+ | ||||
| | | auth | section 2.4.4 | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
| fail | this | dkim | section 2.4.1 | | ||||
| | document | domainkeys | | | ||||
| | +----------------+------------------------------+ | ||||
| | | iprev | section 2.4.3 | | ||||
| | +----------------+------------------------------+ | ||||
| | | auth | section 2.4.4 | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
| policy | this | dkim | section 2.4.1 | | All existing registry entries that reference [AR-ORIG] are to be | |||
| | document | domainkeys | | | updated to reference this document. | |||
| | +----------------+------------------------------+ | ||||
| | | spf | section 2.4.2 | | ||||
| | | sender-id | | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
| neutral | this | dkim | section 2.4.1 | | ||||
| | document | domainkeys | | | ||||
| | +----------------+------------------------------+ | ||||
| | | spf | section 2.4.2 | | ||||
| | | sender-id | | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
| temperror | this | dkim | section 2.4.1 | | ||||
| | document | domainkeys | | | ||||
| | +----------------+------------------------------+ | ||||
| | | spf | section 2.4.2 | | ||||
| | | sender-id | | | ||||
| | +----------------+------------------------------+ | ||||
| | | iprev | section 2.4.3 | | ||||
| | +----------------+------------------------------+ | ||||
| | | auth | section 2.4.4 | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
| permerror | this | dkim | section 2.4.1 | | ||||
| | document | domainkeys | | | ||||
| | +----------------+------------------------------+ | ||||
| | | spf | section 2.4.2 | | ||||
| | | sender-id | | | ||||
| | +----------------+------------------------------+ | ||||
| | | iprev | section 2.4.3 | | ||||
| | +----------------+------------------------------+ | ||||
| | | auth | section 2.4.4 | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
| hardfail | this | spf | section 2.4.2 | | ||||
| | document | sender-id | | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
| softfail | this | spf | section 2.4.2 | | ||||
| | document | sender-id | | | ||||
+-----------+----------+----------------+------------------------------+ | ||||
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 mail is handled by a | An MUA or filter that accesses a mailbox whose mail is handled by a | |||
non-conformant MTA, and understands Authentication-Results header | non-conformant MTA, and understands Authentication-Results header | |||
skipping to change at page 26, line 36 | skipping to change at page 24, line 31 | |||
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. | |||
Proposed alternate solutions to this problem are nascent: | Proposed alternate solutions to this problem are nascent: | |||
1. Possibly the simplest is a digital signature protecting the | 1. Possibly the simplest is a digital signature protecting the | |||
header field, such as using [DKIM], that can be verified by an | header field, such as using [DKIM], that can be verified by an | |||
MUA by using a posted public key. Although one of the main | MUA by using a posted public key. Although one of the main | |||
purposes of this memo is to relieve the burden of doing message | purposes of this document is to relieve the burden of doing | |||
authentication work at the MUA, this only requires that the MUA | message authentication work at the MUA, this only requires that | |||
learn a single authentication scheme even if a number of them are | the MUA learn a single authentication scheme even if a number of | |||
in use at the border MTA. Note that [DKIM] requires that the | them are in use at the border MTA. Note that [DKIM] requires | |||
From header field be signed, although in this application, the | that the From header field be signed, although in this | |||
signing agent (a trusted MTA) likely cannot authenticate that | application, the signing agent (a trusted MTA) likely cannot | |||
value, so the fact that it is signed should be ignored. | authenticate that value, so the fact that it is signed should be | |||
ignored. | ||||
2. Another would be a means to interrogate the MTA that added the | 2. Another would be a means to interrogate the MTA that added the | |||
header field to see if it is actually providing any message | header field to see if it is actually providing any message | |||
authentication services and saw the message in question, but this | authentication services and saw the message in question, but this | |||
isn't especially palatable given the work required to craft and | isn't especially palatable given the work required to craft and | |||
implement such a scheme. | implement such a scheme. | |||
3. Yet another might be a method to interrogate the internal MTAs | 3. Yet another might be a method to interrogate the internal MTAs | |||
that apparently handled the message (based on Received: header | that apparently handled the message (based on Received: header | |||
fields) to determine whether any of them conform to Section 5 of | fields) to determine whether any of them conform to Section 5 of | |||
this memo. This, too, has potentially high barriers-to-entry. | this memo. This, too, has potentially high barriers to entry. | |||
4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to | 4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to | |||
allow an MUA or filtering agent to acquire the "authserv-id" in | allow an MUA or filtering agent to acquire the "authserv-id" in | |||
use within an ADMD, thus allowing it to identify which | use within an ADMD, thus allowing it to identify which | |||
Authentication-Results header fields it can trust. | Authentication-Results header fields it can trust. | |||
5. On the presumption that internal MTAs are fully compliant with | 5. On the presumption that internal MTAs are fully compliant with | |||
Section 3.6 of [MAIL], and the compliant internal MTAs are using | Section 3.6 of [MAIL], and the compliant internal MTAs are using | |||
their own host names or the ADMD's DNS domain name as the | their own host names or the ADMD's DNS domain name as the | |||
"authserv-id" token, the header field proposed here should always | "authserv-id" token, the header field proposed here should always | |||
appear above a Received: header added by a trusted MTA. This can | appear above a Received: header added by a trusted MTA. This can | |||
be used as a test for header field validity. | be used as a test for header field validity. | |||
Support for some of these is planned for future work. | Support for some of these is being considered for future work. | |||
In any case, a mechanism needs to exist for an MUA or filter to | In any case, a mechanism needs to exist for an MUA or filter to | |||
verify that the host that appears to have added the header field (a) | verify that the host that appears to have added the header field (a) | |||
actually did so, and (b) is legitimately adding that header field for | actually did so, and (b) is legitimately adding that header field for | |||
this delivery. Given the variety of messaging environments deployed | this delivery. Given the variety of messaging environments deployed | |||
today, consensus appears to be that specifying a particular mechanism | today, consensus appears to be that specifying a particular mechanism | |||
for doing so is not appropriate for this memo. | for doing so is not appropriate for this document. | |||
Mitigation of the forged header field attack can also be accomplished | Mitigation of the forged header field attack can also be accomplished | |||
by moving the authentication results data into meta-data associated | by moving the authentication results data into meta-data associated | |||
with the message. In particular, an [SMTP] extension could be | with the message. In particular, an [SMTP] extension could be | |||
established which is used to communicate authentication results from | established that is used to communicate authentication results from | |||
the border MTA to intermediate and delivery MTAs; the latter of these | the border MTA to intermediate and delivery MTAs; the latter of these | |||
could arrange to store the authentication results as meta-data | could arrange to store the authentication results as meta-data | |||
retrieved and rendered along with the message by an [IMAP] client | retrieved and rendered along with the message by an [IMAP] client | |||
aware of a similar extension in that protocol. The delivery MTA | aware of a similar extension in that protocol. The delivery MTA | |||
would be told to trust data via this extension only from MTAs it | would be told to trust data via this extension only from MTAs it | |||
trusts, and border MTAs would not accept data via this extension from | trusts, and border MTAs would not accept data via this extension from | |||
any source. There is no vector in such an arrangement for forgery of | any source. There is no vector in such an arrangement for forgery of | |||
authentication data by an outside agent. | authentication data by an outside agent. | |||
7.2. Misleading Results | 7.2. Misleading Results | |||
skipping to change at page 28, line 23 | skipping to change at page 26, line 20 | |||
that some MTAs do reorder header fields, but most do not. Thus, in | that some MTAs do reorder header fields, but most do not. Thus, in | |||
the general case, there will be some indication of which MTAs (if | the general case, there will be some indication of which MTAs (if | |||
any) handled the message after the addition of the header field | any) handled the message after the addition of the header field | |||
defined here. | defined here. | |||
7.4. Reverse IP Query Denial-of-Service Attacks | 7.4. Reverse IP Query Denial-of-Service Attacks | |||
Section 5.5 of [SPF] describes a DNS-based denial-of-service attack | Section 5.5 of [SPF] describes a DNS-based denial-of-service attack | |||
for verifiers that attempt DNS-based identity verification of | for verifiers that attempt DNS-based identity verification of | |||
arriving client connections. A verifier wishing to do this check and | arriving client connections. A verifier wishing to do this check and | |||
report this information SHOULD take care not to go to unbounded | report this information need to take care not to go to unbounded | |||
lengths to resolve "A" and "PTR" queries. MUAs or other filters | lengths to resolve "A" and "PTR" queries. MUAs or other filters | |||
making use of an "iprev" result specified by this memo SHOULD be | making use of an "iprev" result specified by this document need to be | |||
aware of the algorithm used by the verifier reporting the result and | aware of the algorithm used by the verifier reporting the result and, | |||
thus be aware of its limitations. | especially, its limitations. | |||
7.5. Mitigation of Backscatter | 7.5. Mitigation of Backscatter | |||
Failing to follow the instructions of Section 4.2 can result in a | Failing to follow the instructions of Section 4.2 can result in a | |||
denial-of-service attack caused by the generation of [DSN] messages | denial-of-service attack caused by the generation of [DSN] messages | |||
(or equivalent) to addresses that did not send the messages being | (or equivalent) to addresses that did not send the messages being | |||
rejected. | rejected. | |||
7.6. Internal MTA Lists | 7.6. Internal MTA Lists | |||
Section 5 describes a procedure for scrubbing headers that may | Section 5 describes a procedure for scrubbing header fields that may | |||
contain forged authentication results about a message. A compliant | contain forged authentication results about a message. A compliant | |||
installation will have to include, at each MTA, a list of other MTAs | installation will have to include, at each MTA, a list of other MTAs | |||
known to be compliant and trustworthy. Failing to keep this list | known to be compliant and trustworthy. Failing to keep this list | |||
current as internal infrastructure changes may expose an ADMD to | current as internal infrastructure changes may expose an ADMD to | |||
attack. | attack. | |||
7.7. Attacks against Authentication Methods | 7.7. Attacks against Authentication Methods | |||
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 (and later | authentication methods supported by this document (and later | |||
amendments to it) is also a security consideration here. | amendments to it) is also a security 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 | It is possible for an attacker to add an Authentication-Results | |||
header field that is extraordinarily large or otherwise malformed in | header field that is extraordinarily large or otherwise malformed in | |||
an attempt to discover or exploit weaknesses in header field parsing | an attempt to discover or exploit weaknesses in header field parsing | |||
code. Implementors must thoroughly verify all such header fields | code. Implementers must thoroughly verify all such header fields | |||
received from MTAs and be robust against intentionally as well as | 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 | |||
been added by a trusted border MTA (as described above), yet the | been added by a trusted border MTA (as described above), yet the | |||
[SMTP] connection is not coming from an internal machine known to be | [SMTP] connection is not coming from an internal machine known to be | |||
running an authorized MTA. However, in such a configuration, | running an authorized MTA. However, in such a configuration, | |||
legitimate MTAs will have to add this header field when legitimate | legitimate MTAs will have to add this header field when legitimate | |||
internal-only messages are generated. This is also covered in | internal-only messages are generated. This is also covered in | |||
Section 5. | Section 5. | |||
7.10. Encapsulated Instances | 7.10. Encapsulated Instances | |||
[MIME] messages may contain attachments of type "message/rfc822", | [MIME] messages can contain attachments of type "message/rfc822", | |||
which contain other [MAIL] messages. Such an encapsulated message | which contain other [MAIL] messages. Such an encapsulated message | |||
may also contain an Authentication-Results header field. Although | can also contain an Authentication-Results header field. Although | |||
the processing of these is outside of the intended scope of this | the processing of these is outside of the intended scope of this | |||
document (see Section 1.3), some early guidance to MUA developers is | document (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 advised in Section 4.1 to ignore | |||
such instances within [MIME] attachments. Moreover, when extracting | such instances within [MIME] attachments. Moreover, when extracting | |||
a message digest to separate mail store messages or other media, such | a 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. | |||
Implementors of both this proposal and agents that use the data it | Implementers of both this proposal and agents that use the data it | |||
relays are encouraged to become familiar with the issues raised by | 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. and P. Overell, "Augmented BNF for | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for | |||
Syntax Specifications: ABNF", STD 68, | Syntax Specifications: ABNF", STD 68, | |||
RFC 5234, January 2008. | RFC 5234, January 2008. | |||
[AR-ORIG] Kucherawy, M., "Message Header Field for | ||||
Indicating Message Authentication Status", | ||||
RFC 5451, April 2009. | ||||
[IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, | [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, | |||
"Registration Procedures for Message Header | "Registration Procedures for Message Header | |||
Fields", BCP 90, RFC 3864, September 2004. | Fields", BCP 90, RFC 3864, September 2004. | |||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to | [KEYWORDS] Bradner, S., "Key words for use in RFCs to | |||
Indicate Requirement Levels", BCP 14, | Indicate Requirement Levels", BCP 14, | |||
RFC 2119, March 1997. | RFC 2119, March 1997. | |||
[MAIL] Resnick, P., Ed., "Internet Message Format", | [MAIL] Resnick, P., Ed., "Internet Message Format", | |||
RFC 5322, October 2008. | RFC 5322, October 2008. | |||
[MIME] Freed, N. and N. Borenstein, "Multipurpose | [MIME] Freed, N. and N. Borenstein, "Multipurpose | |||
Internet Mail Extensions (MIME) Part One: | Internet Mail Extensions (MIME) Part One: | |||
Format of Internet Message Bodies", RFC 2045, | Format of Internet Message Bodies", RFC 2045, | |||
November 1996. | November 1996. | |||
8.2. Informative References | 8.2. Informative References | |||
[ADSP] Allman, E., Fenton, J., Delany, M., and J. | ||||
Levine, "DomainKeys Identified Mail (DKIM) | ||||
Author Domain Signing Practices (ADSP)", | ||||
RFC 5617, August 2009. | ||||
[ATPS] Kucherawy, M., "DomainKeys Identified Mail | ||||
(DKIM) Authorized Third-Party Signatures", | ||||
RFC 6541, February 2012. | ||||
[AUTH] Siemborski, R. and A. Melnikov, "SMTP Service | [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service | |||
Extension for Authentication", RFC 4954, | Extension for Authentication", RFC 4954, | |||
July 2007. | July 2007. | |||
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, | [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, | |||
M., Fenton, J., and M. Thomas, "DomainKeys | "DomainKeys Identified Mail (DKIM) | |||
Identified Mail (DKIM) Signatures", RFC 4871, | Signatures", RFC 6376, September 2011. | |||
May 2007. | ||||
[DNS] Mockapetris, P., "Domain names - | [DNS] Mockapetris, P., "Domain names - | |||
implementation and specification", STD 13, | implementation and specification", STD 13, | |||
RFC 1035, November 1987. | RFC 1035, November 1987. | |||
[DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. | [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. | |||
Souissi, "DNS Extensions to Support IP Version | Souissi, "DNS Extensions to Support IP Version | |||
6", RFC 3596, October 2003. | 6", RFC 3596, October 2003. | |||
[DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for | [DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for | |||
skipping to change at page 32, line 5 | skipping to change at page 29, line 50 | |||
[SENDERID] Lyon, J. and M. Wong, "Sender ID: | [SENDERID] Lyon, J. and M. Wong, "Sender ID: | |||
Authenticating E-Mail", RFC 4406, April 2006. | Authenticating E-Mail", RFC 4406, April 2006. | |||
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", | [SMTP] Klensin, J., "Simple Mail Transfer Protocol", | |||
RFC 5321, October 2008. | RFC 5321, October 2008. | |||
[SPF] Wong, M. and W. Schlitt, "Sender Policy | [SPF] Wong, M. and W. Schlitt, "Sender Policy | |||
Framework (SPF) for Authorizing Use of Domains | Framework (SPF) for Authorizing Use of Domains | |||
in E-Mail, Version 1", RFC 4408, April 2006. | in E-Mail, Version 1", RFC 4408, April 2006. | |||
Appendix A. Legacy MUAs | [VBR] Hoffman, P., Levine, J., and A. Hathcock, | |||
"Vouch By Reference", RFC 5518, April 2009. | ||||
Implementors of this proposal should be aware that many MUAs are | Appendix A. Acknowledgements | |||
The author wishes to acknowledge the following for their review and | ||||
constructive criticism of this update: S. Moonesamy, Alessandro | ||||
Vesely, [other names] | ||||
Appendix B. Legacy MUAs | ||||
Implementers of this protocol should be aware that many MUAs are | ||||
unlikely to be retrofitted to support the new header field and its | unlikely to be retrofitted to support the new header field and its | |||
semantics. In the interests of convenience and quicker adoption, a | semantics. In the interests of convenience and quicker adoption, a | |||
delivery MTA might want to consider adding things that are processed | delivery MTA might want to consider adding things that are processed | |||
by existing MUAs in addition to the Authentication-Results header | by existing MUAs in addition to the Authentication-Results header | |||
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, other interim means of | to end users. Until this capability is added, other interim means of | |||
conveying authentication results may be necessary while this proposal | conveying authentication results may be necessary while this proposal | |||
and its successors are adopted. | and its successors are adopted. | |||
Appendix B. Authentication-Results Examples | Appendix C. 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 | C.1. Trivial Case; Header Field Not Present | |||
The trivial case: | The trivial case: | |||
Received: from mail-router.example.com | Received: from mail-router.example.com | |||
(mail-router.example.com [192.0.2.1]) | (mail-router.example.com [192.0.2.1]) | |||
by server.example.org (8.11.6/8.11.6) | by server.example.org (8.11.6/8.11.6) | |||
with ESMTP id g1G0r1kA003489; | with ESMTP id g1G0r1kA003489; | |||
Fri, Feb 15 2002 17:19:07 -0800 | Fri, Feb 15 2002 17:19:07 -0800 | |||
From: sender@example.com | From: sender@example.com | |||
Date: Fri, Feb 15 2002 16:54:30 -0800 | Date: Fri, Feb 15 2002 16:54:30 -0800 | |||
skipping to change at page 34, line 5 | skipping to change at page 31, line 30 | |||
Hello! Goodbye! | Hello! Goodbye! | |||
Example 1: Trivial case | Example 1: Trivial case | |||
The "Authentication-Results" header field is completely absent. The | The "Authentication-Results" header field is completely absent. The | |||
MUA may make no conclusion about the validity of the message. This | MUA may make no conclusion about the validity of the message. This | |||
could be the case because the message authentication services were | could be the case because the message authentication services were | |||
not available at the time of delivery, or no service is provided, or | not available at the time of delivery, or no service is provided, or | |||
the MTA is not in compliance with this specification. | the MTA is not in compliance with this specification. | |||
B.2. Nearly Trivial Case; Service Provided, But No Authentication Done | C.2. Nearly Trivial Case; Service Provided, But No Authentication Done | |||
A message that was delivered by an MTA that conforms to this | A message that was delivered by an MTA that conforms to this | |||
specification but provides no actual message authentication service: | specification but provides no actual message authentication service: | |||
Authentication-Results: example.org; none | Authentication-Results: example.org; none | |||
Received: from mail-router.example.com | Received: from mail-router.example.com | |||
(mail-router.example.com [192.0.2.1]) | (mail-router.example.com [192.0.2.1]) | |||
by server.example.org (8.11.6/8.11.6) | by server.example.org (8.11.6/8.11.6) | |||
with ESMTP id g1G0r1kA003489; | with ESMTP id g1G0r1kA003489; | |||
Fri, Feb 15 2002 17:19:07 -0800 | Fri, Feb 15 2002 17:19:07 -0800 | |||
skipping to change at page 35, line 5 | skipping to change at page 32, line 8 | |||
Hello! Goodbye! | Hello! Goodbye! | |||
Example 2: Header present but no authentication done | Example 2: Header present but no authentication done | |||
The "Authentication-Results" header field is present, showing that | The "Authentication-Results" header field is present, showing that | |||
the delivering MTA conforms to this specification. It used its DNS | the delivering MTA conforms to this specification. It used its DNS | |||
domain name as the authserv-id. The presence of "none" (and the | domain name as the authserv-id. The presence of "none" (and the | |||
absence of any method and result tokens) indicates that no message | absence of any method and result tokens) indicates that no message | |||
authentication was done. | authentication was done. | |||
B.3. Service Provided, Authentication Done | C.3. Service Provided, Authentication Done | |||
A message that was delivered by an MTA that conforms to this | A message that was delivered by an MTA that conforms to this | |||
specification and applied some message authentication: | specification and applied some message authentication: | |||
Authentication-Results: example.com; | Authentication-Results: example.com; | |||
spf=pass smtp.mailfrom=example.net | spf=pass smtp.mailfrom=example.net | |||
Received: from dialup-1-2-3-4.example.net | Received: from dialup-1-2-3-4.example.net | |||
(dialup-1-2-3-4.example.net [192.0.2.200]) | (dialup-1-2-3-4.example.net [192.0.2.200]) | |||
by mail-router.example.com (8.11.6/8.11.6) | by mail-router.example.com (8.11.6/8.11.6) | |||
with ESMTP id g1G0r1kA003489; | with ESMTP id g1G0r1kA003489; | |||
skipping to change at page 36, line 5 | skipping to change at page 33, line 5 | |||
Example 3: Header reporting results | Example 3: Header reporting results | |||
The "Authentication-Results" header field is present, indicating that | The "Authentication-Results" header field is present, indicating that | |||
the border MTA conforms to this specification. The authserv-id is | the border MTA conforms to this specification. The authserv-id is | |||
once again the DNS domain name. Furthermore, the message was | once again the DNS domain name. Furthermore, the message was | |||
authenticated by that MTA via the method specified in [SPF]. Note | authenticated by that MTA via the method specified in [SPF]. Note | |||
that since that method cannot authenticate the local-part, it has | that since that method cannot authenticate the local-part, it has | |||
been omitted from the result's value. The MUA could extract and | been omitted from the result's value. The MUA could extract and | |||
relay this extra information if desired. | relay this extra information if desired. | |||
B.4. Service Provided, Several Authentications Done, Single MTA | C.4. Service Provided, Several Authentications Done, Single MTA | |||
A message that was relayed inbound via a single MTA that conforms to | A message that was relayed inbound via a single MTA that conforms to | |||
this specification and applied three different message authentication | this specification and applied three different message authentication | |||
checks: | checks: | |||
Authentication-Results: example.com; | Authentication-Results: example.com; | |||
auth=pass (cram-md5) smtp.auth=sender@example.com; | auth=pass (cram-md5) smtp.auth=sender@example.com; | |||
spf=pass smtp.mailfrom=example.com | spf=pass smtp.mailfrom=example.com | |||
Authentication-Results: example.com; | Authentication-Results: example.com; | |||
sender-id=pass header.from=example.com | sender-id=pass header.from=example.com | |||
skipping to change at page 37, line 5 | skipping to change at page 34, line 5 | |||
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 | This example illustrates a scenario in which a remote user on a | |||
dialup connection (example.net) sends mail to a border MTA | dialup connection (example.net) sends mail to a border MTA | |||
(example.com) using SMTP authentication to prove identity. The | (example.com) using SMTP authentication to prove identity. The | |||
dialup provider has been explicitly authorized to relay mail as | dialup provider has been explicitly authorized to relay mail as | |||
"example.com" resulting in passes by the SPF and SenderID checks. | "example.com" resulting in passes by the SPF and SenderID checks. | |||
B.5. Service Provided, Several Authentications Done, Different MTAs | C.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=hardfail header.from=example.com; | sender-id=fail header.from=example.com; | |||
dkim=pass (good signature) header.i=sender@example.com | dkim=pass (good signature) header.i=sender@example.com | |||
Received: from mail-router.example.com | Received: from mail-router.example.com | |||
(mail-router.example.com [192.0.2.1]) | (mail-router.example.com [192.0.2.1]) | |||
by auth-checker.example.com (8.11.6/8.11.6) | by auth-checker.example.com (8.11.6/8.11.6) | |||
with ESMTP id i7PK0sH7021929; | with ESMTP id i7PK0sH7021929; | |||
Fri, Feb 15 2002 17:19:22 -0800 | Fri, Feb 15 2002 17:19:22 -0800 | |||
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; | ||||
t=1188964191; c=simple/simple; h=From:Date:To:Subject: | ||||
Message-Id:Authentication-Results; | ||||
bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; | ||||
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= | ||||
Authentication-Results: example.com; | Authentication-Results: example.com; | |||
auth=pass (cram-md5) smtp.auth=sender@example.com; | auth=pass (cram-md5) smtp.auth=sender@example.com; | |||
spf=hardfail smtp.mailfrom=example.com | spf=fail smtp.mailfrom=example.com | |||
Received: from dialup-1-2-3-4.example.net | Received: from dialup-1-2-3-4.example.net | |||
(dialup-1-2-3-4.example.net [192.0.2.200]) | (dialup-1-2-3-4.example.net [192.0.2.200]) | |||
by mail-router.example.com (8.11.6/8.11.6) | by mail-router.example.com (8.11.6/8.11.6) | |||
with ESMTP id g1G0r1kA003489; | with ESMTP id g1G0r1kA003489; | |||
Fri, Feb 15 2002 17:19:07 -0800 | Fri, Feb 15 2002 17:19:07 -0800 | |||
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; | ||||
i=sender@example.com; t=1188964191; c=simple/simple; | ||||
h=From:Date:To:Message-Id:Subject; | ||||
bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; | ||||
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= | ||||
From: sender@example.com | From: sender@example.com | |||
Date: Fri, Feb 15 2002 16:54:30 -0800 | Date: Fri, Feb 15 2002 16:54:30 -0800 | |||
To: receiver@example.com | To: receiver@example.com | |||
Message-Id: <12345.abc@example.com> | Message-Id: <12345.abc@example.com> | |||
Subject: here's a sample | Subject: here's a sample | |||
Hello! Goodbye! | Hello! Goodbye! | |||
Example 5: Headers reporting results from multiple MTAs | Example 5: Headers reporting results from multiple MTAs | |||
skipping to change at page 38, line 7 | skipping to change at page 35, line 4 | |||
conformance to this specification. Once again, the authserv-id used | conformance to this specification. Once again, the authserv-id used | |||
is the recipient's DNS domain name. The header field is present | is the recipient's DNS domain name. The header field is present | |||
twice because two different MTAs in the chain of delivery did | twice because two different MTAs in the chain of delivery did | |||
authentication tests. The first, "mail-router.example.com" reports | authentication tests. The first, "mail-router.example.com" reports | |||
that [AUTH] and [SPF] were both used, and [AUTH] passed but [SPF] | that [AUTH] and [SPF] were both used, and [AUTH] passed but [SPF] | |||
failed. In the [AUTH] case, additional data is provided in the | failed. In the [AUTH] case, additional data is provided in the | |||
comment field, which the MUA can choose to render if desired. | comment field, which the MUA can choose to render if desired. | |||
The second MTA, "auth-checker.example.com", reports that it did a | The second MTA, "auth-checker.example.com", reports that it did a | |||
[SENDERID] test (which failed) and a [DKIM] test (which passed). | [SENDERID] test (which failed) and a [DKIM] test (which passed). | |||
Again, additional data about one of the tests is provided as a | Again, additional data about one of the tests is provided as a | |||
comment, which the MUA may choose to render. | comment, which the MUA may choose to render. Also noteworthy here is | |||
the fact that there is a DKIM signature added by example.com that | ||||
assured the integrity of the lower Authentication-Results field. | ||||
Since different hosts did the two sets of authentication checks, the | 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 dialup connection "example.net". The | "example.com" from a user on a dialup 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 [AUTH]. The [SPF] and | authentication at the border MTA using [AUTH]. The [SPF] and | |||
[SENDERID] tests failed since "example.com" has not granted | [SENDERID] tests failed since "example.com" has not granted | |||
"example.net" authority to relay mail on its behalf. However, the | "example.net" authority to relay mail on its behalf. However, the | |||
[DKIM] test passed because the sending user had a private key | [DKIM] test passed because the sending user had a private key | |||
matching one of "example.com"'s published public keys and used it to | matching one of "example.com"'s published public keys and used it to | |||
sign the message. | sign the message. | |||
B.6. Service Provided, Multi-Tiered Authentication Done | C.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 (good signature) header.i=@mail-router.example.net; | dkim=pass reason="good signature" | |||
dkim=fail (bad signature) header.i=@newyork.example.com | header.i=@mail-router.example.net; | |||
dkim=fail reason="bad signature" | ||||
header.i=@newyork.example.com | ||||
Received: from mail-router.example.net | Received: from mail-router.example.net | |||
(mail-router.example.net [192.0.2.250]) | (mail-router.example.net [192.0.2.250]) | |||
by chicago.example.com (8.11.6/8.11.6) | by chicago.example.com (8.11.6/8.11.6) | |||
for <recipient@chicago.example.com> | for <recipient@chicago.example.com> | |||
with ESMTP id i7PK0sH7021929; | with ESMTP id i7PK0sH7021929; | |||
Fri, Feb 15 2002 17:19:22 -0800 | Fri, Feb 15 2002 17:19:22 -0800 | |||
DKIM-Signature: v=1; a=rsa-sha256; s=furble; | DKIM-Signature: v=1; a=rsa-sha256; s=furble; | |||
d=mail-router.example.net; t=1188964198; c=relaxed/simple; | d=mail-router.example.net; t=1188964198; c=relaxed/simple; | |||
h=From:Date:To:Message-Id:Subject:Authentication-Results; | h=From:Date:To:Message-Id:Subject:Authentication-Results; | |||
bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; | bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; | |||
b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= | b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= | |||
Authentication-Results: example.net; | Authentication-Results: example.net; | |||
dkim=pass (good signature) header.i=@newyork.example.com | dkim=pass (good signature) header.i=@newyork.example.com | |||
Received: from smtp.newyork.example.com | Received: from smtp.newyork.example.com | |||
(smtp.newyork.example.com [192.0.2.220]) | (smtp.newyork.example.com [192.0.2.220]) | |||
by mail-router.example.net (8.11.6/8.11.6) | by mail-router.example.net (8.11.6/8.11.6) | |||
with ESMTP id g1G0r1kA003489; | with ESMTP id g1G0r1kA003489; | |||
Fri, Feb 15 2002 17:19:07 -0800 | Fri, Feb 15 2002 17:19:07 -0800 | |||
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=newyork.example.com; | DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; | |||
d=newyork.example.com; | ||||
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 | |||
skipping to change at page 41, line 5 | skipping to change at page 37, line 32 | |||
The border MTA for chicago.example.com explicitly trusts results from | The border MTA for chicago.example.com explicitly trusts results from | |||
mail-router.example.net so that header field is not removed. It | mail-router.example.net so that header field is not removed. It | |||
performs evaluation of both signatures and determines that the first | performs evaluation of both signatures and determines that the first | |||
(most recent) is a "pass" but, because of the aforementioned | (most recent) is a "pass" but, because of the aforementioned | |||
modifications, the second is a "fail". However, the first signature | modifications, the second is a "fail". However, the first signature | |||
included the Authentication-Results header added at mail- | included the Authentication-Results header added at mail- | |||
router.example.net that validated the second signature. Thus, | router.example.net that validated the second signature. Thus, | |||
indirectly, it can be determined that the authentications claimed by | indirectly, it can be determined that the authentications claimed by | |||
both signatures are indeed valid. | both signatures are indeed valid. | |||
Appendix C. Operational Considerations about Message Authentication | Note that two styles of presenting meta-data about the result are in | |||
use here. In one case, the "reason=" clause is present which is | ||||
intended for easy extraction by parsers; in the other case, the CFWS | ||||
production of the ABNF is used to include such data as a header field | ||||
comment. The latter can be harder for parsers to extract given the | ||||
varied supported syntaxes of mail header fields. | ||||
This proposal is predicated on the idea that authentication (and | Appendix D. Operational Considerations about Message Authentication | |||
This protocol is predicated on the idea that authentication (and | ||||
presumably in the future, reputation) work is typically done by | presumably in the future, reputation) work is typically done by | |||
border MTAs rather than MUAs or intermediate MTAs; the latter merely | border MTAs rather than MUAs or intermediate MTAs; the latter merely | |||
make use of the results determined by the former. Certainly this is | make use of the results determined by the former. Certainly this is | |||
not mandatory for participation in electronic mail or message | not mandatory for participation in electronic mail or message | |||
authentication, but the work of this proposal and its deployment to | authentication, but this protocol and its deployment to date are | |||
date is based on that model. The assumption satisfies several common | based on that model. The assumption satisfies several common ADMD | |||
ADMD requirements: | requirements: | |||
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, rejections of messages at the SMTP level | enables, for example, rejections 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 | |||
skipping to change at page 43, line 5 | skipping to change at page 39, line 22 | |||
delivery process has completed. This seriously diminishes the | delivery process has completed. This seriously diminishes the | |||
value of this work when done other than at MTAs. | value of this work when done other 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. | |||
Acknowledgements | Appendix E. Changes since RFC5451 | |||
The author wishes to acknowledge the following for their review and | o Errata #2617 was addressed in RFC6577 and was incorporated here | |||
constructive criticism of this proposal: Eric Allman, Mark Delany, | ||||
Victor Duchovni, Frank Ellermann, Jim Fenton, Philip Guenther, Tony | ||||
Hansen, Paul Hoffman, Scott Kitterman, Eliot Lear, John Levine, Miles | ||||
Libbey, Charles Lindsey, Alexey Melnikov, Douglas Otis, Juan Altmayer | ||||
Pizzorno, Michael Thomas, and Kazu Yamamoto. | ||||
Special thanks to Dave Crocker and S. Moonesamy for their logistical | o Request Internet Standard status | |||
support, and feedback on and contributions to the numerous proposed | ||||
edits throughout the lifetime of this work. | o Change IANA rules to Designated Expert from IETF Review | |||
o Copy current IANA registry entries | ||||
o Add references to ADSP, ATPS, VBR | ||||
o Remove all the "X-" stuff, per BCP178 | ||||
o Adjust language to indicate that this header field was already | ||||
defined, and we're just refreshing and revising | ||||
o In a few places, RFC2119 language had been used in lowercase | ||||
terms; fixed here | ||||
o Errata #2818 addressed | ||||
o Errata #3195 addressed | ||||
o Some minor wordsmithing | ||||
Author's Address | Author's Address | |||
Murray S. Kucherawy | Murray S. Kucherawy | |||
Sendmail, Inc. | 270 Upland Drive | |||
6475 Christie Ave., Suite 350 | San Francisco, CA 94127 | |||
Emeryville, CA 94608 | ||||
US | US | |||
Phone: +1 510 594 5400 | EMail: superuser@gmail.com | |||
EMail: msk+ietf@sendmail.com | ||||
End of changes. 127 change blocks. | ||||
426 lines changed or deleted | 407 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/ |