Email Authentication Status Codes
draft-ietf-appsawg-email-auth-codes-07

[Ballot comment]

- Since only one code is returned and since the client has to
assume that other failures may have happened in parallel, and
since the X.7.20 code covers two different things (i.e. (a) and
(b) from 3.1), did the wg consider splitting out 3.1's (a) and
(b) into different codes?  That way the 3.1.a code would
conform to 6376 and the 3.1.b code would be "failed my local
DKIM specifics." Seems to me that splitting those out might be
better but I'm fine if this was considered and rejected (i.e.
no need to re-do the reason for rejecting, just tell me it
happened and that'll be fine).

- The intro could make the X.7.nn notation clearer, but it
becomes blatently obvious if one reads 5248 so its ok unless
you want to be extra-nice to the reader.

[Ballot discuss]
We might be able to clear this up with an explanation rather than a change of the text, but I wanted to make sure:

I was comparing the descriptions in section 3.1 to the descriptions in RFC 7001 section 2.6.1 and I'm left a bit confused.

- When is X.7.20 expected to be returned? Would you use it for "none", "fail", "neutral", "temperror", "permerror", or more than one of those? The way it is worded, you could read it as saying this is only for the "neutral" case (i.e., the signature is there but not valid), but I could also see sending it back for "none". What was the intention?

- X.7.21 says it's for the author not matching case, but I would think that this should be generalized for *any* of the RFC 7001 "policy" cases. Do you really intend it only to be used for the particular policy case of no author match? If so, are we going to need other error codes later for other policy cases?

Perhaps this could be cleared up with some specific discussion of the 2.6.1 cases in regard to the use of these codes. But as-is, I'm not sure they are going to be used interoperably without further explanation.

[Ballot comment]
No objection to the publication of this document, but I have one comment that I would like considered.

It may be useful to provide an explicit link to the IANA registry being updated.  That could easily be done by including http://www.iana.org/assignments/smtp-enhanced-status-codes in the IANA Considerations section.  It would also be clearer of section 6 referred to the SMTP Enumerated Status Codes registry rather than the SMTP Enhanced Status Code Registry.

[Ballot comment]
I have no objeciton to the publication of this document.

Here are two small editorial points you may want to consider.

---

Whenever I see an Abstract like this one (and the corresponding
paragraph in the Introduction) I wonder how it will read as an RFC
rather than as an Internet-Draft. 

As part of an I-D it is fine to say "there is at present..."
but in five years time, when you read the RFC it will seem really odd.

Why not go for the more simple statement...

  This document registers code points to allow status codes to be
  returned to an email client to indicate that a message is being
  rejected of deferred specifically because of email authentication
  failures.

---

I would prefer that the Abstract also indicated how this document
updates RFC 7208. Thus...

  This document updates RFC 7208 to register code points to allow
  status codes to be returned to an email client to indicate that a
  message is being rejected of deferred specifically because of email
  authentication failures.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-email-auth-codes-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has a question about this one.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Enumerated Status Codes subregistry of the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry located at:

http://www.iana.org/assignments/smtp-enhanced-status-codes/

the following six Sub-Codes are to be added:

Code: X.7.20
Sample Text: No valid DKIM signature found
Associated basic status code: 550
Description: This status code is returned when a message
did not contain a valid DKIM signature,
contrary to local policy requirements.
(Note that this violates the advice of
Section 6.1 of RFC6376.)
Reference: [ RFC-to-be ]; RFC6376
Submitter: M. Kucherawy
Change controller: IESG

Code: X.7.21
Sample Text: No valid author-matched DKIM signature found
Associated basic status code: 550
Description: This status code is returned when a message
did not contain a valid DKIM signature
whose identifier(s) match the author
address(es) found in the From header field,
contrary to local policy requirements. (Note
that this violates the advice of Section 6.1
of RFC6376.)
Reference: [ RFC-to-be ]; RFC6376
Submitter: M. Kucherawy
Change controller: IESG

Code: X.7.22
Sample Text: SPF validation failed
Associated basic status code: 550
Description: This status code is returned when a message
completed an SPF check that produced a
"fail" result, contrary to local policy
requirements. Used in place of 5.7.1 as
described in Section 8.4 of RFC7208.
Reference: [ RFC-to-be ]; RFC7208
Submitter: M. Kucherawy
Change controller: IESG

