draft-ietf-appsawg-rfc7001bis-06.txt   draft-ietf-appsawg-rfc7001bis-07.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft April 19, 2015 Internet-Draft April 21, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 21, 2015 Expires: October 23, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-06 draft-ietf-appsawg-rfc7001bis-07
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 October 21, 2015. This Internet-Draft will expire on October 23, 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 4, line 4 skipping to change at page 3, line 39
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 48 Authentication . . . . . . . . . . . . . . . . . . . 48
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 49 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 49
E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 49 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 49
E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 51 E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.7. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 51 E.7. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.8. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 51
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 19, line 51 skipping to change at page 19, line 51
of evaluation will always be possible. of evaluation will always be possible.
The result is reported using a ptype of "policy" (as this is not part The result is reported using a ptype of "policy" (as this is not part
of any established protocol) and a property of "iprev". of any established protocol) and a property of "iprev".
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.7.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: 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
the protocol described in [AUTH] but was not successful, yet the protocol described in [AUTH] but was not successful (such as
continued to send the message about which a result is being providing a valid identity but an incorrect password).
reported.
temperror: The SMTP client attempted to authenticate using the temperror: 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 transient in nature, such attempt due to some error that is likely transient in nature, such
as a temporary directory service lookup error. A later attempt as a temporary directory service lookup error. A later attempt
may produce a final result. may produce a final result.
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,
skipping to change at page 20, line 47 skipping to change at page 20, line 46
consider this command issued by a client that has completed session consider this command issued by a client that has completed session
authentication with the AUTH command resulting in an authorized authentication with the AUTH command resulting in an authorized
identity of "client@c.example": identity of "client@c.example":
MAIL FROM:<alice@a.example> AUTH=<bob@b.example> MAIL FROM:<alice@a.example> AUTH=<bob@b.example>
This could result in a resinfo construction like so: This could result in a resinfo construction like so:
; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example ; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example
An agent making use of the data provided by this header field SHOULD Note that in all cases other than "pass", the message was sent by an
consider "fail" and "temperror" to be synonymous in terms of message unauthenticated client. All non-"pass" cases SHOULD thus be treated
authentication, i.e., the client did not authenticate in either case. as equivalent with respect to this method.
2.7.5. Other Registered Codes 2.7.5. Other Registered Codes
Result codes were also registered in other RFCs as follows: Result codes were also registered in other RFCs as follows:
o Vouch By Reference (in [AR-VBR], represented by "vbr"); o Vouch By Reference (in [AR-VBR], represented by "vbr");
o Authorized Third-Party Signatures (in [ATPS], represented by o Authorized Third-Party Signatures (in [ATPS], represented by
"dkim-atps"); "dkim-atps");
skipping to change at page 29, line 42 skipping to change at page 29, line 42
reference shall be removed from the description. reference shall be removed from the description.
3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf" 3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf"
method entries shall have their "Defined" fields changed to this method entries shall have their "Defined" fields changed to this
document. document.
4. All "smime" entries have their "Defined" fields changed to 4. All "smime" entries have their "Defined" fields changed to
[SMIME-REG]. [SMIME-REG].
5. The "value" field of the "smime" entry using property "smime- 5. The "value" field of the "smime" entry using property "smime-
part" shall be changed to read "The MIME body part reference that part" shall be changed to read: "The MIME body part reference
contains the S/MIME signature." The redundant reference is thus that contains the S/MIME signature. See Section 3.2.1 of RFC7281
removed. for full syntax."
6. The following entry is to be added: 6. The following entry is to be added:
Method: auth Method: auth
Defined: [this document] Defined: [this document]
ptype: smtp ptype: smtp
property: auth property: auth
skipping to change at page 52, line 5 skipping to change at page 51, line 46
o Mention that when a local-part is removed, the "@" goes with it. o Mention that when a local-part is removed, the "@" goes with it.
o Refer to RFC7328 in the "iprev" definition. o Refer to RFC7328 in the "iprev" definition.
o Correction to "smime-part" prose. o Correction to "smime-part" prose.
o Examples that use SMTP AUTH now claim "with ESMTPA" in the o Examples that use SMTP AUTH now claim "with ESMTPA" in the
Received fields. Received fields.
E.8. -06 to -07
o Wording around the S/MIME results.
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. 10 change blocks. 
15 lines changed or deleted 19 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/