[AMaViS-user] Postfix + Amavisd-new + Amavisd-milter

From: David Schweikert <david(at)schweikert.ch>
Date: Fri Jul 27 2007 - 08:15:49 EDT

Hi,

I am using Postfix and am experimenting with the inline rejection of virus mails using amavisd-new combined with amavisd-milter.

The reason for using the milter interface instead of smtpd_proxy_filter is that if you do inline rejection with smtpd_proxy_filter, you need to have as many amavisd processes as you have smtpd processes, which is really a problem. You can't also just limit drastically the number of concurrent smtpd processes because then they could be all blocked by slow clients. I guess that this is the biggest reason why Wietse does not recommend doing it for big sites.

Combining amavisd-new with amavisd-milter could however solve this problem: there is only one small multi-threaded process that talks to each of the smtpd processes and a connection is done to amavisd only when all the data is ready. It means that you can have 100 smtpd processes and 4 backend amavisd processes... Also, note that you can't combine smtpd_proxy_filter with milters doing content filtering, which puts you in a position to choose between the two.

There are however two small problems that I encountered:

1. amavisd-milter needs to be patched to work well with Postfix, because Postfix does give information about the queue-number only after the RCPT-TO-phase. I have attached a patch for that.
2. amavisd-milter requires to use Unix domain sockets to communicate with amavisd. This is not really a problem except that when I was stress-testing my test setup with 10 backend amavisd processes, I noticed that, once in a while, amavisd-milter was getting a "Connection refused" on the socket.

   The problem is that even though I properly limited the number of    amavisd connections in amavisd-milter, amavisd does have a listen    backlog (queuing of connecting clients) of maximum 5 clients. That    is, if I have configured to use at most 10 amavisd processes and by    chance 6 amavisd-milter processes try to establish a connection    simultaneously, it will fail.

   That's why, it would be useful to have in amavisd a variable called    $listen_backlog or something like that, which would allow you to    specify the queue size for the listen sockets. amavisd would then    just need to pass this as 'listen' parameter to Net::Server...

   Note that this is also not really an issue with inet sockets because    of the way connections to inet sockets are handled: if there is no    free space in the connection queue, the SYN packet is just dropped    so that the client comes back later. With unix sockets, it is not    possible to do that so the client gets immediately a connection    refused.

By the way: I am also getting better performance with amavisd-milter than with smtpd_proxy_filter: about 20% more mails per second.

Cheers
David

---

This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

---

AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/ Received on Fri Jul 27 08:29:31 2007