Steve Atkins wrote: > > On Jan 24, 2006, at 5:18 PM, Jim Fenton wrote: > >> Mark Delany wrote: >>> >>> Actually I'm not sure why a list has to do anything in this case. If a >>> failed signature is the same as no signature, then the very action of >>> a mutating list has the effect of "stripping out" any existing sig. So >>> why impose extra work on a list? And why not let the natural course of >>> existing lists serendipitously "do the right thing"? >>> >> This makes sense to me. The main reason I can think of for removing a >> previous signature is the effort involved in trying to verify it. But >> that's just an optimization. > > It's, ah, not unlikely that at least some recipient MTAs will consider an > invalid DKIM signature as evidence that the email is spam, a virus or > mind control cooties from the little orange martians. That's likely to > reduce deliverability for messages with invalid signatures, or anything > that even looks vaguely like them. This goes back to the topic of how much we need to accommodate verifiers that interpret things wrong. Messages will be signed in order to increase their deliverability. If verifiers behave in this way, people will be reluctant to sign messages at all because there will be a possibility that the signature will impede deliverability in the event that something enroute (e.g., SpamAssassin with certain settings) "breaks" the signature. > > So... regardless of what is decided here I expect some MLMs will > strip out incoming signatures, if doing so will increase their > deliverability > even marginally. That doesn't mean you should mandate doing so, > of course, but don't assume that remailers of various types won't do > so either. I would much rather put whatever language is necessary in the specifications and/or overview document to guide implementers to interpret signatures, and in particular broken ones, appropriately.
Besides, everyone knows Martians are green, not orange. http://www.imdb.com/title/tt0058548/ -Jim _______________________________________________ ietf-dkim mailing list http://dkim.org
