central amavis machine for in and outbound

[Tobias Hachmer]

Am 17.11.2011 19:55, schrieb Patrick Ben Koetter:
>> Well, at the moment there are 30000~ incoming mails per month,
>
> 30.000 msg overall, including spam, or filtered messages?

Yes, overall. Got this values from mailgraph...

> 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.

Yeah, you're right, doesn't thought of that, yet.

> 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.

Is it a problem when multiple amavisd instances want to write to bayes 
db ore awl db at the same time?

> 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.

Thank's a lot for your suggestions. You helped me a lot to plan my next 
setup, also tending now to decentralized system.

Best regards,

Tobias