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/