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