Subject: Re: [ietf-dkim] sender-auth-header

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Mar 2008 11:59:23 -0700 (PDT)

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 18 Mar 2008 09:33:28 +0100

Murray S. Kucherawy wrote:
 
> 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".

Yes, and I have no problem with this.  Likewise receivers are
free to use what is known as "best guess" in SPF (a/24 mx/24),
or similar tricks like mapping NEUTRAL to SOFTFAIL depending
on the domain.  

Your draft does not permit to confuse best guesses and tricks
with genuine results for other techniques, that is good.  For
DKIM + DK I pointed it out, it is up to you (collective you)
what to do.  If you think it is okay to note receiver "policy"
as DKIM or DK go for it.  

Admittedly it makes me nervous to see *seven* DKIM results in
2.4.1, and *nine* ADSP results in 2.4.2.  I hoped that *six*
SPF results are an all-time record in missing KISS.  <sigh />

 Frank