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

["Murray S. Kucherawy" <[e-mail]>]

Hi Paul, thanks for the review.

On Fri, Aug 1, 2014 at 8:28 AM, Paul Wouters <[e-mail]> wrote:

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


I think the case of interest for both is what to do when something
malformed is discovered.  In that respect, the two communities operate a
little differently.  Specifically, if a malformed SPF record is found in
the DNS, the intent here is to reject the message with the newly-registered
error code rather than something less precise.  For DKIM, however, a
malformed signature or key record typically leads to the message being
delivered with an annotation (RFC7001, for example) that there was no valid
signature on the message, rather than rejecting it.

For rDNS, I suspect most MTAs use x.4.3 to report that condition, which is
already registered.

I imagine there's no harm in adding an error code for DKIM and maybe for
rDNS.  As the document already says, there's no compulsion to use them if
operators choose to continue using whatever they're using today.

-MSK