On 18/01/2011 16:20, Martin Gregorie wrote:
I enabled Greylisting for a while. Unfortunately - I found that the MTAs my MTA communicated with responded in unreliable ways. Some MTAs would not try any of my MX records (all using the same Greylisting db) for at least a day, while others would retry within 30minutes. The Greylisting server might be good for busy servers once good systems have been remembered, but if you have a small amount of mail traffic and can cope with up to 24hour delays in your email then it's fine and effective.On Tue, 2011-01-18 at 09:00 -0500, Bowie Bailey wrote: If you're thinking of detecting spam at SMTP time you should consider greylisting. When my ISP implemented it the spam I get dropped immediately from 80% of my mail to 8%, where its remained ever since. After that you can take a view whether you want to:- scan the remaining mail at SMTP time (and reject spam as you originally described) - use SA as an MTA filter and let the recipient's MUA put it in a spam folder or bin depending on what the user decides. Or your MTA filter could silently bin spam or feed it to Bayes to be learned as spam. Your choice: you just can't reject it at this stage. - use a procmail recipe to scan mail and either reject spam or pass it to the recipient's MUA as above. Use this if you want the recipients to have some control over spam recognition, individual Bayes filters, etc.
I'm not prepared to wait 24 hours for mail servers to successfully send me mails - it's the equivalent of sealing my letterbox on Mondays, Wednesdays and Fridays for me, and I want near-real time email communication.
-- Best Regards, Giles Coochey NetSecSpec Ltd NL T-Systems Mobile: +31 681 265 086 NL Mobile: +31 626 508 131 GIB Mobile: +350 5401 6693 Email/MSN/Live Messenger: gi...@coochey.net Skype: gilescoochey
smime.p7s
Description: S/MIME Cryptographic Signature
