draft-ietf-appsawg-email-auth-codes-04.txt   draft-ietf-appsawg-email-auth-codes-05.txt 
Network Working Group M. Kucherawy Network Working Group M. Kucherawy
Internet-Draft July 8, 2014 Internet-Draft July 21, 2014
Updates: 7208 (if approved) Updates: 7208 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 9, 2015 Expires: January 22, 2015
Email Authentication Status Codes Email Authentication Status Codes
draft-ietf-appsawg-email-auth-codes-04 draft-ietf-appsawg-email-auth-codes-05
Abstract Abstract
There is at present no way to return a status code to an email client There is at present no way to return a status code to an email client
that indicates a message is being rejected or deferred specifically that indicates a message is being rejected or deferred specifically
because of email authentication failures. This document registers because of email authentication failures. This document registers
codes for this purpose. codes for this purpose.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 9, 2015. This Internet-Draft will expire on January 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 3, line 25 skipping to change at page 3, line 25
[RFC7001]. [RFC7001].
The current set of enhanced status codes does not include any code The current set of enhanced status codes does not include any code
for indicating that a message is being rejected or deferred due to for indicating that a message is being rejected or deferred due to
local policy reasons related to any of these mechanisms. This is local policy reasons related to any of these mechanisms. This is
potentially useful information to agents that need more than potentially useful information to agents that need more than
rudimentary handling information about the reason a message was rudimentary handling information about the reason a message was
rejected on receipt. This document introduces enhanced status codes rejected on receipt. This document introduces enhanced status codes
for reporting those cases to clients. for reporting those cases to clients.
This document updates [RFC7208] as new enhanced status codes relevant Section 3.2 updates [RFC7208], as new enhanced status codes relevant
to that specification are being registered. to that specification are being registered and recommended for use.
2. Key Words 2. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. New Enhanced Status Codes 3. New Enhanced Status Codes
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Associated basic status code: 550 Associated basic status code: 550
Description: This status code is returned when a message Description: This status code is returned when a message
did not contain a valid DKIM signature, did not contain a valid DKIM signature,
contrary to local policy requirements. contrary to local policy requirements.
(Note that this violates the advice of (Note that this violates the advice of
Section 6.1 of RFC6376.) Section 6.1 of RFC6376.)
Reference: [this document]; RFC6376 Reference: [this document]; RFC6376
Submitter: M. Kucherawy Submitter: M. Kucherawy
Change controller: IESG Change controller: IESG
Code: X.7.21 Code: X.7.21
Sample Text: No valid author-aligned DKIM signature found Sample Text: No valid author-matched DKIM signature found
Associated basic status code: 550 Associated basic status code: 550
Description: This status code is returned when a message Description: This status code is returned when a message
did not contain a valid DKIM signature did not contain a valid DKIM signature
whose identifier(s) match the address(es) whose identifier(s) match the author
found in the From header field, contrary to address(es) found in the From header field,
local policy requirements. (Note that this contrary to local policy requirements. (Note
violates the advice of Section 6.1 of that this violates the advice of Section 6.1
RFC6376.) of RFC6376.)
Reference: [this document]; RFC6376 Reference: [this document]; RFC6376
Submitter: M. Kucherawy Submitter: M. Kucherawy
Change controller: IESG Change controller: IESG
3.2. SPF Failure Codes 3.2. SPF Failure Codes
Code: X.7.22 Code: X.7.22
Sample Text: SPF validation failed Sample Text: SPF validation failed
Associated basic status code: 550 Associated basic status code: 550
Description: This status code is returned when a message Description: This status code is returned when a message
skipping to change at page 6, line 9 skipping to change at page 6, line 9
configurations that violate DKIM's recommendations, but rather configurations that violate DKIM's recommendations, but rather
acknowledges that they do exist and merely seeks to provide for acknowledges that they do exist and merely seeks to provide for
improved interoperability with such operators. improved interoperability with such operators.
A specific use case for these codes is mailing list software, which A specific use case for these codes is mailing list software, which
processes rejections in order to remove from the subscriber set those processes rejections in order to remove from the subscriber set those
addresses that are no longer valid. There is a need in that case to addresses that are no longer valid. There is a need in that case to
distinguish authentication failures versus indications that the distinguish authentication failures versus indications that the
recipient address is no longer valid. recipient address is no longer valid.
When multiple authentication methods fail, the SMTP server SHOULD use If a receiving server performs multiple authentication checks, and
the code that indicates multiple methods failed rather than only the more than one of them fails thus warranting rejection of the message,
first one that failed. It may be the case that one method is always the SMTP server SHOULD use the code that indicates multiple methods
expected to fail, and thus returning that method's specific code is failed rather than only reporting the first one that failed. It may
not information useful to the sending agent. be the case that one method is always expected to fail, and thus
returning that method's specific code is not information useful to
the sending agent.
The reverse IP DNS check is defined in Section 2.6.3 of [RFC7001]. The reverse IP DNS check is defined in Section 2.6.3 of [RFC7001].
Any message authentication or policy enforcement technologies
developed in the future should also include registration of their own
enhanced status codes so that this kind of specific reporting is
available to operators that wish to use them.
5. Security Considerations 5. Security Considerations
Use of these codes reveals local policy with respect to email Use of these codes reveals local policy with respect to email
authentication, which can be useful information to actors attempting authentication, which can be useful information to actors attempting
to deliver undesirable mail. It should be noted that there is no to deliver undesired mail. It should be noted that there is no
specific obligation to use these codes; if an operator wishes not to specific obligation to use these codes; if an operator wishes not to
reveal this aspect of local policy, it can continue using a generic reveal this aspect of local policy, it can continue using a generic
result code such as 5.7.7, 5.7.1, or even 5.7.0. result code such as 5.7.7, 5.7.1, or even 5.7.0.
6. IANA Considerations 6. IANA Considerations
Registration of new enhanced status codes, for addition to the SMTP Registration of new enhanced status codes, for addition to the SMTP
Enhanced Status Codes Registry, can be found in Section 3. Enhanced Status Codes Registry, can be found in Section 3.
7. Normative References 7. Normative References
skipping to change at page 7, line 8 skipping to change at page 7, line 15
[RFC7001] Kucherawy, M., "Message Header Field for Indicating [RFC7001] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7001, September 2013. Message Authentication Status", RFC 7001, September 2013.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
April 2014. April 2014.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Claudio Allocchio, Dave Crocker, Ned Freed, Arnt Gulbrandsen, Scott Claudio Allocchio, Dave Crocker, Ned Freed, Arnt Gulbrandsen, Scott
Kitterman, Barry Leiba, Alexey Melnikov, S. Moonesamy, and Hector Kitterman, Barry Leiba, Alexey Melnikov, S. Moonesamy, Hector Santos,
Santos contributed to this work. and Stephen Turnbull contributed to this work.
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
USA USA
EMail: superuser@gmail.com EMail: superuser@gmail.com
 End of changes. 11 change blocks. 
20 lines changed or deleted 27 lines changed or added

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