Rainer Zocholl said... > An other trick is "gray listing": > If there is a new "mail from:" adresse, reject the email with a > "450 Please try again later. See http:\\info for the reason > of the delay." > > Viruses don't run a mail quue and will never try again. > Spamers thombies don't run mail quues too (but may > simply resent the email. That's why serveral spam mail will > be seen twice. ).
This is a limited-time trick - if it isn't already beat down, it will soon be. I'm already seeing multiple attempts to relay in my postfix logs from single IP addresses, and the attempts are from obviously infected computers. > The simplest, cheapes and very secure attempt: > Remove every directly executable attachment. > I know nobody who sends executables as attachment, only worms do. > Place the attachments into quantain and give it out only if the > user asks for. After virus scanning it. Nice when you can do it, and to a large degree we do here, but not all environments can make that policy decision. > Yes, and how will you manage the problem to be able to reject > emails to unknown users? > I assume your 0,5Mio box accepted every email it got offered, > the virus scanns it and then(!) generate a bounce because > the "mail to:" account is unkown after all that... > That's a very bad but common practise. So it's easier to > sell bigger machines... > Too those bounces -to totally innocent receipients- distributes the > address to more and more (maybe infected) PC, generating more > worm mails... > making it easier to sell bigger machines and showing how important > the virus scanning has become... > > Simply "reject unknown" is only a fast database lookup. > After that not further actions are required. > Most worm mails are addressed to unknown users. Yep - the MTA should reject messages to unknown recipients. > On the first degree (after apply the simlpe roles above) > i would recommend "dspam", NOT a virus scanner. > dspam is "just" a database and "learning" would is "spam" and > what is not. As a side effect it protects against viruses as > viruses may lead to the same "repetitive signature". I have no experience with dspam, but SpamAssassin rocks. If you turn off bayesian learning, and turn on the SURBL stuff, you'll be ahead of the game, especially if you rsync the SURBL databases. It sounds like the OP has sufficient volume to make that worthwhile. > Summary (the numbers shows the (felt) "cost effectiveness"): > - (10) "reject" all emails for unknown recipients Yes. > - (5) "graylist" all unkown "from" Maybe - I'm not so keen on it. > - (3) slow down SMTP dialog or dynamic IPs or reject all. The latter is not always an option. For instance, as a business, we've felt that we can't do that, and an educational institution may be even less inclined. Nice if you can swing it, but I wouldn't count on it. > - (4) verify that sender exists Nice, but that costs time too. And this often breaks list servers badly. > - (3) block spam, maybe with self adjusting databases and > p2p networks > which distributes signature in real time. Razor/Pyzor/DCC are all good. SURBL is *really* good. Bayesian style learning databases might or might not be good. Worth a try, though. > - (9) remove all executables attachments (.exe .pif ...long > long list. > including "ActiveX" > it's easier to say: allow .zip .txt .doc .xls and its > OSS counter parts) As noted above, a big win if you can do it, but policy may dictate otherwise. > - (4) use a virus scanner to scan the (few) remaining emails. > > I think that will lower the load so much so you don't need to > worry much about the hardware for so "few" users. > Of cause that can't give 100% protection. > Who is promissing that is lying, who trust it is an idiot. > Brain v1.0 is still the unbeaten virus scanner ;-) > (But sometimes tricked out by the mail client) > > > Rainer Kurt _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
