draft-ietf-appsawg-rfc7001bis-01.txt   draft-ietf-appsawg-rfc7001bis-02.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft February 19, 2015 Internet-Draft February 20, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 23, 2015 Expires: August 24, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-01 draft-ietf-appsawg-rfc7001bis-02
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
to relay that information in a convenient and meaningful way to users to relay that information in a convenient and meaningful way to users
or to make sorting and filtering decisions. or to make sorting and filtering decisions.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2015. This Internet-Draft will expire on August 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 7 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 7
1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8 1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9
2. Definition and Format of the Header Field . . . . . . . . . . 9 2. Definition and Format of the Header Field . . . . . . . . . . 9
2.1. General Description . . . . . . . . . . . . . . . . . . . 9 2.1. General Description . . . . . . . . . . . . . . . . . . . 9
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10
2.3. Property Types (ptypes) . . . . . . . . . . . . . . . . . 12 2.3. Property Types (ptypes) and Properties . . . . . . . . . . 12
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13
2.5. Properties . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6. Authentication Identifier Field . . . . . . . . . . . . . 14 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15
2.7. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15 2.7. Defined Methods and Result Values . . . . . . . . . . . . 15
2.8. Defined Methods and Result Values . . . . . . . . . . . . 16 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16
2.8.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17
2.8.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 18
2.8.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 19
2.8.5. Other Registered Codes . . . . . . . . . . . . . . . . 19 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 19
2.8.6. Extension Methods . . . . . . . . . . . . . . . . . . 19 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 20
2.8.7. Extension Result Codes . . . . . . . . . . . . . . . . 20 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 20
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 21
4. Adding the Header Field to a Message . . . . . . . . . . . . . 22 4. Adding the Header Field to a Message . . . . . . . . . . . . . 22
4.1. Header Field Position and Interpretation . . . . . . . . . 23 4.1. Header Field Position and Interpretation . . . . . . . . . 23
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 24 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 24
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 24 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6.1. The Authentication-Results Header Field . . . . . . . . . 26 6.1. The Authentication-Results Header Field . . . . . . . . . 26
6.2. "Email Authentication Methods" Registry . . . . . . . . . 26 6.2. "Email Authentication Methods" Registry . . . . . . . . . 26
6.3. "Email Authentication Result Names" Registry . . . . . . . 27 6.3. "Email Authentication Result Names" Registry . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 27 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 27
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 29 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 29
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 29 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 29
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 29 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 29
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 30 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 30
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 30 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 30
7.7. Attacks against Authentication Methods . . . . . . . . . . 30 7.7. Attacks against Authentication Methods . . . . . . . . . . 30
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 30 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 30
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 30 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 30
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 31 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 31
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 31 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33
Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 34
Appendix C. Authentication-Results Examples . . . . . . . . . . . 34 Appendix C. Authentication-Results Examples . . . . . . . . . . . 34
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 35 C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 34
C.2. Nearly Trivial Case; Service Provided, but No C.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 35 Authentication Done . . . . . . . . . . . . . . . . . . . 35
C.3. Service Provided, Authentication Done . . . . . . . . . . 36 C.3. Service Provided, Authentication Done . . . . . . . . . . 36
C.4. Service Provided, Several Authentications Done, Single C.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
C.5. Service Provided, Several Authentications Done, C.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 38 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 38
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 40 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 40
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 41 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 41
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 42 Authentication . . . . . . . . . . . . . . . . . . . 42
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 43 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 43
E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 43 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 43
E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 44 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 44
E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document describes a header field called Authentication-Results This document describes a header field called Authentication-Results
for electronic mail messages that presents the results of a message for electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions Agent (MUA) and downstream filters can make filtering decisions
and/or provide a recommendation to the user as to the validity of the and/or provide a recommendation to the user as to the validity of the
skipping to change at page 11, line 46 skipping to change at page 11, line 46
"local-part" is defined in Section 3.4.1 of [MAIL], and "CFWS" is "local-part" is defined in Section 3.4.1 of [MAIL], and "CFWS" is
defined in Section 3.2.2 of [MAIL]. defined in Section 3.2.2 of [MAIL].
"Keyword" is defined in Section 4.1.2 of [SMTP]. "Keyword" is defined in Section 4.1.2 of [SMTP].
The "value" is as defined in Section 5.1 of [MIME]. The "value" is as defined in Section 5.1 of [MIME].
The "domain-name" is as defined in Section 3.5 of [DKIM]. The "domain-name" is as defined in Section 3.5 of [DKIM].
The "Keyword" used in "result" above is further constrained by the The "Keyword" used in "result" above is further constrained by the
necessity of being enumerated in Section 2.8. necessity of being enumerated in Section 2.7.
See Section 2.6 for a description of the authserv-id element. See Section 2.5 for a description of the authserv-id element.
If the value portion of a "pvalue" construction identifies something If the value portion of a "pvalue" construction identifies something
intended to be an e-mail identity, then it MUST use the right hand intended to be an e-mail identity, then it MUST use the right hand
portion of that ABNF definition. portion of that ABNF definition.
The list of commands eligible for use with the "smtp" ptype can be The list of commands eligible for use with the "smtp" ptype can be
found in Section 4.1 of [SMTP]. found in Section 4.1 of [SMTP].
The "propspec" may be omitted if, for example, the method was unable The "propspec" may be omitted if, for example, the method was unable
to extract any properties to do its evaluation yet has a result to to extract any properties to do its evaluation yet has a result to
skipping to change at page 12, line 25 skipping to change at page 12, line 25
converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" converting it to lowercase and dropping any spaces (e.g., "MAIL FROM"
becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.).
A "ptype" value of "policy" indicates a policy decision about the A "ptype" value of "policy" indicates a policy decision about the
message not specific to a property of the message that could be message not specific to a property of the message that could be
extracted. See Section 2.4 for details. extracted. See Section 2.4 for details.
Examples of complete messages using this header field can be found in Examples of complete messages using this header field can be found in
Appendix C. Appendix C.
2.3. Property Types (ptypes) 2.3. Property Types (ptypes) and Properties
The "ptype" in the ABNF above indicates the type of property being The "ptype" in the ABNF above indicates the general type of property
described by the result being reported, upon which the reported being described by the result being reported, upon which the reported
result was based. Coupled with the "property", it inidcates from result was based. Coupled with the "property", which is more
which part of the message the reported data were extracted. specific, they inidcate from which part of the message the reported
data were extracted.
Combinations of ptypes and properties are registered and described in
the "Email Authentication Methods" registry, coupled with the
authentication methods with which they are used. This is further
described in Section 6.
Legal values of "ptype" are as defined in the IANA "Email Legal values of "ptype" are as defined in the IANA "Email
Authentication Property Types" registry, created by Authentication Property Types" registry, created by
[PTYPES-REGISTRY]. The initial values are as follows, copied from [PTYPES-REGISTRY]. The initial values and what they typically
[RFC7001]: indicate are as follows, copied from [RFC7001]:
body: Indicates information that was extracted from the body of the body: Information that was extracted from the body of the message.
message. This might be an arbitrary string of bytes, a hash of a This might be an arbitrary string of bytes, a hash of a string of
string of bytes, a Uniform Resource Identifier, or some other bytes, a Uniform Resource Identifier, or some other content of
content of interest. interest. The "property" is an indication of where within the
message body the extracted content was found, and can indicate an
offset, identify a MIME part, or
header: Indicates information that was extracted from the header of header: Indicates information that was extracted from the header of
the message. This might be the value of a header field or some the message. This might be the value of a header field or some
portion of a header field. portion of a header field. The "property" gives a more precise
indication of the place in the header from which the extraction
took place.
policy: A local policy mechanism was applied that augments or policy: A local policy mechanism was applied that augments or
overrides the result returned by the authentication mechanism. overrides the result returned by the authentication mechanism.
(See Section 2.4.) (See Section 2.4.)
smtp: Indicates information that was extracted from an SMTP command smtp: Indicates information that was extracted from an SMTP command
that was used to relay the message. that was used to relay the message. The "property" indicates
which SMTP command included the extracted content as a parameter.
When a consumer of this header field encounters a "ptype" that it When a consumer of this header field encounters a "ptype" that it
does not understand, it ignores the result reported with that does not understand, it ignores the result reported with that
"ptype". "ptype".
Entries in the "Email Authentication Methods" registry can define
properties that deviate from these definitions when appropriate. For
example, when reporting the result of a [DKIM] evaluation, it would
be redundant to report the name of the header field from which
details were extracted. Thus, instead, DKIM results use the "header"
property to name the signature tag from which a detail of interest
was extracted.
2.4. The "policy" ptype 2.4. The "policy" ptype
A special ptype value of "policy" is also defined. This ptype is A special ptype value of "policy" is also defined. This ptype is
provided to indicate that some local policy mechanism was applied provided to indicate that some local policy mechanism was applied
that augments or even replaces (i.e., overrides) the result returned that augments or even replaces (i.e., overrides) the result returned
by the authentication mechanism. The property and value in this case by the authentication mechanism. The property and value in this case
identify the local policy that was applied and the result it identify the local policy that was applied and the result it
returned. returned.
For example, a DKIM signature is not required to include the Subject For example, a DKIM signature is not required to include the Subject
skipping to change at page 13, line 46 skipping to change at page 14, line 16
normally registered with IANA or otherwise specified apart from normally registered with IANA or otherwise specified apart from
setting syntax restrictions that allow for easy parsing within the setting syntax restrictions that allow for easy parsing within the
rest of the header field. rest of the header field.
This ptype existed in the original specification for this header This ptype existed in the original specification for this header
field, but without a complete description or example of intended use. field, but without a complete description or example of intended use.
As a result, it has not seen any practical use to date that matches As a result, it has not seen any practical use to date that matches
its intended purpose. These added details are provided to guide its intended purpose. These added details are provided to guide
implementers toward proper use. implementers toward proper use.
2.5. Properties 2.5. Authentication Identifier Field
While the "ptype" names the general area from which some data of
interest were extracted to perform authentication, the associated
"property" is more specific. Its meaning, however, can also vary
slightly depeneding on which authentication method's result is being
reported.
Generally, the properties are defined as follows:
header: Indicates from which header field the value being evaluated
was extracted.
body: Indicates where in the message body a value being evaluated
can be found (e.g., a specific offset into the message or a
reference to a MIME part).
policy: Indicates the local name of the policy that caused this
header field to be added (see Section 2.4).
smtp: Indicates which [SMTP] command provided the value that was
evaluated by the authentication scheme being applied.
Entries in the "Email Authentication Methods" registry can define
properties that deviate from these definitions when appropriate. For
example, when reporting the result of a [DKIM] evaluation, it would
be redundant to report the name of the header field from which
details were extracted. Thus, instead, DKIM results use the "header"
property to name the signature tag from which a detail of interest
was extracted.
2.6. Authentication Identifier Field
Every Authentication-Results header field has an authentication Every Authentication-Results header field has an authentication
service identifier field (authserv-id above). Specifically, this is service identifier field (authserv-id above). Specifically, this is
any string intended to identify the authentication service within the any string intended to identify the authentication service within the
ADMD that conducted authentication checks on the message. This ADMD that conducted authentication checks on the message. This
identifier is intended to be machine-readable and not necessarily identifier is intended to be machine-readable and not necessarily
meaningful to users. meaningful to users.
Since agents consuming this field will use this identifier to Since agents consuming this field will use this identifier to
determine whether its contents are of interest (and are safe to use), determine whether its contents are of interest (and are safe to use),
skipping to change at page 15, line 34 skipping to change at page 15, line 23
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
only the current identifier(s) in use but previous ones as well to only the current identifier(s) in use but previous ones as well to
account for delivery latency or later re-assessment of the header account for delivery latency or later re-assessment of the header
field's contents. 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.7. Version Tokens 2.6. Version Tokens
The grammar above provides for the optional inclusion of versions on The grammar above provides for the optional inclusion of versions on
both the header field itself (attached to the authserv-id token) and both the header field itself (attached to the authserv-id token) and
on each of the methods being reported. The method version refers to on each of the methods being reported. The method version refers to
the method itself, which is specified in the documents describing the method itself, which is specified in the documents describing
those methods, while the authserv-id version refers to this document those methods, while the authserv-id version refers to this document
and thus the syntax of this header field. and thus the syntax of this header field.
The purpose of including these is to avoid misinterpretation of the The purpose of including these is to avoid misinterpretation of the
results. That is, if a parser finds a version after an authserv-id results. That is, if a parser finds a version after an authserv-id
skipping to change at page 16, line 8 skipping to change at page 15, line 45
trying to parse since what follows might not be in an expected trying to parse since what follows might not be in an expected
format. For a method version, the parser SHOULD ignore a method format. For a method version, the parser SHOULD ignore a method
result if the version is not supported in case the semantics of the result if the version is not supported in case the semantics of the
result have a different meaning than what is expected. For example, result have a different meaning than what is expected. For example,
if a hypothetical DKIM version 2 yielded a "pass" result for if a hypothetical DKIM version 2 yielded a "pass" result for
different reasons than version 1 does, a consumer of this field might different reasons than version 1 does, a consumer of this field might
not want to use the altered semantics. Allowing versions in the not want to use the altered semantics. Allowing versions in the
syntax is a way to indicate this and let the consumer of the header syntax is a way to indicate this and let the consumer of the header
field decide. field decide.
2.8. Defined Methods and Result Values 2.7. Defined Methods and 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 provide references to specific result values. The subsections below provide references to
the documents defining the authentication methods specifically the documents defining the authentication methods specifically
supported by this document, and their corresponding result values. supported by this document, and their corresponding result values.
Verifiers SHOULD use these values as described below. New methods Verifiers SHOULD use these values as described below. New methods
not specified in this document, but intended to be supported by the not specified in this document, but intended to be supported by the
header field defined here, MUST include a similar result table either header field defined here, MUST include a similar result table either
in their defining documents or in supplementary ones. in their defining documents or in supplementary ones.
2.8.1. DKIM and DomainKeys 2.7.1. DKIM and DomainKeys
DKIM is represented by the "dkim" method and is defined in [DKIM]. DKIM is represented by the "dkim" method and is defined in [DKIM].
DomainKeys is defined in [DOMAINKEYS] and is represented by the DomainKeys is defined in [DOMAINKEYS] and is represented by the
"domainkeys" method. "domainkeys" method.
A signature is "acceptable to the ADMD" if it passes local policy A signature is "acceptable to the ADMD" if it passes local policy
checks (or there are no specific local policy checks). For example, checks (or there are no specific local policy checks). For example,
an ADMD policy might require that the signature(s) on the message be an ADMD policy might require that the signature(s) on the message be
added using the DNS domain present in the From header field of the added using the DNS domain present in the From header field of the
message, thus making third-party signatures unacceptable even if they message, thus making third-party signatures unacceptable even if they
skipping to change at page 17, line 20 skipping to change at page 17, line 7
permerror: The message could not be verified due to some error that permerror: The message could not be verified due to some error that
is unrecoverable, such as a required header field being absent. A is unrecoverable, such as a required header field being absent. A
later attempt is unlikely to produce a final result. later attempt is unlikely to produce a final result.
[DKIM] advises that if a message fails verification, it is to be [DKIM] advises that if a message fails verification, it is to be
treated as an unsigned message. A report of "fail" here permits the treated as an unsigned message. A report of "fail" here permits the
receiver of the report to decide how to handle the failure. A report receiver of the report to decide how to handle the failure. A report
of "neutral" or "none" preempts that choice, ensuring the message of "neutral" or "none" preempts that choice, ensuring the message
will be treated as if it had not been signed. will be treated as if it had not been signed.
2.8.2. SPF and Sender ID 2.7.2. SPF and Sender ID
SPF and Sender ID use the "spf" and "sender-id" method names, SPF and Sender ID use the "spf" and "sender-id" method names,
respectively. The result values for SPF are defined in Section 2.6 respectively. The result values for SPF are defined in Section 2.6
of [SPF], and those definitions are included here by reference: of [SPF], and those definitions are included here by reference:
+-----------+--------------------------------+ +-----------+--------------------------------+
| Code | Meaning | | Code | Meaning |
+-----------+--------------------------------+ +-----------+--------------------------------+
| none | [RFC7208], Section 2.6.1 | | none | [RFC7208], Section 2.6.1 |
+-----------+--------------------------------+ +-----------+--------------------------------+
skipping to change at page 18, line 22 skipping to change at page 18, line 11
For example, "policy" might be used if SPF returns a "pass" result, For example, "policy" might be used if SPF returns a "pass" result,
but a local policy check matches the sending DNS domain to one found but a local policy check matches the sending DNS domain to one found
in an explicit list of unacceptable DNS domains (e.g., spammers). in an explicit list of unacceptable DNS domains (e.g., spammers).
If the retrieved sender policies used to evaluate SPF and Sender ID If the retrieved sender policies used to evaluate SPF and Sender ID
do not contain explicit provisions for authenticating the local-part do not contain explicit provisions for authenticating the local-part
(see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported
along with results for these mechanisms SHOULD NOT include the local- along with results for these mechanisms SHOULD NOT include the local-
part. part.
2.8.3. "iprev" 2.7.3. "iprev"
The result values used by the "iprev" method, defined in Section 3, The result values used by the "iprev" method, defined in Section 3,
are as follows: are as follows:
pass: The DNS evaluation succeeded, i.e., the "reverse" and pass: The DNS evaluation succeeded, i.e., the "reverse" and
"forward" lookup results were returned and were in agreement. "forward" lookup results were returned and were in agreement.
fail: The DNS evaluation failed. In particular, the "reverse" and fail: The DNS evaluation failed. In particular, the "reverse" and
"forward" lookups each produced results, but they were not in "forward" lookups each produced results, but they were not in
agreement, or the "forward" query completed but produced no agreement, or the "forward" query completed but produced no
skipping to change at page 19, line 8 skipping to change at page 18, line 46
completion of the evaluation. A later attempt is unlikely to completion of the evaluation. A later attempt is unlikely to
produce a final result. 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 "Domain Names - For discussion of the format of DNS replies, see "Domain Names -
Implementation and Specification" ([DNS]). Implementation and Specification" ([DNS]).
2.8.4. SMTP AUTH 2.7.4. SMTP AUTH
SMTP AUTH (defined in [AUTH]) is represented by the "auth" method, SMTP AUTH (defined in [AUTH]) is represented by the "auth" method,
and its result values are as follows: and its result values are as follows:
none: SMTP authentication was not attempted. none: SMTP authentication was not attempted.
pass: The SMTP client authenticated to the server reporting the pass: The SMTP client authenticated to the server reporting the
result using the protocol described in [AUTH]. result using the protocol described in [AUTH].
fail: The SMTP client attempted to authenticate to the server using fail: The SMTP client attempted to authenticate to the server using
skipping to change at page 19, line 39 skipping to change at page 19, line 31
permerror: The SMTP client attempted to authenticate using the permerror: The SMTP client attempted to authenticate using the
protocol described in [AUTH] but was not able to complete the protocol described in [AUTH] but was not able to complete the
attempt due to some error that is likely not transient in nature, attempt due to some error that is likely not transient in nature,
such as a permanent directory service lookup error. A later such as a permanent directory service lookup error. A later
attempt is not likely to produce a final result. attempt is not likely to produce a final result.
An agent making use of the data provided by this header field SHOULD An agent making use of the data provided by this header field SHOULD
consider "fail" and "temperror" to be synonymous in terms of message consider "fail" and "temperror" to be synonymous in terms of message
authentication, i.e., the client did not authenticate in either case. authentication, i.e., the client did not authenticate in either case.
2.8.5. Other Registered Codes 2.7.5. Other Registered Codes
Result codes were also registered in other RFCs for Vouch By Result codes were also registered in other RFCs for Vouch By
Reference (in [AR-VBR], represented by "vbr"), Authorized Third-Party Reference (in [AR-VBR], represented by "vbr"), Authorized Third-Party
Signatures (in [ATPS], represented by "dkim-atps"), and the DKIM- Signatures (in [ATPS], represented by "dkim-atps"), and the DKIM-
related Author Domain Signing Practices (in [ADSP], represented by related Author Domain Signing Practices (in [ADSP], represented by
"dkim-adsp"). "dkim-adsp").
2.8.6. Extension Methods 2.7.6. Extension Methods
Additional authentication method identifiers (extension methods) may Additional authentication method identifiers (extension methods) may
be defined in the future by later revisions or extensions to this be defined in the future by later revisions or extensions to this
specification. These method identifiers are registered with the specification. These method identifiers are registered with the
Internet Assigned Numbers Authority (IANA) and, preferably, published Internet Assigned Numbers Authority (IANA) and, preferably, published
in an RFC. See Section 6 for further details. in an RFC. See Section 6 for further details.
Extension methods can be defined for the following reasons: Extension methods can be defined for the following reasons:
1. To allow additional information from new authentication systems 1. To allow additional information from new authentication systems
skipping to change at page 20, line 36 skipping to change at page 20, line 28
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 (unknown) method header field that includes an experimental (unknown) method
identifier. identifier.
2.8.7. Extension Result Codes 2.7.7. Extension Result Codes
Additional result codes (extension results) might be defined in the Additional result codes (extension results) might be defined in the
future by later revisions or extensions to this specification. future by later revisions or extensions to this specification.
Result codes MUST be registered with the Internet Assigned Numbers Result codes MUST be registered with the Internet Assigned Numbers
Authority (IANA) and preferably published in an RFC. See Section 6 Authority (IANA) and preferably published in an RFC. See Section 6
for further details. for further details.
Experimental results MUST only be used within ADMDs that have Experimental results MUST only be used within ADMDs that have
explicitly consented to use them. These results and the parameters explicitly consented to use them. These results and the parameters
associated with them are not formally documented. Therefore, they associated with them are not formally documented. Therefore, they
skipping to change at page 22, line 21 skipping to change at page 22, line 16
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. The methods listed are an order-independent set; their available. The methods listed are an order-independent set; their
sequence does not indicate relative strength or importance of one sequence does not indicate relative strength or importance of one
method over another. Instead, the MUA or downstream filter consuming method over another. Instead, the MUA or downstream filter consuming
this header field is to interpret the result of each method based on this header field is to interpret the result of each method based on
its own knowledge of what that method evaluates. its own knowledge of 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 described in Section 2.8.6, IANA registry or an extension method as described in Section 2.7.6,
and each "result" MUST refer to a result code declared in the IANA and each "result" MUST refer to a result code declared in the IANA
registry or an extension result code as defined in Section 2.8.7. registry or an extension result code as defined in Section 2.7.7.
See Section 6 for further information about the registered methods See Section 6 for further information about the registered methods
and result codes. and result codes.
An MTA compliant with this specification adds this header field An MTA compliant with this specification adds this header field
(after performing one or more message authentication tests) to (after performing one or more message authentication tests) to
indicate which MTA or ADMD performed the test, which test got indicate which MTA or ADMD performed the test, which test got
applied, and what the result was. If an MTA applies more than one applied, and what the result was. If an MTA applies more than one
such test, it adds this header field either once per test or once such test, it adds this header field either once per test or once
indicating all of the results. An MTA MUST NOT add a result to an indicating all of the results. An MTA MUST NOT add a result to an
existing header field. existing header field.
skipping to change at page 24, line 43 skipping to change at page 24, line 37
such cases, the border MTA SHOULD issue an SMTP rejection response to such cases, the border MTA SHOULD issue an SMTP rejection response to
the message, rather than adding this header field and allowing the the message, rather than adding this header field and allowing the
message to proceed toward delivery. This is more desirable than message to proceed toward delivery. This is more desirable than
allowing the message to reach an internal host's MTA or spam filter, allowing the message to reach an internal host's MTA or spam filter,
thus possibly generating a local rejection such as a Delivery Status thus possibly generating a local rejection such as a Delivery Status
Notification (DSN) [DSN] to a forged originator. Such generated Notification (DSN) [DSN] to a forged originator. Such generated
rejections are colloquially known as "backscatter". 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.8). codes described in Section 2.7).
Such rejections at the SMTP protocol level are not possible if local Such rejections at the SMTP protocol level are not possible if local
policy is enforced at the MUA and not the MTA. policy is enforced at the MUA and not the MTA.
5. Removing Existing Header Fields 5. Removing Existing Header Fields
For security reasons, any MTA conforming to this specification MUST For security reasons, any MTA conforming to this specification MUST
delete any discovered instance of this header field that claims, by delete any discovered instance of this header field that claims, by
virtue of its authentication service identifier, to have been added virtue of its authentication service identifier, to have been added
within its trust boundary but that did not come directly from another within its trust boundary but that did not come directly from another
skipping to change at page 26, line 32 skipping to change at page 26, line 25
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [this RFC] Specification document(s): [this RFC]
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 Methods" Registry 6.2. "Email Authentication Methods" Registry
Names of message authentication methods supported by this Names of message authentication methods supported by this
specification are to 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.8.6. A registry was experimental names as described in Section 2.7.6. A registry was
created by [RFC5451] for this purpose. [RFC7001] amended ther rules created by [RFC5451] for this purpose. [RFC7001] amended ther rules
governing that registry, and also added a "version" field to the governing that registry, and also added a "version" field to the
registry. registry.
New entries are assigned only for values that have received Expert New entries are assigned only for values that have received Expert
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise request that a publication be referenced if a clear, concise
definition of the authentication method cannot be provided such that definition of the authentication method cannot be provided such that
interoperability is assured. Registrations should otherwise be interoperability is assured. Registrations should otherwise be
skipping to change at page 27, line 13 skipping to change at page 27, line 9
with each. with each.
All existing registry entries that reference [RFC7001] are to be All existing registry entries that reference [RFC7001] are to be
updated to reference this document, except where entries have already updated to reference this document, except where entries have already
been deprecated. been deprecated.
6.3. "Email Authentication Result Names" Registry 6.3. "Email Authentication Result Names" 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.8.7. A registry was experimental codes as described in Section 2.7.7. A registry was
created by [RFC5451] for this purpose. [RFC7001] updated the rules created by [RFC5451] for this purpose. [RFC7001] updated the rules
governing that registry. governing that registry.
New entries are assigned only for values that have received Expert New entries are assigned only for values that have received Expert
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise request that a publication be referenced if a clear, concise
definition of the authentication result cannot be provided such that definition of the authentication result cannot be provided such that
interoperability is assured. Registrations should otherwise be interoperability is assured. Registrations should otherwise be
permitted. The designated expert can also handle requests to mark permitted. The designated expert can also handle requests to mark
any current registration as "deprecated". any current registration as "deprecated".
All existing registry entries that reference [RFC7001] are to be All existing registry entries that reference [RFC7001] are to be
updated to reference this document. updated to reference this document.
The definitions for the SPF and Sender ID authentication methods are The definitions for the SPF and Sender ID authentication methods are
updated using the references found in Section 2.8.2. updated using the references found in Section 2.7.2.
7. Security Considerations 7. Security Considerations
The following security considerations apply when adding or processing The following security considerations apply when adding or processing
the Authentication-Results header field: the Authentication-Results header field:
7.1. Forged Header Fields 7.1. Forged Header Fields
An MUA or filter that accesses a mailbox whose messages are handled An MUA or filter that accesses a mailbox whose messages are handled
by a non-conformant MTA, and understands Authentication-Results by a non-conformant MTA, and understands Authentication-Results
skipping to change at page 44, line 13 skipping to change at page 44, line 13
o Add "To-Do" section. o Add "To-Do" section.
E.2. -00 to -01 E.2. -00 to -01
o Apply RFC7410. o Apply RFC7410.
o Update all the RFC4408 references to RFC7208. o Update all the RFC4408 references to RFC7208.
o Add section explaining "property" values. (Errata #4201) o Add section explaining "property" values. (Errata #4201)
o Remove "To-Do" section.
E.3. -01 to -02
o Consolidate new sections.
Author's Address Author's Address
Murray S. Kucherawy Murray S. Kucherawy
270 Upland Drive 270 Upland Drive
San Francisco, CA 94127 San Francisco, CA 94127
US US
EMail: superuser@gmail.com EMail: superuser@gmail.com
 End of changes. 36 change blocks. 
82 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/