[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: exim/postfix comparisons



Nate Duehr wrote:
Nate Duehr wrote:
Qmail is fast, and can handle an incredible amount of mail thrown at it,
I have heard and read that claim so many times but, after years of having to admin qmail servers, have yet to seen it handle huge amounts of mail with even half the grace that Postfix does.

I have no experience with postfix on massive amounts of mail.

[snip]

I regularly encounter servers that had been compromised (usually via php or a weak smtp password) and used for sending out massess of spam. 100,000 undeliverable mails in the queue and qmail just about stops functioning.

That's odd. Someone who would go through the time/effort to set up qmail didn't secure their box? Weird.

Well, it's like this. I work for a hosting company, a lot of our clients use a certain hosting panel whose name I won't mention. This particular hosting panel works with qmail. The ones that aren't are generally set up by hand with either postfix or sendmail (about 50/50) and a handful with exim. Most servers are all-in-one hosting boxes, and the hardware range from desktop class machines to big brand-name servers with lots of CPUs, RAM and fast discs.

The thing with security on all-in-one hosting servers, is there are multiple ways to compromise them. Idiotic users whose passwords are 'password', '123456' or 'penis' (I kid you not) or the same as the username, means that script kiddies generally find a usable account in a matter of minutes. So seeing heaps of mail coming from some domain's "info" account is a daily occurance.

On top of this, until recently, this particular hosting panel by default bounced mail for non-existant users. So spammers forge the Return-Path, send mail to bogus addresses on valid domains, and let your box take the heat for spamming.

Third method is injecting mail in contact forms on websites. Also very popular and can be pretty tricky to troubleshoot.

I get at least one box that's compromised in one of the above ways per day. Clients call saying their mail isn't going out. This is usually because there are tens of thousands of mails in the queue and the box is paralised.

Take note, I'm talking about undeliverable mail. qmail doesn't deal well with this. It is pretty fast if all the mail can be delivered without problems.

Postfix is quite a different beast. The one and only time I saw it straining under load, a client phoned and complained that his mail was slow. Turns out he set up a mysql backend, but couldn't get smtp authentication working with it (forgot to install pam_mysql) and instead decided to just allow relay for 0.0.0.0. Let your imagination do the rest. His humble little server (I think it was a duron with 512MB ram and a single IDE disc) had over a million mails in the queue, but was still spitting out mail, just not as fast as he was used to.

What made this a pleasure to work with, was that after fixing the relay issue, I could move all the mail in the active queue to the hold queue, so mail was instantly flowing as normail, which gave me all the time in the world to delete the spam and requeue the legitimate mail. qmail (to the best of my knowledge) doesn't have a way to do this.

Never seen a queue quite that high, but I would assume the box would get both CPU and I/O bound for most values of "box". (GRIN)
Yeah, it gets to them. Another silly thing with qmail is that when you restart it, it doesn't kill existing outgoing smtp sessions. So if your remoteconcurrency is set to 100, you'll now have 200 sessions, until the first 100 all timed out.

--kj


Reply to: