[secdir] Secdir review of draft-ietf-appsawg-email-auth-codes

[Paul Wouters <[e-mail]>]

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