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