I think that there's an implicit level of trust that has to be honored in mailing list management. Even SASL-based SMTP authentication from ISPs isn't going to prevent throw-away accounts from being used. Until we can get a fingerprint or cornea scan (or even a driver's license) with each mailing list subscription and compare it against a master database (which I'm not advocating), you can't be 100% sure of the users.

For now I'd say that the best method is a social one; require references when people want to subscribe to your list. Ask them which lists they participate on, an example post from another list, etc. But ultimately it becomes a judgement call by the listowner either way.

I think Chris is right on target here. Judgement and non-automated checks are one good way of reducing the number of spammers.

For one list, I depend on the person telling me something or asking me something about topic. It all I get in a join request, I write back asking them if they really wanted to join the list and "BTW: which version of XXX are you using?" or "What would you like to see improved in XXX?" or "In what ways are you using XXX?" or something like that. Yea, I suppose a spammer could go through the effort to learn about XXX to get on the list ... that would be a lot of special work just to target a small list.

=-=

Processing requests by hand'' is important in order to use Judgement and non-automated checks''. Clearly this does not work for huge lists or where the list owner is too busy to process each and every request. An alternative to perform a ``credit check'' first:

*) Is the request from a recently created domain?
*) Did the DNS lookup of the IP address of the sender match the envelope?
*) Did the request come from an area flagged by the RBL, DUL, RSS or
   dorkslayers?
*) Did the request come from a known spam haven or place from which
   you had problem before?

None of these checks are perfect, but that is OK. The false negatives of things like the RSS are not a problem either. Anything that can pass all of the credit checks gets processed automatically. Anything else you process by hand'' using Judgement and non-automated checks''.

=-=

Prevention helps. Avoid placing your list or list-request address on the web (or on Usenet) in text form. Put your instructions / list information as text in the form of a jpg. So far spammers are not scanning jpg images for text and groking them ... I hope!

=-=

Do not use a single EMail address for the list. Make use of sub-domains. For example instead of:

XXX-list@foo.org

Use:

XXX-list@Jrandom-text.XXX.m.foo.org

where Jrandom-text' is different for each and every list member. Here Jrandom-text' is could be random collection of chars produced by your friendly neighborhood Lavarand server. :-)

Perform automated in-bound checks on EMail going into 'Jrandom-text.XXX.m.foo.org'. Use the 'credit checks' listed above. Look for the EMail being relayed thru the subscription address. Look for procmail-like spam triggers.

If the message passes the sanity check, allow it to go thru the system in an automated fashion. If a flag is raised, process it by hand.

When EMail it sent out to the list, send it out with each message being from XXX-list@Jrandom-text.XXX.m.foo.org style addresses.

All list users know (or care) is that they have / use / receive EMail from a single address. They need not know / or care that the single address is different from person to person.

Another advantage to the ``non-single EMail address for the list'' is that if an address becomes a problem, you can turn it off without impacting the entire list.

Say the user who is assigned 'XXX-list@table.XXX.m.foo.org' gets hit by a virus that spams their address book. Say this virus is able to duck under the ``credit checks''. Say despite all of your efforts the spam goes onto the list. Well you:

*) disable 'XXX-list@atlbe.XXX.m.foo.org'
*) apologize to the XXX-list

Later on if the member cleans up their mess, allow them to re-join by assigning them a new address: 'XXX-list@lztyg.XXX.m.foo.org'.

If people object to Jrandom-text, one can always use a randomly selected word-number combination.

chongo <> /\oo/\