Re: Guidance for spam-control on IETF mailing lists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Joe Touch: Sat, Mar 16, 2002 at 11:21:28AM -0800]
> >Someone with N addresses they'd like to post from simply subscribes to
> >the list from all of them and sets the disable delivery flag on N-1 of
> >them. Mailman seems to define temporary as "until I unset this attribute".
> >
> >No admin intervention required.
>
> Yes. But lots of user intervention required.
>
> Lists for open discussion should require such hoops for participation,
> esp. when there are plenty of reasonable, sufficiently correlated
> identifiers than "not a list member" to identify spam.

Actually I think whitelists, even self-service whitelists, are much
more effective than blacklists. And if I'm going to read a list, I'd
much rather it be well run than just easy to post to. I define well
run as _both_ spam-free and lacking in moderation delays. I'm willing
to go through a little hassle to keep the system running
well. Sometimes the integrity of the system is simply more important
than my personal convenience.

I think you're defining the calculus of list policy wholly in terms of
the poster and not at all in terms of the large numbers of readers.

blacklists always drift over time. They require an astonishing amount
of energy to keep current - otherwise their rates of both false
positives and negatives keep inching up.

The e2e-interest blacklist is new. It appears to be a reaction to the
embarrassing amount of spam that that list has redistributed over the
last couple of years. Clearly, the brand new system is not a useful
datapoint yet, but the totally unregulated nature of the list whose
results dictated the need for the new policy is a strong indictment
against pure open lists in the current climate.

At some point a legitimate submission will be snagged as a false
positive by that system. The submitter is powerless to correct
it. Given a system where the "also-post-from" list is under the
sender's control (as was just illustrated with mailman) the user can
take initiative and fix the problem.

And false positives will happen. A recent ha-ha example from one of
the linux development lists was discussion regarding the SCSI driver
for the aic7700 series of chips. That driver is known (for obvious
reasons) as the aic7XXX driver. Someone's nanny software flagged those
messages as porn ads.

To me, the obvious corollary to approved whitelists are phone/internet
credit card purchases. Most vendors will only ship to approved
addresses. Generally this is your billing address. However, if you
call most credit card companies they will add additional "approved to
ship to" (aka post only) addresses to your card. As a credit card user
this doesn't strike me as particularly onerous to help maintain the
integrity (and ultimately the utility) of the system.

If a list bounces my crosspost, but also gives me an option to
"confirm you're a person not a program even if you don't want to
receive copies of list traffic" I think that's a perfectly reasonable
thing to ask before echoing my (deep and profound) thoughts to a
couple thousand other people. Plus, becaause its user and not
administrative driven, it scales well.

-Patrick



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux