I am not looking for unenforceable rules. I am looking for consistency and there is none. All this has to make sense before offering it to our SMTP customers.
Just consider what is a verifier or a "assessor" to do with that hard failure you got. Is this an indication of an preexisting signature? As it is, there is a recording of the failure and that AR may be input to another process logic. It has nothing to do with enforcement but rather consistency. It doesn't make sense to tell another layer "there is no signature", when in fact there was one, as recorded by the AR. As you can see, the AR can be used as input for some reputation service as well. So maybe there should be a consideration to clarify in this Errata what exactly the "Broken Signature to No Signature" really means from an implementation standpoint. Is that too much to ask? The mail I sent was a replay modification of a previous valid signature message sent right back to GMAIL. Only when I removed the DKIM-Signature header did it finally post it. -- hls On Sat, Feb 21, 2009 at 3:00 PM, John Levine <[email protected]> wrote: > > Well, according what I seen by the GMAIL verifier, it is discarding > > mail with invalid signatures. > > I sent a message to my gmail account with a broken signature, and > gmail noted the bad signature and delivered it just fine. Evidently > there's something else wrong with your mail. > > Authentication-Results: mx.google.com; spf=pass (google.com: domain of > [email protected] designates 208.31.42.53 as permitted > sender) [email protected]; dkim=hardfail header.i= > [email protected] > > Anyway, even if a large ISP were mishandling DKIM signatures, that > would be a reason to encourage the ISP to fix their DKIM processing, > not to change the spec. > > You've made it abundantly clear that you'd like lots of unenforceable > rules about who can do what to mail you send them. But that's not > what DKIM does, so please stop. > > R's, > John > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- hls
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
