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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html