qmail

[koffiejunkie]

Don't do it.

That's all.

 

[froot]

I like it when someone tells us not to do something (it means they've had a very bad experience with something).
It's also nice to know why....

I will be returning to Linux after an absence of just over a year.... why should I not use it?

 

[drs]

In defence of qmail...

qmail was an awesome MTA in its day -- I ran it quite happily for many years. Once you'd learned how the pieces fitted together, it was very easy to understand and work with. It was vastly better than sendmail, and probably better than Exim at the time (though I didn't run Exim then). And aspects of qmail's design have influenced Postfix.

Trouble is, the last version of qmail was released in 1998. Its time has now passed, and you shouldn't be running it in 2011.

 

[froot]

Yes that definitely makes sense. Okay, mods can close this thread, discussion closed

 

[koffiejunkie]

I like it when someone tells us not to do something (it means they've had a very bad experience with something).

Heh, my team deals with something close to 100,000 servers, a good deal of them - 70% I'd guess - is qmail.

I will be returning to Linux after an absence of just over a year.... why should I not use it?

How much time do you have?

Disclaimer: I work with qmail on Plesk, so what follows is in that context.

Let's start with some basics. Disregarding any problems, qmail proponents tout two features in particular: speed and security. Both are false. They may have been true 10 years ago, but the rest of the MTA world has moved on while qmail hasn't.

Back when qmail was first written, the biggest bottlenecks on servers were CPU and RAM. Hard drive speed wasn't much of an issue at the time and qmail comfortably outperformed everything else because it was light on CPU and RAM. But CPUs have gotten faster and RAM have gotten cheap, and hard drives still don't go any faster than 15krpm (ignore SSD for now). qmail is heavier on disc I/O than Postfix and Exim. It's even heavier than Sendmail. This means that, under huge load, qmail loses to the other three. Big time.

With regards to security, if you want to be anal and insist that means you can't get rooted through qmail, then fine. You'll have your hands full getting yourself off blacklists anyway. But I consider re-using queue IDs at an alarming rate and bouncing mail to someone other than the sender pretty serious security flaws.

It has some other quirks too. For example, it never does an MX lookup, or an A lookup. Instead, it does an ANY lookup, which I suppose means its spends less time looking up DNS, so there's a performance benefit. But there is no requirement for DNS servers to respond to an ANY query, and no requirement with respect to what the response to an ANY query should contain. So if you're sending mail to a domain that does not respond to ANY requests with the MX or A records, your mail won't go nowhere.

What prompted me to write this today, is the way RBLs are done. Instead, you rely on an external program (rblsmtp) to accept the SMTP connection first, do the RBL check and pass it on to qmail if it passes. This means that qmail never knows about mail that got rejected, and consequently it never logs that information. So when your legitimate mail is getting rejected because of RBL issues, you just don't know it, unless the sender gets a bounce (which isn't a given) and lets you know. Today I had an issue where a client was getting mail a day after it was sent. The headers show it was bouncing around in the sender's solution (it's a big one, so multiple servers). Turns out the problem was that the client had SORBS in their RBLs, and the sender's servers were listed there. If that fact had been logged, it would have been quick and easy to see what the problem was, but of course there's no trace of that in the logs.

It has many other shortcomings and odd behaviours like treating 5xx errors as 4xx, so your mail sits in the queue for the default 7 days, hard-wiring destination information at submission time, and lots more.

Fortunately Plesk supports Postfix these days. Makes life easier.

 

[koffiejunkie]

qmail was an awesome MTA in its day -- I ran it quite happily for many years. Once you'd learned how the pieces fitted together, it was very easy to understand and work with. It was vastly better than sendmail, and probably better than Exim at the time (though I didn't run Exim then). And aspects of qmail's design have influenced Postfix.

I don't think it was ever "better" than sendmail. It was faster and more secure at the time. But it was never as configurable. There are lots of things that you could do with Sendmail back then, that you simply can't do with qmail. At least not without lots of patching.

But yeah, I agree. Dan Bernstein unfortunately thinks his code is perfect, and won't let anyone fix it.

 

[San-DraX]

lol

 

[froot]

Heh, my team deals with something close to 100,000 servers, a good deal of them - 70% I'd guess - is qmail.



How much time do you have?

Disclaimer: I work with qmail on Plesk, so what follows is in that context.

Let's start with some basics. Disregarding any problems, qmail proponents tout two features in particular: speed and security. Both are false. They may have been true 10 years ago, but the rest of the MTA world has moved on while qmail hasn't.

Back when qmail was first written, the biggest bottlenecks on servers were CPU and RAM. Hard drive speed wasn't much of an issue at the time and qmail comfortably outperformed everything else because it was light on CPU and RAM. But CPUs have gotten faster and RAM have gotten cheap, and hard drives still don't go any faster than 15krpm (ignore SSD for now). qmail is heavier on disc I/O than Postfix and Exim. It's even heavier than Sendmail. This means that, under huge load, qmail loses to the other three. Big time.

With regards to security, if you want to be anal and insist that means you can't get rooted through qmail, then fine. You'll have your hands full getting yourself off blacklists anyway. But I consider re-using queue IDs at an alarming rate and bouncing mail to someone other than the sender pretty serious security flaws.

It has some other quirks too. For example, it never does an MX lookup, or an A lookup. Instead, it does an ANY lookup, which I suppose means its spends less time looking up DNS, so there's a performance benefit. But there is no requirement for DNS servers to respond to an ANY query, and no requirement with respect to what the response to an ANY query should contain. So if you're sending mail to a domain that does not respond to ANY requests with the MX or A records, your mail won't go nowhere.

What prompted me to write this today, is the way RBLs are done. Instead, you rely on an external program (rblsmtp) to accept the SMTP connection first, do the RBL check and pass it on to qmail if it passes. This means that qmail never knows about mail that got rejected, and consequently it never logs that information. So when your legitimate mail is getting rejected because of RBL issues, you just don't know it, unless the sender gets a bounce (which isn't a given) and lets you know. Today I had an issue where a client was getting mail a day after it was sent. The headers show it was bouncing around in the sender's solution (it's a big one, so multiple servers). Turns out the problem was that the client had SORBS in their RBLs, and the sender's servers were listed there. If that fact had been logged, it would have been quick and easy to see what the problem was, but of course there's no trace of that in the logs.

It has many other shortcomings and odd behaviours like treating 5xx errors as 4xx, so your mail sits in the queue for the default 7 days, hard-wiring destination information at submission time, and lots more.

Fortunately Plesk supports Postfix these days. Makes life easier.

Reason enough, I'd say.
I'm probably going to stick with web-based for now.... maintaining two mailboxes (one for Windows and one for Linux) gets tedious.

lol

RAS

 

[koffiejunkie]

Yeah, there's little point in rolling your own (from a technical perspective at least, privacy is another matter) for so few boxes.

 

[axelblue]

A feud against qmail maybe?

 

[koffiejunkie]

feud is maybe a strong word. Or maybe not? It's justified.