Re: Using a spam-trap e-mail address with greylist

"Graham Miller" <[email protected]> Fri, 26 Jan 2007 13:15:05 +1100
Newsgroups gmane.mail.spam.greylist.user
Organization Graham Miller Computer Services
Message-ID <000b01c740ef$cdcc2ce0$6401010a@gmn800c60gb>
[email protected] wrote:
> I see your principal, but dont think it will go very far in reducing
> spam.  Blacklists dont work very well with spammers.  Sad fact is most
> spam is coming from zombie boxes whose owners dont know they are being
> used for spamming.  So your blacklist wouldnt block very much spam.

True, that individual blacklists do not block much spam, but a good RBL can
help remove plenty of spam. We use zen.spamhaus.org, list.dsbl.org, and
combined.njabl.org with great success. It knocked out about 50% of all spam
coming into our servers when we implemented it and still rejects a good
proportion (not measured) today. And we have had no false positives as far
as we know.

>  A
> spam filter like bogofilter or spamassassin that you 'train' by giving
> it spam and nonspam messages works much better.  However, even those
> dont do a perfect job in blocking spam.

And nothing will do a perfect job handling spam... No such animal. Harm
reduction is the best that can be achieved. And better to let some through
than block legitimate ones IMO.

>  I run bogofilter, and Im
> catching around 20000 emails a day with a better than 95% success
> rate.  Sometimes a message is put in the filter that isnt spam.

And what if the user does not ever know the message was not received... Say
an email from a potential customer who just gave up and did not do business
with you? Or someone sending an email to let you know of a problem on your
web site? Do your users see the emails in the filter?

IMHO, any antispam measure that scans the message body for characteristics
has a higher chance of blocking a real email than other measures. And it
constantly needs to learn or be upgraded. It's the same approach as virus
scanning.

The "known" spammers from RBLs that use honeypots, can be a good measure as
part of a chain of tests without using the processor power to scan every
message body (including de-encoding for mime multipart stuff).

From what I have seen of greylisting on our servers, until the spammers
adjust and learn to retry, it is having an enormous impact on the amount of
spam delivered to the server. And it lowers bandwidth use by stopping it
even before the subject is received (let alone the message body).

By using RBL checks before greylisting, we reject with a permanent error
based on the conservative RBLs which stops retries. Then greylisting knocks
out a big percentage. Following that, we check for valid domain, valid
recipient mailbox present, and a couple of small things, then queue for
delivery. We check for viruses and malware as it is delivered to the
mailbox.

This strategy has reduce my spam intake from about 400 per day to 10 per day
and our customers are reporting similar experiences. I can live with the
trickle that's left and it does not seem to reject any legitimate mail.

Of course, we can not be 100% sure of the "no false positive" statement
because there could be mail rejected that never gets reported to us. But we
have been using the RBLs for about 4 years now and not even a suspicion of a
lost email. But the RBL must be chosen wisely.

So would I bother with my own spam trap? Probably not.

Cheers
Graham