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
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