Re: list

[Richard Kettlewell <]

Paul Rattray writes:

> I'd hoped this list would be about measures to take to avoid or
> eliminate spamming, but all I've seen so far is debate about whether
> we can spoof this list.

We've seen several kinds of attacks here.  The simplest is of course
just individual addresses here being sent spam; it's irritating and
wastes time but doesn't actually prevent us from doing business for
more than the time it takes to hit `delete'.

More annoying is people trying to use our mail servers to `explode'
spam from one message with many recipients and steal our bandwidth,
cpu time, etc to do the hard work of the multiple deliveries.

Also annoying is the case where someone issues a spam (perhaps to many
undeliverable addresses, as well as to a great many real people who
will get irritated) with your own address as the return path (or in
one case random addresses @ our domain in the return path).

We modified our mail software to check a "deny file" which allows us
to accept or reject mail on the basis of sender address, recipient
address and the host we received the message from.  This all happens
at the SMTP level and on the "envelope" addresses only.

This isn't much of a win for the first case; although some spammers do
use consistent addresses which we can specifically block others use
random addresses which may not belong to them - or even exist at all -
making it pretty much impossible to defeat them with anything this
simple.  The "realtime blackhole list" is one possible better solution
here, I'll leave it to someone else to discuss that.

For the second case (relay hijacking) we can do much better though -
the "deny file" is constructed to allow anyone to send mail to our
customers, and to allow our customers to send mail to anyone, but to
allow no other mail through.  This is generated almost entirely
automatically.  This appears to work...

One obvious flaw is that a spammer could just forge the return address
to be that of one of our customers.  That'd be where the ability to
block particular hosts would come in - but someone would have to
notice and do something manually.

The third case, of people issuing spam not through us but with the
return path pointed at us, is much harder to combat.  We can't stop
the spam, as it never goes anywhere near us before being delivered to
thousands of recipients.  And when some of those recipients turn out
to be undeliverable, or sound off about the spam without checking the
headers to see if we actually had anything to do about it, you
suddenly have an awful lot of incoming mail.

The only solution we were able to come up with was to block the
targets of the bounces.  If these had been one particular address than
that'd have been equivalent to disabling that address for a period;
however the spam had been sent with <random string>@<domain> as the
return path so in fact we were able to solve the problem simply by
blocking everything but known legitimate addresses for that domain.

The postmaster/abuse complaints we just had to put up with.

In conclusion, we can use at least some defenses against most of the
problems we've seen so far; but it's not perfect and some attacks
still require human attention to deal with.

At home, I've been experimenting with a "whitelist": mail sent to my
published email addresses will have the sender checked against a
"whitelist" and if it doesn't match it will be bounced with
instructions on how to get on the whitelist (which are supposed to
require a human to interpret them).  There's another address which is
guaranteed to be delivered to me, bypassing the whitelist, but I only
tell my friends that one; I don't post to Usenet with it, for example.

The disadvantage is that this makes it much more work for someone to
email me, and I have to remember to set the From: line in my headers
to the the public or private address depending on how public the email
is.

(At the moment the software shouldn't bounce anything; it just tells
me what it would do.  I'm still building up the whitelist to include
friends who email me only rarely, mailing lists, etc.  It's currently
quite liberal, e.g. allowing all of ac.uk through..)

ttfn/rjk