On 23/Sep/10 21:16, John R. Levine wrote: > All of this emphasis on complex designs for MLMs strikes me as a waste > of time, since it's a tiny corner of the mail space that has not > historically been a vector for abuse, and shows no sign of becoming one. > > That's why my advice is that lists should sign their mail, which is > easy and at worst harmless, and we're done.
According to Murray's definition, MLMs include ESPs and email marketers, which originate a volume of traffic and have historically been a vector for abuse. Indeed, except for subscription mechanisms and deployed software, most of the problems are similar. Notwithstanding the informative discussion about the relationship between SDID and AUID, author domain signatures have a meaning that is independent of any assessors that may or may not be installed at the verifier's. A survived author domain signature is significant even if the author domain defines no ADSP record. The notion of a sender's signature would be useful, as a replay limitation, whenever messages are not delivered directly. Should we introduce that notion? By comparison with SPF, it would certify each hop along a message path, not just the last one --provided that signatures don't break. Besides courtesy forwarding and MLMs, this would also include outsourced backup MXes (an extinguishing species). In http://www.opendkim.org/stats/report.html the "Correlation of Received: count to signature successes" shows an optimum at 3 hops. IMHO those failure rates are an indication that message modifications occur beyond what DKIM had anticipated. I don't think a significant part of them are actual forgeries. Do we content ourselves with a product that is not reliable? Transferring messages responsibility (possibly removing broken signatures) and MIME-compliant canonicalizations (possibly providing for standardized modifications, like subject tags) are just two alternative, non mutually-exclusive strategies. Should we devise more of them, and state what strategies seem more promising? If you answer respectively "no, yes, no", I'm lost. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
