Antispam Proxy

Hey Chris,

Looks like it exists as a standalone filter...so it probably shouldn't cause any trouble with Virtualmin (with one caveat regarding allowing your clients to send email, see below). Though, I suspect you'll see load increase quite a bit over having Postfix as your front line. It's probably possible to set up ASSP using the filter interface of Postfix rather than the way this example shows it being configured, which avoids that problem.

Specifically, postfix knows all of your mailboxes, and can reject immediately based on messages to users that don't exist or aren't allowed to relay. This is a very cheap rejection, whereas processing for spam is a very heavy rejection...requiring possibly a couple of seconds of CPU time.

The other potential gotcha is that they suggest you disallow connections from anyone other than localhost. Unless ASSP provides an SMTP auth mechanism, your users won't be able to send email through your server anymore in the configuration suggested.

If it is possible to use the Postfix filter mechanism, all of those problems disappear (a few other minor ones might appear, but I'm almost certain nothing will cause you or your clients any pain...just an additional bit of obfuscation during troubleshooting of mail troubles).

The way you would do that is put ASSP onto some other (probably local) port. 10024 or 10025 is common for this sort of thing--that's where Amavisd-new lives usually, but any old unassigned port will do. Then you configure postfix in master.cf with the incoming and outgoing stuff. ASSP uses SMTP to communicate and so does the Postfix filter interface (no "milter" special casing required, as with Sendmail), so I think this would be possible. The Amavisd-new docs can probably guide you better in how to set things up that the HOWTO you've linked to, since it also uses SMTP interfaces. There's probably also some docs somewhere about using ASSP as a filter for postfix out there somewhere.

Anyway, it's almost certainly possible to set it up in a way that won't break mail service for your users, but I don't think the HOWTO you've linked to is that way. You'll almost certainly lose SMTP auth. Oh, it looks like you might lose some of the capabilities of ASSP by running it as a filter instead of the front-line SMTP server--greylisting (they call it "delaying") requires the ability to refuse connections temporarily, and I don't think filters have that possibility since Postfix will have already accepted the connection. So, depending on how important control of that connection is to the ASSP way of filtering, it might neuter it too much to run it as a filter.

You may be better served by tweaking and training SpamAssassin a bit more. SA includes good implementations of almost every major mechanism for filtering spam. Though, admittedly, the version included with some operating systems is a bit old and lacks some techniques (bayesian filtering only came into SA in 3.0, I think, while CentOS 3 has the 2.x branch).

I'm also looking into adding a few other anti-spam systems to the mix of a default install. CRM-114 has been recommended quite strongly to me by someone quite famous in the anti-spam world (I'm not gonna names, as that would reveal to much of what Virtualmin has been up to lately...and we don't pre-announce), so I'm almost certain we'll be adding it to the system in the next couple of months along with tools to allow users and administrators to manage the ham/spam corpora.

ASSP is a new entry, so I can't judge whether it is a good choice to combine with SpamAssassin, but let us know how it works. We might begin integrating it in the future, if it provides some capabilities that SpamAssassin and CRM-114 lack and if it can be used effectively in a way that is not harmful to our existing mail process.