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/
