Re: [apps-discuss] Registering email status codes for authentication failures

[Barry Leiba <[e-mail]>]

On Wed, May 7, 2014 at 5:32 PM, Murray S. Kucherawy <[e-mail]> wrote:
> A while ago I did this short draft:
>
> https://datatracker.ietf.org/doc/draft-kucherawy-email-auth-codes/
>
> ...and then promptly forgot about it.  Given that email authentication is
> front-and-center these days, is it worth updating it and then pushing it
> through?  Given its size, does anyone have thoughts about processing it
> through APPSAWG?

Murray asked me about this separately, after posting it here.  As I
was a bit behind on following this list, I didn't know he'd started a
discussion here until I'm catching up now.

Apart from a few editorial things, here's what I said to Murray.
Some, but not all of this has been discussed here already, so add this
as strong support for addressing it:

On a broader level, keep in mind that 6376 says this (Section 6.3):

   In general, modules that consume DKIM verification output SHOULD NOT
   determine message acceptability based solely on a lack of any
   signature or on an unverifiable signature; such rejection would cause
   severe interoperability problems.

and this (Section 6.3):

   If the email cannot be verified, then it SHOULD be treated the same
   as all unverified email, regardless of whether or not it looks like
   it was signed.

The two DKIM codes seem to encourage, or at least support, violation
of both of these.

Further, what code do I return if I check both SPF and DKIM, and both
checks fail?  Does it really make sense to have these as three
different extended codes?  Or might it makes sense to have one code
that says "sender verification failed," with a description that says
that no sender verification mechanism succeeded, and policy requires
successful verification?  It might then go on to explain that the
requirement could come from local policy or from some communication of
sender policy to the receiving domain.

This point's a complicated one, and I'm happy if you don't address it
now, and we address it on the mailing list.

Barry, Applications AD