On Fri, 14 Mar 2008, Frank Ellermann wrote:
[...]
Unrelated, I just reviewed sender-auth-header-13, could the
DKIM experts here please also check it, especially section
2.4.1 ? AFAIK some wannabe-DKIM results in 2.4.1 are wrong:
There is no "policy" result in DKIM, or if it makes sense it
could be also used elesewhere. There is no "fail" and no
"neutral" in DKIM, both are by definition the same as "none"
(unsigned).
The draft also covers Domainkeys, please check if all as it
should be for DKIM vs. Domainkeys. Are "policy", "neutral",
and "fail" in section 2.4.1 results needed for Domainkeys ?
I'm the author sender-auth-header and as an early adopter of DKIM
I think I also qualify as a DKIM expert.
DKIM itself doesn't have a "policy" result, but that doesn't mean a filter
or MTA is forbidden from deciding things like "although this message is
signed, I don't like the signature so I'm going to discount its value".
Examples include one large ISP that wishes to favour author signatures
over third-party (e.g. mailing list) signatures, or a receiver who, upon
seeing an "l=" tag used, asserts that at least x% of the message must
be signed or it's not to be trusted.
There are real-world implementations that already do these things, so
there's a need to be able to relay that fact downstream.
Likewise, there are verifiers that want to make a distinction between a
message that was not signed (and, perhaps, should have been according to
ASP) and one that bore a signature that did not pass verification.
The very same scenarios, except for "l=" (since it didn't have that),
apply to DomainKeys.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html