--On 4 May 2010 16:09:28 +0000 John Levine <johnl(_at_)iecc(_dot_)com> wrote:
I agree it's hypothetically possible, but have you ever seen an actual
need for this in practice, a list where the recipients filter out
messages that a more competently managed list would have rejected?
I've seen spam posted to mailing lists. Recently, I've seen lists
targetted in more intelligent ways by spammers. For example, by using
sender addresses in the domain of the list (quite a useful way of
attacking academic lists, which tend to have lots of local users, but
some non-local).
I believe it. Are you saying the list managers make no effort to keep
the spam out of their lists?
No, but I don't think it's their job. As the site manager, that's my job in
general. What the list managers can add is access controls, and
authentication helps to improve the utility of such controls.
Remember that every change to list
software that might be useful to let recipients identify spam that
leaks through a list could be used to keep the spam from leaking in
the first place. Why go to extra effort to push the work out to the
subscribers?
I'm not advocating extra effort to push the work out. I am advocating
leaving in place information that recipients may (or may not) wish to use.
Also, re your other discussion about list authentication, you're
right, we don't know what authentication lists do on their
contributors, but DKIM doesn't help there since DKIM most definitely
never says that the From: address is "real".
"real"? A signature from the sender domain at least says that if it's not
real, that's the responsibility of the sender domain owner, doesn't it?
Then reputation services come into play. Which is where the answer to your
first question comes in - the end recipient may have a very different view
of the reputation of the sender than does the list. Or, it may wish to use
the message content to modify its reputation score for the sender.
If you want strong
sender authentication, we already have S/MIME, and I wouldn't be
surprised if there were list software that could use it.
R's,
John
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html