Code: X.7.23
Sample Text: SPF validation error
Associated basic status code: 451/550
Description: This status code is returned when evaluation
of SPF relative to an arriving message
resulted in an error. Used in place of
4.4.3 or 5.5.2 as described in Sections
8.6 and 8.7 of RFC7208.
Reference: [ RFC-to-be ]; RFC7208
Submitter: M. Kucherawy
Change controller: IESG

Code: X.7.24
Sample Text: Reverse DNS validation failed
Associated basic status code: 550
Description: This status code is returned when an SMTP
client's IP address failed a reverse DNS
validation check, contrary to local policy
requirements.
Reference: [ RFC-to-be ]; Section 3 of RFC7001
Submitter: M. Kucherawy
Change controller: IESG

Code: X.7.25
Sample Text: Multiple authentication checks failed
Associated basic status code: 550
Description: This status code is returned when a message
failed more than one message authentication
check, contrary to local policy requirements.
The specific mechanisms that failed are not
specified.
Reference: [ RFC-to-be ]
Submitter: M. Kucherawy
Change controller: IESG

Question/Note: The Enumerated Status Codes subregistry is managed
via Specification Required.  IANA has submitted a management item
to get a designated expert (or experts).  The requested sub-codes
will be sent to the designated expert for review upon approval of
the management item. 

IANA understands that adding these six Sub-Codes is the only action
required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values.  We receive
requests constantly and the numbers may not be available.  However,
early allocation is available for some types of registrations. For
more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Email Authentication Status Codes) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Email Authentication Status Codes'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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
  because of email authentication failures.  This document registers
  codes for this purpose.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

  The document shepherd is S. Moonesamy.  The Responsible Area Director is
  Barry Leiba.

  draft-ietf-appsawg-email-auth-codes register Enhanced Status Codes for
  email authentication failures.  The intended status is Proposed Standard as
  the specification seeks to improve interoperability by allowing the SMTP
  server to provide more information to the SMTP client.

2. Review and Consensus
 
  The document was discussed by seven participants within the Applications
  Area Working Group and it has the consensus of the working group.  Most of
  issues raised were resolved.  An outstanding issue is the term
  "author-aligned".  It was agreed to resolve that during the Last Call.

  The significant issue was how to handle cases where multiple authentication
  checks failed.  Alexey Melnikov was not convinced about having an enhanced
  status code for that case, but in the end is okay with doing that as it provides more
  information.  There was agreement to assign an enhanced status code for such a
  case.

  There was some discussion about whether to register additional enhanced status
  codes for DMARC.  The working group agreed to handle that as part of the
  DMARC work.

  There was a very strong objection to including enhanced status codes for DKIM
  as it violates a recommendation in RFC 6376.  There was agreement to have text
  in this document to make it clear that is not recommended behaviour and
  it is a local policy decision, and this allayed the objections.

3. Intellectual Property

  There isn't any IPR disclosure referencing this document.  The author has
  confirmed that the document is in full conformance with BCP 78 and BCP 79.

4. Other points

  The document updates RFC 7208, as it registers a new enhanced status
  code for SPF.  There is an explanation for the update in the Introduction
  Section.

1. Summary

  The document shepherd is S. Moonesamy.  The Responsible Area Director is
  Barry Leiba.

  draft-ietf-appsawg-email-auth-codes register Enhanced Status Codes for
  email authentication failures.  The intended status is Proposed Standard as
  the specification seeks to improve interoperability by allowing the SMTP
  server to provide more information to the SMTP client.

2. Review and Consensus
 
  The document was discussed by seven participants within the Applications
  Area Working Group and it has the consensus of the working group.  Most of
  issues raised were resolved.  An outstanding issue is the term
  "author-aligned".  It was agreed to resolve that during the Last Call.

  The significant issue was how to handle cases where multiple authentication
  checks failed.  Alexey Melnikov was not convinced about have an enhanced status
  code for that case but it is okay with doing that as it provides more
  information.  There was agreement to assign an enhanced status code for such a
  case.

  There was some discussion about whether to register enhanced status codes for
  DMARC.  The working group agreed to handle that as part of a specification about
  DMARC.

  There was a very strong objection to including enhanced status codes for DKIM
  as it violates a recommendation in RFC 6376.  There was agreement to have text
  in this document to make it clear that is not recommended behaviour and
  it is a local policy decision.

3. Intellectual Property

  There isn't any IPR disclosure referencing this document.  The author has
  confirmed that the document is in full conformance with BCP 78 and BCP 79.

4. Other points

  The document updates RFC 7208 as it registers a new enhanced status
  code for SPF.  There is an explanation for the update in the Introduction
  Section.