[CentOS] Re: Planning Mail Server (with low resources)

Tue Dec 6 15:18:41 UTC 2005
Feizhou <feizhou at graffiti.net>

Rodrigo Barbosa wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, Dec 06, 2005 at 10:27:24PM +0800, Feizhou wrote:
> 
>>Forget mailscanner. Use postfix with clamsmtpd and clamav for AV. As for 
>>spam, the best defence is NOT to accept spams in the first place. Making 
>>good use of RBLs like the SBL, XBL, SORBS RBLs and the other suggestion 
>>of using SURBL in spamassassin should keep the spam problem to a minimum 
>>and this again is mostly postfix related except for spamassassin.
> 
> 
> That depends on how you see it. If you are thinking about the spam ratio,
> yes, you are correct. RBLs can filter up to 90% of all the spam (in my
> experience). On the other hand, if you are being targeted by 1000's of
> spams daily, you will still get a fair number of them.


More than 90% is possible in mine :) and it is also a case of being 
targeted...

Content filtering for spam is one of the worst things to do.

> 
> 
>>I would suggest otherwise. Your huge /var/spool/mail suggests that you 
>>plan to use the mbox format for storing mails. I suggest that you switch 
>>to maildir and therefore trash /var/spool/mail and allocate that lot to 
>>/home and use maildir to store your mails.
> 
> 
> As I stated before, one of the best things about maildir is that you
> can use incremental backup procedures. So I second that idea, no
> matter if you are keeping the maildirs on /home or /var/spool/mail.


Keeping them under /home would seem the best. Everything is there. Need 
to delete? Bye bye /home/goner. But we have forgotten the 2k user part. 
It appears that this is best implemented using a virtual 
user/domain/whatever system.

> 
> 
>>Yes. I suggest running two queues. postfix + clamsmtpd + clamav, first 
>>line of defence (RBLs and other gateway blocking). Mails that get 
>>through should then be delivered to a qmail queue which will give you 
>>very low resource taking processes and a maildir delivery system with 
>>the most versatile local delivery agent possible. dovecot can be used as 
>>the imap server.
> 
> 
> Is it really recomended (cost/benefit) to mix two different MTA's ?
> I never tried that. I just start on the idea that it would simply
> add too much complexity. Then again, I might be misinformed, and
> the benefits be enough to make it worth. Care you elaborate a little
> more on that one, please ?

It is a case of trying to get the best from both MTAs. A qmail system 
requires almost zero maintenance. There have been cases of people who 
install qmail, some without help while others requiring some help, and 
then forgetting how to do it after a couple or a few years of not even 
touching it. The only reason for these ones to install qmail again was 
because of a server replacement. This is for those who do not have to 
deal with a lot of spam.

qmail is simple, efficient and has a small footprint and can be 
maintenance free and comes with the best local delivery system 
available. For these same reasons, it is also the least best for dealing 
with spam unless you heavily modify it like Yahoo!, the least convenient 
if you have to deal with mail in the mail queue and is so simple that it 
lacks what others would consider essential items like smtp-auth and what 
not. Although it is possible to get these other essential items, it 
involves choosing from a substantial list of patches and then getting 
those to apply without breaking one another so it can be a quite an 
uphill thing for a newcomer.

postfix on the other hand has plenty of features or essential items 
builtin, is not too hard to configure and also has a very convenient way 
of handling the queue.

Both come from security experts and those self-same men have got into 
the mta side of things. Why not put them together? The irony of course 
is that both men probably hate each other to bits.

The other benefit from this (not necessary to run two different mtas of 
course) is that you get two queues which means you can separate incoming 
and outgoing traffic. incoming traffic ends up in qmail and outgoing 
traffic stay in the postfix queue.

Just telling postfix to send all incoming mails to the qmail queue 
should not be complex. Then you can manage the two on their own.