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

Feizhou feizhou at graffiti.net
Tue Dec 6 16:17:45 UTC 2005


> I find it a liability to just leave an e-mail server like that.
> Putting asside the "qmail is 100% secure idea", which I really won't
> debate, you have to agree that qmail needs a lot of 3rd party software
> to work on an environment like that (vpopmail etc etc). And those
> require maintenance, not to mention the database backend.

vpopmail does not require maintenance. add a domain in his case would be 
like once in a blue moon, ditto remove. mysql is one of the most easy to 
maintain...the thing usually keeps running even after a crash.

> 
> Performancewise, I consider (from the tests I ran for Conectiva back in
> 2000) qmail the second fastest non-commercial MTA. The fastests being
> exim. Commercial solutions like S/MAIL will beat them all to the ground,
> and S/MAIL is the basis of Exim just like QMail is the basis for Postfix.

sendmail led to qmail led to postfix

I am sure exim fits somewhere :D

> 
> Let me make it plain once again: I'm not recomending exim for his
> e-mail server. Learning to get exim running "just right" is not
> easy. Exim 4 is very complex these days, specially if you add ACL to the
> mix. I used to edit sendmail.cf using VI (not vim), so I can recognize
> complexity when I see it :) The old saying goes that you can only
> consider yourself a network administrator if you ever edited sendmail.cf
> by hand once. If you did it twice, you are not a network admnistrator, you
> are a lunatic, and should be commited to a mental institution :)

Hear hear. Glad I got sendmail chucked out...we had a mysql enabled version.

> 
> Anyway, I think your solution, even tho it does have many merits, will
> add unneeded complexity to Alain's setup.

He still needs a virtual backend. Either learn to use someone else's 
tools or make your own...

> 
> Let me also mention that I do think a multiple server solution is
> best, specially if you can, as you mentioned, separate incoming from
> outgoing queues.

agreed.

> 
> 
>>qmail is simple, efficient and has a small footprint (...)
> 
> 
> I won't argue about efficent and small footprint, specially the
> later, but simple it isn't.

Simple it is. There is absolutely NOTHING to do after initial 
installation and configuration. Oh, you meant the setup? Well, some 
manage with help, others won't get anywhere without.

> 
> The most simple (as in straightforward) MTA I've seen so far is
> postfix. And no, I never use it.

Sorry, I use both and sendmail too and I do not agree. qmail is by far 
the most simple.

> 
> 
>>maintenance free and 
> 
> 
>>comes with the best local delivery system available. 
> 
> 
> <flamewar invitation>
> Procmail ? Sure it does. But so does every other MTA :)
> </flamewar>

AH, we have a slight misunderstanding here. procmail don't handle 
.forward files I believe. procmail is a filtering program. Its 
competitor/comparison would be maildrop for which I'd vouch for given 
procmail's cpu hogging properties.

  .forward simply does not match .qmail

> 
>>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.
> 
> 
> We agree on more than we disagree.
> 
> Postfix is all that. It is not the best solution, but it is the
> one I recomend for non-experienced MTA admins.

Hear hear.

> 
> 
>>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.
> 
> 
> Hating DJB is more common than not :)

Haha

> 
> 
>>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.
> 
> 
> Despite the merits of qmail or the configuration you are proposing,
> I don't think it is the best solution for this particular user
> on this particular environment.


Well he is better off not doing a system account = email account 
management system in my opinion.



More information about the CentOS mailing list