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
