Page 1 of 1

AV/AS solutions for Plesk, Centos 7 and Postfix

Posted: Sat Jan 23, 2016 9:59 am
by faris
I've decided to start a new thread on this one rather than continue with the old one.

As far as I can tell, the only real option for anti-spam and anti-virus on Plesk 12.5 and Centos 7 is either to go for Plesk's built-in spamassassin support in conjunction with commercial (and stupidly expensive) anti-virus, or to use amavisd-new with it.

Has anybody used amavisd-new with Centos 7 yet? Any comments?

Is there also a third possibility, a hybrid approach?

There's nothing much wrong with Plesk's built-in spamassassin support, so I was wondering if clamav could be added manually.
If so, it would eliminate the need for amavisd-new. ... th-clamav/ seems to indicate that adding clamav scanning to Postfix is straightforward - IF you have the right clamav packages, and that means the clamsmtp filter, which I've not come across before.

Has anybody looked into this at all?

Re: AV/AS solutions for Plesk, Centos 7 and Postfix

Posted: Sun Jan 24, 2016 6:13 am
by prupert
Have had no issues with amavisd-new (from EPEL) on EL 7 with and without Plesk. I do recommend not to use the Atomic repo, and stick with EPEL, also for ClamAV.

Re: AV/AS solutions for Plesk, Centos 7 and Postfix

Posted: Sun Jan 24, 2016 6:54 am
by faris

I've now had a go and installed it and it worked fine just as you say.

I'm just not happy with it yet. All the new configuration files and complexity compared to qmail/qmail-scanner/spamdyke is annoying me. I'll either have to get used to it, or stick to qmail!

Re: AV/AS solutions for Plesk, Centos 7 and Postfix

Posted: Sun Jan 24, 2016 1:08 pm
by prupert
What do you exactly find complex or annoying?

Do you mean their ugly config file?

Re: AV/AS solutions for Plesk, Centos 7 and Postfix

Posted: Mon Jan 25, 2016 6:30 am
by faris
Yes, ugly config file is one, and a confusing set of options for whitelisting/rejecting IPs/rdns etc.

Then there's the logs. I want easy to understand logs. So far when I look at them I get more confused than with qmail.

What I want with postfix, and what I currently get with spamdyke/qmail/qmail-scanner:

Simple reject logging
Text file containing whitelist rDNS and a different one for blacklist rDNS.
Similar whitelist/blacklists for sending IPs, sending "from" address, etc etc
per-domain and per-recipient control of which RBLs and other settings will be applied (e.g. domain1 reject on no rDNS, domain2 does not reject on no rDNS).

In my current logs, I get DENIED [REASON] for every connection (unless the recipient doesn't exist). I get spamassassin score, with which rules triggered to cause it and how long it took. I get clamd result, and how long it took.
But because it is qmail, everything is all over the place and it can be a headache to track a particular email through the logs to find who sent it, and how it was processed and what happened to it.

But so far -- and I admit I've not tried very hard yet - I'm struggling to get the same configuration granularity with postfix and amavisd, and the logs just seem incomprehensible.

I *know* postfix is the way I should go, but right now I'm wondering if I should wait until I can do what I need to do more easily.

So at the moment I'm considering using qmail with Plesk's built-in spamassassin support to allow customers to adjust sensitivity themselves, in conjunction with qmail-scanner for clamav only, and spamdyke for RBL/rDNS/whitelist/blacklist etc.

Re: AV/AS solutions for Plesk, Centos 7 and Postfix

Posted: Mon Jan 25, 2016 3:26 pm
by prupert
End-users rarely understand what SpamAssassin scores mean. Heck, I wouldn't even want to mess with it. Stick with sane global defaults is my motto.

IMHO nowadays the most important aspect of mail filtering is to have your filter learn which messages your end-users believe to be spam and which not.

For optimal performance of your mail server it is very beneficial to do some simple rejection (cheap!) *before* using your full-flegded content scanners (expensive!). Here again, using sane global defaults is useful at the first layer(s) of connection/content rejection.

Ideally you use a multi layered defence such as, but this may not be a good fit if you are using a single server setup with Plesk as the primary MX and SMTP relay.

Re: AV/AS solutions for Plesk, Centos 7 and Postfix

Posted: Tue Jan 26, 2016 10:47 am
by faris
Postscreen looks very interesting, and has a lot in common with SpamDyke, I think, but with bells on :-)

We have a variety of setups. We have several PG boxes on unrelated networks in different countries to scan mail for some users, but not all. I would not be comfortable switching all users to these boxes unless I had more of them, and I'm trying to control costs at the moment.

The disadvantage of a PG box is that it can't reject email sent to a non-existent address, and although only a tiny fraction of emails get through the filters to such addresses, I find it annoying as the PG box then bounces the spam, potentially, causing annoying backscatter.

A feature has recently been added to spamdyke that, with some simple additional scripts, could do a user lookup, but as I understand it Postfix has this facility built-in (not that I know how to use it).

I totally agree about the spam setting thing. Almost nobody wants or needs to change the settings. But some really do, and I certainly need per-user spamassassin settings as I know some users get heaps of spam and are happy to set a low reject score.

And again, as you say, what is spam to some isn't spam to others. The main complaint is business stuff - telephone systems, payment recovery, water coolers -- this is allowed in the UK and marketing companies take advantage of it.

Unfortunately I know of no way for individual users to mark a particular message as spam via Plesk, without using IMAP.

What's required is either a local anti-spam (e.g. part of Norton or whatever) or something that does not exist - a plugin for Outlook that somehow interfaces to the anti-spam system on the server and transfers messages marked as spam into a directory that can be learned from.

So there you go. That's an original idea. Certainly I've never heard of such a thing. So I think all I need is venture capital and a programmer :-)