Subject: [apps-discuss] Review of: draft-ietf-appsawg-email-auth-codes-02

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Jun 2014 14:46:27 +0200

This is an independent review effort on the draft.

Review of:     Email Authentication Status Codes
I-D:           draft-ietf-appsawg-email-auth-codes-02

Reviewer:      D. Crocker
Review Date:   16 June 2014

Summary:

   As the draft says, it takes note of the established practice of
rejecting mail for some specific failures in authentication and seeks to
permit rejectors to tell sources about the reason(s) for the rejection.
 The purpose and style of the draft are straightforward.  It's usable in
its current form, though there are some tweaks or clarifications I've
suggested inline.

Detail:

> Abstract
> 
>    There is at present no way to return a status code to an email client
>    that indicates a message is being rejected or deferred specifically
>    because of email authentication failures.  This document registers
>    codes for this purpose.

Stray bit of curiosity:  There are a number of security-related reasons
a message could be rejected.  Is there any benefit in considered them as
a coherent set?  Is there any benefit in at least having the document
reference the larger set and then clarify what/why the current draft is
restricted.  (I did say 'stray'...)

> 1.  Introduction
> 
>    [RFC3463] introduced Enhanced Mail System Status Codes, and [RFC5248]
>    created an IANA registry for these.
> 
>    [RFC6376] and [RFC7208] introduced, respectively, DomainKeys
>    Identified Mail and Sender Policy Framework, two protocols for
>    conducting email authentication.  Another common email acceptance
>    test is the reverse Domain Name System check on an email client's IP
>    address, as described in Section 3 of [RFC7001].
> 
>    The current set of enhanced status codes does not include any code
>    for indicating that a message is being rejected or deferred due to
>    local policy reasons related to either of these two mechanisms.  This
>    is potentially useful information to agents that need more than
>    rudimentary handling information about the reason a message was
>    rejected on receipt.  This document introduces enhanced status codes
>    for reporting those cases to clients.

This is an oddly 'bottom-up' introduction to the purpose of the
document.  Not 'wrong', just odd, to me.

I'd have opened with something like a statement that email
authentication methods are a relatively recent addition to the handling
process and that it would helpful to be able to send information back to
authors/originators about authentication-related failures.  That would
at least set the stage for the detail the doc immediately dives into.
But then, I'm happier with top-down...

> 3.1.  DKIM Failure Codes
> 
> 
>       Code:               X.7.20
>       Sample Text:        No valid DKIM signature found
>       Associated basic status code:  5
>       Description:        This status code is returned when a message
>                           did not contain a valid DKIM signature,
>                           contrary to local policy requirements.
>                           (Note that this violates the advice of
>                           Section 6.1 of RFC6376.)
>       Reference:          [this document]; RFC6376
>       Submitter:          M. Kucherawy
>       Change controller:  IESG
>       Code:               X.7.21
>       Sample Text:        No valid author DKIM signature found

I suggest phrasing this as "No valid author-aligned DKIM signature, in
order to more strongly invoke the DMARC phrasing of things, since there
really isn't anything called an "author dkim signature'.

>       Associated basic status code:  5
>       Description:        This status code is returned when a message
>                           did not contain a valid DKIM signature
>                           matching the domain(s) found in the From
>                           header field, contrary to local policy
>                           requirements.  (Note that this violates the
>                           advice of Section 6.1 of RFC6376.)

However it conforms to the dmarc spec...

>       Reference:          [this document]; RFC6376
>       Submitter:          M. Kucherawy
>       Change controller:  IESG
> 
> 3.2.  SPF Failure Codes
> 
> 
>       Code:               X.7.22
>       Sample Text:        SPF validation failed
>       Associated basic status code:  5
>       Description:        This status code is returned when a message
>                           failed an SPF check, contrary to local
>                           policy requirements.
>       Reference:          [this document]; RFC7208
>       Submitter:          M. Kucherawy
>       Change controller:  IESG
> 
> 
>       Code:               X.7.23
>       Sample Text:        SPF validation error
>       Associated basic status code:  5
>       Description:        This status code is returned when evaluation
>                           of SPF relative to an arriving message
>                           resulted in an error.
>       Reference:          [this document]; RFC7208
>       Submitter:          M. Kucherawy
>       Change controller:  IESG

There should be text that makes clear when to do .22 and when to do .23.
 While yes I see some Description differences, it's not obvious to me
what the differences mean, in terms of when to apply one or the other.

> 4.  General Considerations
> 
>    By the nature of the Simple Mail Transfer Protocol (SMTP), only one
>    enhanced status code can be returned for a given exchange between
>    client and server.  However, an operator might decide to defer or
>    reject a message for a plurality of reasons.  Clients receiving these
>    codes need to consider that the failure reflected by one of these
>    status codes might not reflect the only reason, or the most important
>    reason, for non-acceptance of the message or command.
> 
>    It is important to note that Section 6.1 of [RFC6376] discourages
>    special treatment of messages bearing no valid signature.  There are
>    some operators that disregard this advice, a few of which go so far
>    as to require a valid Author Domain signature in order to accept the

'author domain signature' should be defined explicitly, since it's a key
construct.

Anyhow, there are operators that do this enforcement even without DMARC?????

>    message.  Moreover, some nascent technologies built atop SPF and DKIM
>    depend on such authentications.  This work does not endorse
>    configurations that violate DKIM's recommendations, but rather
>    acknowledges that they do exist and provides for improved

   and provides -> and merely seeks to provide

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Jun 2014 09:35:54 -0700

> restricted.  (I did say 'stray'...)

Yes, that's a possibility.  One idea was to have the third part of the
enhanced status code be a bit mask of the mechanism(s) whose evaluation
failed.  Consensus appears to be that this is a somewhat interesting idea
but there aren't enough cases to warrant doing so now.

> really isn't anything called an "author dkim signature'.

Sure.  However, this draft is deliberately independent of DMARC, because we
don't know how long that's going to take to make its way to
standardization.  Meanwhile, even if DMARC never sees the light of RFC-day,
these codes are already potentially useful.

> what the differences mean, in terms of when to apply one or the other.

OK.

> 'author domain signature' should be defined explicitly, since it's a key

OK.

There was a major revision done to dkim-filter (OpenDKIM's antecedent)
specifically to make this possible, at the request of a large email
operator.  I presume they're still applying that logic or some variant of
it.

>    and provides -> and merely seeks to provide

Done.  Thanks!

-MSK