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