Atomicorp

I particularly like the ability of qmail-scanner to Reject a message at the MTA level when a message is considered Spam or contains a virus.

In conjunction with SpamDyke, which can Reject with a specific message when a sender fails RBL, rDNS tests etc, a legitimate sender whose message is not accepted due to a false positive will ALWAYS be informed, and with zero backscatter.


But having looked deeply into amavisd-new and Postfix, it seems that you just can't Reject. The only option is to drop or bounce (or redirect/quarantine).

Bouncing is out of the question. That's basically a guarantee of huge backscatter.

Redirecting (e.g. to a quarantine address) is not going to work as it requires that address to exist.

So the only option is therefore to Drop.

Has anyone found this to be an issue (clients complaining)? Or do you do something interesting to get around the problem?

Yeah I was looking into amavisd-new today as well. You'd think 12+ years after I did Project Gamera this stuff would suck less. If anything things feel more complicated than they did before.

My thoughts so far:

* amavisd-new: all perl, the way it uses spamassassin as a library is unusual. Overall doesn't seem to be any better than qmail-scanner. Also you need to know perl to edit its config file.

* sagator: In python, has a web console. I'm trying this soon.

* clapf from bitbucket: In C, so potentially faster. Has a web console, but uses its own alternative to spamassassin. Im concerned about accuracy there.

I really dont want to keep qmail on any more life support by porting PG to EL7. Id like to get all these steps collapsed into something less work.

I totally agree with you Scott. Amavisd-new does seem to be the best supported option though. I would be happy with something faster and less ugly to manage.

I have looked into postscreen and we reject using the Spamhaus SBL which does help a lot.

I just got sagator set up last night on a PG node, so about as much as I can vouch for right now is the installation and the tie ins:

* Installation is pretty good, and only takes 2 steps (I think this could be done in one with some rpm work)
1) yum install sagator
This installs sagator with a default configuration that enables greylisting, spamassassin, and clamav. It can optionally support other AV & Anti-spam scanners

2) sh /usr/share/doc/sagator*/configure_postfix.sh
This updates the postfix config. Id probably move this into a rpm trigger to cut out a step like clapf & qmail-scanner use.

Not tried yet:
* It appears that spamassassin is invoked in a way that would allow per user SQL settings.
* Web console, this might only handle quarantined email messages & reporting.
* chrooting
* rejecting messages, I definitely saw this referenced in the config
* Policy scanners, it looks like it can do quota based rules. I know you can do this in postfix with policyd too, which might be more advanced. This looks pretty basic
* Database integration, looks like you could use this for clustering

A small concern might be that the sagator project was not updated between 2011 and 2014.

I'm also worried that as far as I can see, Postfix is designed to accept a complete message, then send it for processing by some form of content filter (content_filter=), such as amavid-new or sagator or whatever.

My understanding of this is therefore that Postfix simply cannot directly reject spam or virus messages (i.e. to the connecting client) in the way qmail-scanner can - at least not when using content_filter.

From a list post I read somewhere about rejecting, a message can be "rejected" by a Postfix content filer, but this involves a bounce email, not a rejection by Postfix to the connecting client.

I think http://www.ijs.si/software/amavisd/READ ... ations.txt has some reference to that I'm going on about, although this is amavid-specific.

You could kind of say the same about qmai-scanner, last updates I saw for that were in 2013.

And you're absolutely right, when I tested "reject" it just sent a bounce message instead of handling it purely at the SMTP layer.

OK, so I suppose we have to accept that we cannot Reject properly if we are going to use Postfix.

Silently dropping an email with a viral attachment is not a big problem, even though I have seen the occasional false positive with the additional ASL clamav rules.

Silently dropping a message that is considered spam is more of a problem, especially if the customer has no way to adjust the score at which messages get dropped and/or tagged.

I mean sure, we can safely silently drop messages above 20, and maybe even a little lower, but otherwise we have to tag.

And that means more spam appearing in customer mailboxes. Sigh.

There's also the fact that Plesk now has built-in SA support. I know that's no good to PG, but most users are going to want this solution to use with Plesk.

Unfortunately Plesk's SA support appears at first glance to be rudimentary, and doesn't even allow you to tag above X and drop above Y as far as I can tell.

I havent played with it yet, but I see sagator has a quarantine with a web front end. Here are some screenshots:

http://www.salstar.sk/sagator/webq

It also looks like it can store the per user settings in mysql, and that particular screenshot looks like the quarantine for a specific mail box.

The third-party anti-spam system that we have protecting a particular domain works a bit like that, but with a very useful added feature: every day I get an email listing all the messages (sender, subject, time) that were quarantined, with a link next to each email to release it and optionally to also whitelist the sender.

What's neat about this way of quarantining is that the user need never login to any sort of anti-spam control panel (something many users would struggle with). So no usernames/passwords to remember/forget.

For users with more technical ability, there is a control panel if they want it though. After logging in, they can manually add whitelist entries and view quarantined emails going back X days (approx. one week).

It even has some advanced features: If you have more than one email address protected by the system, it allows you to register some or all of them in one control panel account, so you don't have to login to X different accounts to check for false positives.

Overall it works very well in terms of user friendliness.
I wonder if the sagator system can be adapted to offer similar features.