> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Ian Eiloart > Sent: Thursday, March 31, 2011 3:45 AM > To: Franck Martin > Cc: <ietf-dkim@mipassoc.org> > Subject: Re: [ietf-dkim] If DKIM would ignore [] at the beginning of > the subject line > > That's an implementation issue for verifiers, isn't it? If an rfc were > to say anything at all, it might say that mailing lists will often > break header signatures by prefixing the subject line. If a verifier > finds a [] prefix and broken signature, it might like to try verifying > a signature formed without that part of the subject line. It might also > want to limit the number of characters in the prefix. And, it might > like to keep a track of prefixes used with specific List-ID headers, to > spot attempts to abuse this flexibility.
There was pretty solid consensus against doing things like this in the past. There was similarly solid consensus against trying to verify a signature using the "z=" header fields if they're present. I believe we decided an implementation does so outside of DKIM's scope, and at its own peril; DKIM has to return a failure, but what you do after that is up to you. > I suppose some guidance as to what might be acceptable in the prefix > might be warranted. You could, for example, restrict it to substrings > of the (also signed) List-ID header. That would severely limit replay > attacks. That's also something we considered when talking to the Mailman people. But again, this is really a small percentage of what causes author signatures on list mail to break. > Anyway, the list should be signing messages after adding subject line > prefixes, and after adding body footers. It's the list's signature, and > the list's reputation that need to be assessed by the recipient. There > are many other modifications that a list might make (like stripping > attachments, body prefixes, and so on) that would make l= useless. I think the MLM document makes all of this stuff pretty clear already. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
