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

Re: Anti-spam recommendations



On Wed, 04 Feb 2015 18:00:03 +0000
Mark Carroll <mtbc@ixod.org> wrote:

> I'm moving a Debian mail server installation over to a different
> machine environment and I figure that I may as well take the
> opportunity for a fresh install and rethink. I've been using
> greylistd to good effect, but I'd be surprised if it keeps working so
> well long-term. I have long lists of aliases in Exim and perhaps more
> automated use of throwaway addresses could have value; I haven't
> really thought that through.
> 
> What are people expecting will work well in the future for rejecting
> spam at the MTA? E.g., SpamAssassin's performance, use of IP
> blacklists, etc. I can live with some spam, if I am fairly sure I'm
> not wrongly rejecting anything. I'm happy to look at anything
> conveniently packaged for jessie.
> 

I'm getting about three a day past the server. The email address at the
top is genuine and has been used frequently on Usenet and the web for
nearly seventeen years, on the same fixed IP address. I'd have thought
that very few would be larger spam targets than I am.

My recent average spam rejections are about 100 a day, with peaks up to
400. There was a time years ago when there would be one to two thousand
rejections a day, with a record of over 12,000. So things seem to be a
bit quieter.

On the other hand, I look at some that get through, and a disturbing
percentage are from ISP address pools. The most important anti-spam
measure I use (after accepting email for the genuine recipients only,
which is vital) is to require complementary PTR-A DNS records for the
sending server, which pretty well eliminated home computers. Now, many
ISPs seem to be providing the complementary DNS pairs for their home
users, which is a shame.

I do also reject about twenty country codes in PTR or HELO, and a
hundred or so CIDR blocks. I request an ident from the sender, and
continue after a thirty-second timeout if one is not received. Any
genuine mail server will wait that long, but the spambots won't. A fair
number of senders disappear during the timeout, though the large
majority are also rejected for other reasons. If you wait until the
RCPT stage to reject a sender, as seems to be the general advice, more
than one other test is also performed and a single spam may be rejected
for two or three reasons.

I do a small amount of content filtering, but I've always thought that
to be risky and of poor accuracy. Anything with 'hinet' anywhere in the
headers, anything without a date, and a few other really obvious things
are all that I look for. Some years ago I took part in the great
Spamassassin arms race for a while, but decided that trying to keep
adding new rules as the spam evolved was a waste of time. There has
recently been a storm of emails with no kind of spam payload at all,
but with quite large chunks of random text, and I assume that was some
sort of attempt at messing up Bayes filtering databases. I can't see
any other reason for it.

SPF exists, but so many people seem to do some kind of forwarding,
often from  work to home email addresses, that it seems to be more
trouble than it's worth. Demon started using it when they outsourced
their email (Demon is my ISP but I haven't used its email system for at
least 15 years) and a large number of their users complained, and they
had to allow opt-outs. I haven't made any attempts to use SPF.

-- 
Joe


Reply to: