[mail-vet-discuss] Authentication-Results: header draft 12 + 13

[Murray S. Kucherawy]

On Fri, 14 Mar 2008, Frank Ellermann wrote:
> Hi, in your latest drafts you define result values per
> specification.  The SPF + PRA "Neutral" description in
> 2.4.3 is wrong:
>
> | neutral:  The sender's domain has asserted that it
> | cannot or does not want to assert a policy record
> | suitable for evaluation of the authentication method.
>
> The (truncated) definition in RFC 4408 2.5.2 is:
>
> | The domain owner has explicitly stated that he cannot
> | or does not want to assert whether or not the IP
> | address is authorized.  A "Neutral" result MUST be
> | treated exactly like the "None" result; the distinction
> | exists only for informational purposes.
>
> You can't copy the MUSTard, maybe the following works:
>
> | The domain owner has explicitly stated that he cannot
> | or does not want to assert whether or not the IP
> | address is authorized.  A "Neutral" result has the
> | same meaning as the "None" result; the distinction
> | exists for informational purposes.
>
> You'd be better off with a pointer to the specification
> in this case, the details of the result codes are the
> result of long deliberations on the SPF discuss list.

My "neutral" is now (pardon the XML):

                                         <t hangText="neutral:"> The sender's
                                             domain has asserted that it
                                             cannot or does not want to assert
                                             whether or not the sending IP
                                             address is authorized to send
                                             mail on behalf of the sender's
                                             domain. </t>

...and I added this at the end of the list:

                                 <t> The distinction between and interpretation
                                     of "none" and "neutral" under these
                                     methods is discussed further in
                                     <xref target="SPF"/>. </t>

> Chapter 4.2 explains "hardfail" reject, but doesn't
> mention "fail" (for AUTH) and "discard" (for ASP).

Fixed.

> Apparently you want "hardfail" instead of "fail" in
> chapter 2.4.5 (AUTH).  Or IF NOT the end of 2.4.5 has
> to talk about s/hardfail/fail/.  Whatever the final
> name of "discard" will be, it should be also covered
> by chapter 4.2.

Fixed.

> For 2.4.1 I think there is no "fail" in (pure) DKIM,
> and also no "pass".  DKIM only offers "signed" or not,
> by definition DKIM FAIL is the same as unsigned, that
> ia AFAIK even stricter than SPF's NEUTRAL ~ NONE, but
> better check this with DKIM experts.

I think I qualify in that category.  :-)

In a number of places in RFC4871 section 6 (verifier actions), the 
algorithm has to return a PERMFAIL result while evaluating a signed 
message.  Authentication-Results relays that information.  The normative 
text of RFC4871 only says a bad signature SHOULD be treated as no 
signature, not MUST, so it's appropriate to reflect the difference here.

> AFAIK there is no "policy" result in DKIM.  Or rather
> if DKIM gets "policy" other methods could also use it,
> e.g., an SPF PASS from a known spammer.  But that is
> IMO another case for chapter 4.2, not a result defined
> in RFC 4871.

The latter is more appropriate.  However, it's not clear that an SMTP 
rejection is appropriate in those cases, so I'll use MAY to amend 4.2 as 
follows:

                         <t> The same MAY also be done for local policy
                             decisions overriding the results of the
                             authentication methods (e.g. the "policy" result
                             codes described in <xref target="policy"/>. </t>

> Likewise by definition "neutral" is "none" for DKIM,
> either there is a good signature or not, all details
> why there is no good signature are irrelevant.  Again,
> better check this with DKIM and Domainkeys experts.

I think I fit into those camps.  There are distinctions; an unsigned 
message is not necessarily the same to a verifier as one bearing a 
signature that appeared to be syntactically valid but the OpenSSL 
libraries returned a weird error code like "illegal padding".

> The interpretation of NXDOMAIN as PermError for the
> purposes of 'iprev' is not obvious.  Maybe add a note
> in 2.4.4 why 'iprev' has no "none" (?)

I've added:

                                 <t> There is no "none" for this method since
                                     any TCP connection delivering e-mail
                                     has an IP address associated with it,
                                     so some kind of evaluation will always
                                     be possible. </t>

I also changed "NXDOMAIN" to "NXDOMAIN or NODATA".

-MSK