On May 22, 2009, at 5:31 PM, John Levine wrote: >> Surely you do not suppose that a signature which covers only the >> From header (and that is a perfectly valis signature according to >> the document) is to be accepted as equally valuable to a signature >> that covers everything. > > Probably not, but that's because a dimwit who puts on cruddy > signatures is unlikely to earn a very good reputation. I really > REALLY do not plan to waste any time inventing heuristics to > evaluate the "quality" of a DKIM signature and I doubt anyone else > does, either. If you want people to accept your mail, be sure to > sign only good mail, and be sure to sign it in a way that bad guys > can't fake.
John, I would agree signatures currently should cover the message body, but this might also include the message body length. A properly structured message should not be prone to attack without the attack being rather obvious. When the body of the message has an open-ended length, the number of attempts to produce a collision might be within what now seems like a small number of attempts. With millions of computers under centralized control, the time required to defeat an open-ended DKIM body hash with a reasonable set of signatures might be fairly brief. For most of these systems, users might not even be aware of the role their computer play in the attack. Anyone that signs a fairly generic message, where users could think they are being cc'd with comments added in the phish, might prove fairly effective at creating victims. The ability to keep the message format from being messed up by what is likely to become a deluge of provider ads would also be a benefit. After all, this was one of the driving benefits being sought when developing DKIM. It seems that DKIM combined with RFC 5451 and the loss of the l= parameter, this benefit is likely lost as well. That would be a shame. It would also be a shame to have people still wondering who sent which part of a DKIM signed message. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
