[Mailman-Developers] FYI -- mailback validations no longer safe?

[Landon Curt Noll]

> 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/\