central amavis machine for in and outbound

Patrick Ben Koetter p at state-of-mind.de
Thu Nov 17 19:55:05 CET 2011


* Tobias Hachmer <lists at kokelnet.de>:
> Am 17.11.2011 18:05, schrieb Patrick Ben Koetter:
> >You mean this?
> >
> > +--------+    +--------+      +--------+  +--------+
> > |        |    |        |      |        |  |        |
> > |inbound |    |inbound |      |outbound|  |outbound|
> > |        |    |        |      |        |  |        |
> > +---+----+    +-+------+      +--------+  +--------+
> >     |           |                     +      +
> >     |           |                     |      |
> >     |           |                     |      |
> >     |           |   +---------------+ |      |
> >     |           |   |               | |      |
> >     |           +--+|  content      |++      |
> >     +--------------+|  filter       |+-------+
> >     smtpd_proxy_... |  amavis       |
> >                     +---------------+
> 
> Yes, that's what I've tried to express...
> 
> >It depends on the load and the filters (commercial virus scanner
> >licences) you
> >use within amavis.
> 
> Well, at the moment there are 30000~ incoming mails per month,

30.000 msg overall, including spam, or filtered messages?

> outgoing is nothing to speak of.
> I don't use any commercial virus scanner, just clamav.

Then there's no gain in reducing license fees.


> >>>Are there any pros or cons?
> >
> >What is the gain in your eyes?
> 
> I don't really know, I hope the list can tell me some experiences.
> What are the pros and cons to have one or two central amavis
> machines compared to have an amavis instance on every postfix
> machine locally (e.g. how to handle bayes?)?

I don't think it pays to run a centralized content filter framework.

Costs
You can reduce license costs for e.g. virus scanners, but only if their
license is per cpu/machine. However most virus scanners I have worked with use
a per user license model which makes no difference if you run the scanner on
one or more than one machine.

Content filtering is CPU expensive. If you centralize the filter you will have
to buy hardware that can filter for more than one server at the same time AND
can deal with peak load. You will end up buying extra powerful CPUs (including
board and RAM).

Regular servers bring 8 core CPUs, of whom most idle most of the time on a
mail server because mail is I/O bound. There's plenty of ressources left to
run an additional content filter.

Sharing Ressources
If you run a centralized content filter you don't have to worry about
knowledge distribution. All knowledge required (e.g. bayes DB, quarantine)
resides on one server.

I don't consider this a problem either. Accessing bayes and quarantine over a
network is easy - both can use SQL as storage. All amavis tools are storage
agnostic. You configure the backend in amavisd and tool communication takes
place with amavisd, which deals with backend communication.


Management
If you run n instances of amavis on n servers you will have to manage n
configurations. No reason to put everything on a centralized server either.
First of all there are tons of tools to deal with configuration distribution
ranging from scp, rsyc, etckeeper, Makefiles up to heavy machinery such as
cfengine, puppet, chef etc. pp. to help you distribute configuration.
Secondly you can provide domain and recipient specific configuration over
network using SQL or LDAP and last, but not least, configuration tends to
stablize after a while and you need to deal with it only rarely.

Redundancy
If you run many servers, they can take over if one dies. If you run a central
server you will have to provide a spare server in case it dies away. AND you
will have to keep all config and knowledge in sync.


I favor a decentralized system.

p at rick


-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>


More information about the amavis-users mailing list