Last Call Review of draft-ietf-appsawg-email-auth-codes-04
review-ietf-appsawg-email-auth-codes-04-secdir-lc-wouters-2014-08-07-00
| Request | Review of | draft-ietf-appsawg-email-auth-codes |
|---|---|---|
| Requested rev. | no specific revision (document currently at 07) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2014-08-05 | |
| Requested | 2014-07-17 | |
| Authors | Murray Kucherawy | |
| Draft last updated | 2014-08-07 | |
| Completed reviews |
Genart Last Call review of -04 by Peter Yee
(diff)
Genart Last Call review of -05 by Peter Yee (diff) Secdir Last Call review of -04 by Paul Wouters (diff) Opsdir Last Call review of -04 by Suzanne Woolf (diff) |
|
| Assignment | Reviewer | Paul Wouters |
| State | Completed | |
| Review | review-ietf-appsawg-email-auth-codes-04-secdir-lc-wouters-2014-08-07 | |
| Reviewed rev. | 04 (document currently at 07) | |
| Review result | Has Issues | |
| Review completed: | 2014-08-07 |
Review
review-ietf-appsawg-email-auth-codes-04-secdir-lc-wouters-2014-08-07
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document proposes to add additional entries to the "SMTP Enhanced Status Codes Registry", specifically related to DKIM, SPF and Reverse DNS checks, to assist operators and endusers in determining why their email message was rejected. The document looks good and has a proper security consideration section. I do have one question with respect to the temporary failure codes. For SPF Failure Codes, a distinction is made between an SPF validation failure (X.7.22) and an SPF validation error (X.7.23). A failure is the result of a successful (SPF) check method to mark the email message as failed. An error means the (SPF) method to check for failure did not run successfully and it could not determine whether the message should pass or fail. For example, an error in the (SPF) check could be due to a temporary DNS problem. For the DKIM and Reverse DNS, which like SPF depends on a working DNS resolver for the mail server, there is no such split made. These can only return failures, not errors in determining success or failure. If there is value in indicating this distinction for SPF, I would assume the same distinction would be useful for DKIM and Reverse DNS. If there are good reasons not to do this, perhaps it would be good to explain those reasons in the document along with some advise for implementors on what (existing) extended message code to return in the case of temporary DNS failures in the DKIM and Reverse DNS case. Paul