On Wed, Feb 27, 2008 at 11:19:56AM -0800, Michael Thomas
<mike(_at_)mtcc(_dot_)com> wrote:
Each [DKIM] or [DOMAINKEYS] signature present that is evaluated
produce the following dkim-method or domainkeys-method result values:
[mat: i've removed the "acceptable" parts... i'm not sure what that's
bringing to the table... why should auth res go into the filter's
domain? same goes for other methods, I suspect]
none: No valid signatures were found. [mat: is this needed?? i just
use the ssp result here]
There's a useful distinction to be made between a missing signature on
a domain that does assert some sort of sign-all policy (dkim=all,
o=-, etc.) and one that does not. "none" definitely does not fall into
that category, although SSP/etc. results would.
pass: The signature passed verification.
fail: The message was signed and the signature but it failed the
verification test.
Continuing the thought from above, one could argue that a missing
signature + a sign-all policy = a fail.
It also seems to me, at least, that some way of communicating whether
the broken signature came from a domain or selector in testing mode is
pretty helpful in determining just how strongly any downstream filters
should respond to the failure.
To me, this all argues for maintaining a distinction between softfail
and hardfail, and maybe even neutral.
[mat: i nuked neutral and permerror... how are they different from fail?
less is better here, I think]
temperror: The message could not be verified due to some error which
is likely transient in nature, such as a temporary inability to
retrieve a [DKIM] selector resource record. A later attempt may
produce
a final result.
--
Mike Markley <mike(_at_)markley(_dot_)org>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html