Skip to main content

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

Yes

(Barry Leiba)
(Pete Resnick)
(Ted Lemon)

No Objection

(Alissa Cooper)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Spencer Dawkins)

Note: This ballot was opened for revision 05 and is now closed.

Barry Leiba Former IESG member
Yes
Yes (for -05) Unknown

                            
Pete Resnick Former IESG member
(was Discuss) Yes
Yes (for -06) Unknown

                            
Richard Barnes Former IESG member
Yes
Yes (2014-08-06 for -06) Unknown
As someone who has had to debug SPF-related mail failures, I approve this message.
Ted Lemon Former IESG member
Yes
Yes (for -06) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2014-08-04 for -05) Unknown
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.
Alissa Cooper Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2014-08-04 for -05) Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-08-06 for -06) Unknown
- 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.