Amavis

Quote from Nuxwin

Hello ;

TheCry  mrpink

I'm wondering if an implementation using Amavis could be better than using per service basis filters (as you are doing with milter).. Amavis is a daemon which would avoid usage of milter. I think it's also better for performance on high loaded servers. This could also solve your problem with filters order (problem which we talked privately).

Of course, this is only a personal opinion.

Display More

In the last month I have done a lot of research on the web, what nowadays is the best and up to date open source implementation for antispam and antivirus.
And I also wanted a small and lightweight solution, because I'm already using amavis and I'm not very happy with it. In my opinion it is to complex and overloaded compared to the milter solutions. When you compare the installed size of amavis vs. clamav-milter and spamass-milter, you get an idea of how overloaded amavis is. Here a short overview with pros and cons between amavis vs. clamav-milter and spamass-milter.

Amavis
pros
- one tool/daemon for both (spam and virus)
- content filter framework

cons
- installed size 2,262.0 kB
- complex and overloaded
- is written in perl
- slow compared to the spamass-milter and clamav-milter
- SMTP usage for sending to amavis and then also back to Postfix

clamav-milter
pros
- installed size 669.0 kB
- lightweight
- is written in C
- fast
- Unix socket

cons
- nothing that I know

spamass-milter
pros
- installed size 130.0 kB
- lightweight
- spamass-milter is written in C++
- fast
- Unix socket

cons
- nothing that I know

[size=medium]The way we plan to fight spam and viruses is an implementation in three stages.[/size]

The first stage is the usage of Postscreen, which was introduced with Postfix version 2.8.
When you trust the informations from Wietse Venema, then will Postscreen block 90% of all spam, before it reaches your SMTP server. I have read from users in several mailing lists and forum entries that really 70% - 90% is very realistic.

And with Postscreen it is not necessary to use policyd-weight and postgrey anymore. The functionality of policyd-weight (RBL checks) is integrated in Postscreen and you can drop the extra overhead. Postgrey is also not required, because you eliminate the most spam with Postscreen and don't need the user unfriendly function by temporarily rejecting mails that are maybe urgent.

Here you will find more information about Postscreen, if you don't know it. http://www.postfix.org/POSTSCREEN_README.html

I have written a Postscreen Plugin, which will use the recommended settings in Postfix for activating this functionality. Before I upload the Plugin to github, I have to review the code, because I plan to change some functions.

The second stage is ClamAV with clamav-milter and the third stage is SpamAssassin with spamass-milter.

The main advantage of the milter protocol is, that you can run it as a before-queue filter. That means, you can filter the mails before they will be accepted by the SMTP server.
If you want (but you do not need), you can reject the mails that contain viruses or spam, because the SMTP server did not accept the mail before. So you do not have to torture your users with sorting out mails in the SPAM folder, because you reject them and push the responsibility back to the sender. And that is totally legal, because the mailserver did not accept the mail before the virus and spam check (before-queue filter).

Your server does not have to accept and deliver spam and virus mails, so it has more resources left for the really clean mails. And your users do not have to waste their time on checking mails which are spam.
Some will now ask what is about false-positives? Well, the mail will not be dropped - only rejected back to the sender. So the sender is getting a mail from your mailserver explainig him, that his mail contains possibly spam.
So he has to check, why his mail got rejected and could contact the receiver of the mail or the postmaster of the SMTP server. No mail will be lost, because users are too lazy and do not check their SPAM folders. And also no problems with users who only use pop3 and do not have the SPAM folder synchronized like with imap.

And here the amavis approach, which is not very convenient when you compare with the one just explained.

You mailserver is accepting the mail and delivers it via SMTP to amavis (after-queue filter). Amavis is checking your mail against spam and viruses and also some content checks, is tagging the mail and then it is sending the mail back to your mailserver. Then your mailserver will deliver the mail to the mailbox of the user.

And now let's assume a mail is SPAM.

Amavis (after-queue filter):
- SPAM mail accepted my Postfix
- SPAM mail will be sent via SMTP to Amavis
- Amavis is checking the SPAM mail and tagging the mail as SPAM
- send the SPAM mail back via SMTP to the mailserver
- the mailserver is delivering the SPAM mail to the user

spamass-milter (before-queue filter):
- the spamass-milter is checking the SPAM mail and is rejecting it because it is SPAM

So now you could decide which is the easier, cooler and up to date approach.

Run the spamassassin per user with the roundcube plugin since over a year without any issue or performance problems.
I and my customers like it very much - easy to use and handles spam perfect.