Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Can you guys share some thoughts/experiences for antivirus/antispam for postfix.

  1. What is your antivirus and antispam combination used in your system?
  2. any particular reasons behind it?
  3. notable features that should be considered when choosing antivirus and antispam software?
  4. others

I need to set up an MX server, we are serving about 70 domains, with users ranging from few 100s to 35k for each domain. The idea is to set up MX servers, dozens of them, only for incoming emails, do all the anti spam/virus/rbl, etc., checking and route them back to the domain SMTP.

Hopefully you can enlighten me a little bit.

TQVM guys.

share|improve this question

5 Answers 5

up vote 2 down vote accepted

I prefer to use DSPAM myself (somewhat complicated to implement, but worth it), and I've seen very low resource usage (programmed in C), and I like the statistical approach compared to one-size-fits-all filter systems like spamassassin. DSPAM has built-in support for ClamAV.

But proper usage of built-in postfix restrictions are really the best first-line defense.

I decided to skip greylisting (used postgrey in the past) because it requires you to keep a whitelist of misbehaving servers (or trust its database). For that reason I also decided against reject_unknown_helo, because it requires you to keep a whitelist of servers that doesn't do things the way they should do (according to RFC).

If manual whitelisting floats your boat then these two approaches drastically reduce your spam (catches more than 80% of spam with almost no errors) even before it's queued in your server, which is a major benefit. The downside is that you need to pay attention to your logs and whitelist misbehaving (but legit) servers as soon as you notice them, or your users will probably complain.

Implementing SMTP AUTH (in my opinion most easily by using the dovecot auth provider) helps to make sure that submission is handled properly (together with a strict smarthost (mynetworks) list/policy).

My suggestion when setting up postfix is to have a clear plan of what you want to achieve (figure out if you want local or virtual delivery, what type of antivirus/spam system and how to do delivery+filtering).

Start with an empty main.cf and use postconf (complete current config) / postconf -n (only non-defaults) / postconf -d (only defaults) to build up your configuration from the default step by step until you have what you want. The distribution very often come with defaults that capture the distributors idea of a mail system, and it doesn't always reflect your views, opinions and policies (they might differ). Remember to do all of this on a system without users so that you can experiment in peace.

I was able to implement all of this with precompiled packages on Ubuntu 9.04 server (even dspam), so extensive compiling should not be needed, just patience while configuring.

share|improve this answer
    
hi thanks for sharing, by the way i already decided to use dspam+clamav together with my postfix relay. dspam trained using spamassassin public corpus. –  Abi Aqil Aug 30 '09 at 3:02

I renounced using an antivirus/antispam solution 3-4 yrs ago (by then I was using amavisd+clamav+spamassasin, which was really a resource hog)

the only antispam measures I have now (and tend to work very well, though adding the above combination would decrease the number of spam who managed to reach the inbox) are, in order of checking:

- reject_invalid_hostname
- greylisting
- spf checks
- rbl checks (spamhaus, abuseat, dsbl, sorbs, njabl)
- reject_rhsbl_sender    dsn.rfc-ignorant.org

an some custom rules for checking sender access

this is a compromise between stopping spam and avoiding to use large amounts cpu+ram; however, I am planning to have a machine or two for scanning mail - clamav+spamassassin

for your point 3 - if you are thinking of a commercial product, I guess the price is the main reason (per doman, per mailbox, etc)

share|improve this answer
    
tq for sharing... some points to think of.. –  Abi Aqil Aug 21 '09 at 9:23

I use postfix + amavis + spamassassin + clamav . Is the solution that had worked better in my systems. For large installations is better to separate amavis from postfix in another server.

This kind of solution needs a lot of continuos effort and adjustments to avoid performance problems and get the best results blockin spam and virus. But at the end I'm very satisfied.

Also as petre says you will need custom rules in postfix and dns to improve the solution.

share|improve this answer

I administer the mail (among other things) for an ISP with about 180 domain names and around 5000 e-mail accounts. As such, our customers demand excellent spam filtering and would really prefer that we don't use such crude methods as refusing all mail from Russia or some garbage like that.

Our current mail server is Qmail, with clamav filtering viruses on that machine, and another machine (dual Xeon CPUs with 1.5 Gig of RAM) doing nothing but running Spamassassin. But none of that happens until after a special Qmail plugin checks the IP against bl.spamcop.net and the XBL at Spamhaus.

This filters out about 95% of the e-mail being sent to our server.

However, I wouldn't recommend this approach. Qmail is too antiquated for the task really. Eliminating backscatter requires a kludgy hack that needs too much human intervention, it doesn't do greylisting and handles SPF both for incoming mail and forwards very badly.

I'm nearly finished building a new Debian server running Exim, which does check SPF records, does greylisting, checks Realtime Blacklists, and the incoming SMTP server verifies the existence of e-mail accounts using the same MySQL database that Dovecot uses to authenticate users. Then, when it's done all that, it checks mail with the resource hog that Spamassassin is. Reducing the amount of mail that goes into that filter is very important when you use it. The heuristics provide a high level of granularity, but it shouldn't be your first line of defense.

share|improve this answer
  • reject_invalid_hostname
  • greylisting
  • spf checks
  • rbl checks (spamhaus, abuseat, dsbl, sorbs, njabl)
  • reject_rhsbl_sender dsn.rfc-ignorant.org

with all due respect - by this you reject more legitimate mails in the non-RFC compliant way and support faulty makeup standards like SPF than the lamest of mail setups I have ever heard of.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.