Mail Server recommendations

[Charles Swiger]

On Apr 29, 2005, at 6:05 PM, Chris Cameron wrote:
> On Thursday 28 April 2005 16:32, Chuck Swiger wrote:
>> # limit on number of concurrent queue runners
>> #O MaxQueueChildren
>>
>> Also consider setting up queue groups, and splitting up your mail
>> into at least two piles: your internal mail, and everyone else,
>> although creating a few more groups for common list traffic helps.
>
> I'd just like to say that this isn't the silver-bullet it ought to be,
> and will be pretty much worthless if this mail server is as busy as
> it's being made out to be.

Apparently, the OP is only seeing a few thousand messages per day, and 
has a total of 500 user accounts.  You can handle that easily on less 
hardware than he has, although splitting the load between a reader box 
and a MX/virus/spam-scanner would help a great deal.

> If the amount of mail in your queue is bigger than the number of queue
> runners you allow to run at any given time, sendmail will leak memory
> like mad. I have a script that HUPs sendmail every morning due to this.

The amount of queued up mail is almost always larger than the number of 
queue runners.  You only need one runner per queue (and by default, 
there is only one queue).

This is a seperate matter from sendmail leaking memory.
What OS, which sendmail version?

> This is made all the worse by the fact that during peak times queue
> runners will get gummed up on undeliverable mail, and prevent the next
> bunch of queue runners from going, making the back log in the queue all
> the bigger.

The undeliverable mail (spam and spam bounces) is best handled by 
rejecting the mail before it is accepted, using RBL's, local rulesets, 
greylisting, and so forth, depending on what the local policy permits.

However, if you set up multiple queue groups as I'd recommended above, 
most of your "real mail" will go into a different queue than generic 
spam.  Who cares whether it takes 5 minutes or 50 to iterate through 
today's list of 200 undeliverable messages, so long as legitimate mail 
isn't delayed significantly?

>> Or consider switching to an MTA like postfix, which provides very
>> good control over how many child processes can go on via master.cf...
>
> Probably his best bet. Any new mail accounts at my site are going on a
> different server running qmail.

qmail hasn't caused me any problems, though I don't run it myself.  
I've had a few interoperability issues with exim, but these were 
trivial compared with the poor sods running Exchange as their MX.

I expect that I'll still be dealing with sendmail for as long as I 
administer mail servers, and that's OK, but I was pleased when Apple 
switched to using Postfix with MacOS X, and I wouldn't mind seeing 
other systems follow that path.

-- 
-Chuck