10 ms·

The qmail security guarantee

59 points by rishabhd 9y ago

dozzie 9y ago
Ah yes, the one that djb denied to somebody who found a resource exhaustion hole, from what I remember.
- sigzero 9y ago
  There is actually a section on the web site that addresses that one.
- X-Istence 9y ago
  > In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits.
  - fimbulvetr 9y ago
    Sounds like the no true scottsman fallacy to me.
  - kstrauser 9y ago
    That's adorably quaint. I wonder if djb still believes that's the case?
    - X-Istence 9y ago
      qmail-smtpd is a very small binary that is run per connection received through tcpserver. There is no good reason to give it even a gigabyte of ram, let alone many multiple gigs. I would say the notion that small binaries working together (the unix way) would still allow him to believe to be the case.
      - lawnchair_larry 9y ago
        Nobody "gives" set amounts of memory to their processes at all, so this thinking is backwards to begin with. The vulnerability is legitimate.
        yuubi 9y ago
        I seem to remember that the installation directions included something to limit memory size, and trying to install without reading the directions would fail well before opening a listener port.
        X-Istence 9y ago
        systemd by default limits programs to a certain amount of memory (this bit me in the ass while working on getting OpenStack running on Ubuntu 16.04, and MySQL would get killed because of memory usage). Various other systems also limit with things like /etc/login.conf on FreeBSD. There is also /etc/security/limits.conf on Linux for non-systemd stuff. Limits for memory usage/open files/things of that nature are natural. You don't want one runaway process to cause the rest of your system to OOM.
  - jwilk 9y ago
    http://www.guninski.com/qmailcrash.html http://www.guninski.com/qmailcrash.html http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html http://www.guninski.com/where_do_you_want_billg_to_go_today_...
featherverse 9y ago
According to this: https://en.wikipedia.org/wiki/Comparison_of_mail_servers https://en.wikipedia.org/wiki/Comparison_of_mail_servers qmail doesn't support SMTP over TLS or SSL. How is that "secure"?
- czep 9y ago
  Security of an email server has nothing to do with secure transport of emails. If you run qmail, nobody will ever root your server. Sure they'll be able to intercept and read your email, but they won't root your server! I did run qmail in 1998ish and it was quirky but rock solid. But that was coming from sendmail, which I'd never recommend. Now I'd say postfix is the way to go: quite secure and fully TLS capable.
- geocar 9y ago
  Well, if you sent an email to `|program` it didn't execute program. Seriously[1] [1]: https://www.tenable.com/plugins/index.php?view=single&id=10261 https://www.tenable.com/plugins/index.php?view=single&id=102... Indeed, many sysadmins of the time lauded qmail's lack of supporting "standard features" in the name of "security" which sadly was still a new concept on the Internet. Something to consider: SMTP over TLS offers some privacy and confidentiality between two mail servers that have established a trust relationship, but it offers no protection against an upstream network (who can simply fake some DNS records and get a letsencrypt certificate) or a state actor (who simply threatens the CA). I think referring to "SMTP over TLS" as "secure" is dangerous because it leads us to equate "more code" as providing security.
  - ktRolster 9y ago
    Truly, the only way to have security is to encrypt the message with the receiver's public key.
    - featherverse 9y ago
      I find it discouraging that it's almost 2018 and this function of E-mail has not been made standard in all clients yet. I understand the concerns about trust, but why not make trust the extra step for now, and make encryption the standard. And in time we can standardize trust as well. (I know it's pretty standard already but I'm thinking about 'the average user') "Well I can't trust the source so why bother with encryption" is what we have presently, and that's just ridiculous.
danilocesar 9y ago
"write bug-free code" There's no such a thing, specially when you decide it's a good idea to rewrite libc. But yeah, the "stdio seem designed to encourage bugs" phrase seems pretty correct.
- ktRolster 9y ago
  That's missing the point. You can either learn from his techniques and improve your skill, or you can argue about definitions and not improve your skill. There is no doubt that DJB has good coding skills.
- shadowsun7 9y ago
  Because we need to have a little hero-worship here: http://www.aaronsw.com/weblog/001502 http://www.aaronsw.com/weblog/001502 (see section on writing bug free code) I personally find it hopeful that such people, and such techniques, exist.
SwellJoe 9y ago
For anyone considering QMail today, don't. When QMail was initially conceived, Sendmail was king, and Sendmail was awful (from a security perspective). Today there are multiple very good alternatives to Sendmail (I've used Postfix for many years with no complaints), and QMail has seen very sparse development. While Postfix has a moderately less stellar security record, it's still pretty darned good, and still under active maintenance. Many modern mail security features are either hacked onto QMail via patches from third parties (none of whom are as famous for their security chops as djb) or completely non-existent in QMail. The number of people running it today is extremely small, so you're going to find relatively few resources about it when you run into problems (and what resources you find will be very, very, very old, in most cases). If you're wanting a similarly limited SMTP server that is under active maintenance, opensmtpd from the OpenBSD folks might be an option (though I've never used it). It, at least, has people looking at it regularly and supports basic features lacking in QMail, like encryption, without patches. QMail has a tiny but rabid following (kinda like djb himself) who settled into their beliefs about the MTA landscape in 1998 and have ignored everything that's happened since. (Funny, or maybe just odd, story: When we removed qmail-ldap, an unmaintained patched version of QMail that adds LDAP authentication, from Virtualmin, I literally had someone bringing up companies that have been out of business for more than a decade as proof that it was still in active use and we should keep maintaining support for it, even though no one has asked a question about it in our forums in eight years. It was the most bizarre technical conversation I've had in a while. I was like, "But, umm...they have no website and every mention I can find of that company is from 2006. What makes you think they're still using qmail-ldap or would care that we're removing support for it?" Then again, they also wanted to rant for a couple dozen paragraphs about gay people oppressing them in our issue tracker and for an hour or so in our IRC channel, so he may not have been entirely connected to our reality.)
- KillerDiller 9y ago
  As a hardcore qmail (and qmail-ldap) user back in the days, I can confirm that this is all accurate and correct.
  - JdeBP 9y ago
youdontknowtho 9y ago
He should... wait for it... hold... REWRITE IT IN RUST! Just kidding. The idea about mutually untrusted components is a great idea that just gets better and better all the time.
feelin_googley 9y ago
http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf
- jlgaddis 9y ago
  FYI: "Some thoughts on security after ten years of qmail 1.0" (by DJB, of course). Abstract: The qmail software package is a widely used Internet-mail transfer agent that has been covered by a security guarantee since 1997. In this paper, the qmail author reviews the his- tory and security-relevant architecture of qmail; articulates partitioning standards that qmail fails to meet; analyzes the engineering that has allowed qmail to survive this failure; and draws various conclusions regarding the future of secure programming.
linsomniac 9y ago
"It's too bad DJB is so abrasive, because he has some good ideas and nobody will listen to him because of it." This came from someone fairly famous, but I didn't ask to quote him so I won't. His name is on a definitive book in his field. Personality is important.
- forapurpose 9y ago
  > Personality is important. I agree, but I wonder how it factors in. Compare DJB to Linus Torvalds or Theo de Raadt or Steve Jobs or Steve Balmer or Travis Kalanick, as examples with a variety of outcomes (and I'm not trying hard to come up with those names; there are many more out there). Maybe the determining factor is something other than abrasiveness, maybe it's just balanced against demand for your project or other factors, maybe it depends on the market segment you're operating in - or maybe it's circumstance and luck that really matter.
  - rtpg 9y ago
    I don't think that's the right way of looking at this. It's hard to deny that Linus would not lose influence by having a modicum of self control and not saying someone should have been aborted because of a bad patch. Sure, maybe DJB won't become uber-famous by being nicer, but at the very least he wouldn't generate these sorts of conversations every time he writes something. There's so many documented cases of people saying they don't want to work with Torvalds or Kalanick. In exchange for what? Being able to be some massive edgelord? If even a single good core Linux developer would otherwise be contributing, Torvald's abrassiveness would be a net negative I think.
    - adamkruszewski 9y ago
      But no one have mentioned licensing issues. Linux or *BSD do have quite liberal licenses comparing to QMail license or at least last time I read it, it was quite years ago. I have maintained my own set of patches with some of my own additions but it was a hurdle and it didn't make exchanging of those easy. My point it, maybe it is not only abrassiveness issue?
linsomniac 9y ago
I started using qmail in 1996-ish, and was a pretty big fan for a while. I wouldn't use it at this point though, it really has languished and is, IMHO, totally unusable without a lot of dicking around to get the right set of patches and the like. He kind of lost me when AOL increased their MX record to be larger than UDP could handle in a single packet. He stood firm that AOL was doing it wrong, meanwhile my users didn't care about what the RFCs said, they just wanted to e-mail their grandma like all their friends could. The qmail community collected a lot of people with similar personalities and I got tired of it. These days, I'm pretty happy with Postfix, and it has things a modern e-mail servers needs, supported in the core rather than requiring a ton of patches that haven't been eyeballed by the author.
jedisct1 9y ago
I still run qmail (in addition to postfix and opensmtpd) for one thing: ezmlm-idx. Is there something I can replace ezmlm-idx with, that would seamlessly import all the lists, subscribers and archives?
- seschwar 9y ago
  http://mlmmj.org/ http://mlmmj.org/ claims to be heavily inspired by ezmlm. I haven't used either so I don't know how well it works as a replacement, but it might be worth a look.
pilif 9y ago
Back in 2001 when I was investigating the dependencies I wanted to take on for a webmail service, qmail was on my list of possible candidates, also because of this security guarantee. However, I quickly learned that while that security guarantee probably was a good thing and valid, practically nobody was actually running vanilla qmail because it also had a very limited feature set. What people were running was a mixture of qmail with various patches of their own or downloaded from somewhere on the internet, none of them properly maintained and all of them likely full of security issues nobody was caring about. However, if you asked them what they were running, they were still saying qmail and they were still quoting the security guarantee which at that point was completely worthless. In my case I went with a "batteries included" solution that didn't provide a security guarantee but also came with all the features I needed built-in and which also got regular updates by its maintainer. Not needing to add third-party patches was more important than the design and guarantees of the base-product because the moment you patch the thing yourself, you own it and all the possibly given guarantees and positive aspects of the underlying architecture were null and void. The solution I went with in the end was exim and it still is the MTA on our central relay. It had more security issues than qmail or postfix over its history, but I also do not need to patch it for my solution with users-in-SQL. Meaning that whenever a security issues is found, I can rely on my distro to provide updates which will fix the issue. qmail and postfix provided a better security picture out-of-the-box but both would have needed manual patching for my needs which I deemed too risky. There is no question that the less functionality offered by a product, the more secure it is. If you don't need any features, then by all means go with a product that has no features and you'll automatically enjoy the best security: Features breed complexity. Complexity breeds security issues. But if you absolutely need a list of features that is offered by a tool, be careful in weighing up the risks of manually adding those additional, things compared to going with the full solution where somebody else is taking care of the security picture.
- geocar 9y ago
  > which at that point was completely worthless. I disagree. qmail's design decisions meant that a lot of the patches were insulated even from themselves. It also made me a better programmer and a better sysadmin.
eriksjolund 9y ago
The qmail security guarantee was challenging. I made it a try and actually I found a bug http://adivo.se/qmail/qmail-1.03.qmail_local_c.patch http://adivo.se/qmail/qmail-1.03.qmail_local_c.patch but it was no security bug. Unfortunately I can't find any mailing list archive of qmail where the bug was discussed.
- JdeBP 9y ago
  You've been on http://jdebp.eu./FGA/qmail-problems.html http://jdebp.eu./FGA/qmail-problems.html for about 14 years, and your patch was one of the ones that went into netqmail.
  - eriksjolund 9y ago
    I'm glad that the patch came into use.

59 points by rishabhd 9y ago

dozzie 9y ago

Ah yes, the one that djb denied to somebody who found a resource exhaustion hole, from what I remember.

sigzero 9y ago
There is actually a section on the web site that addresses that one.
X-Istence 9y ago
> In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits.
- fimbulvetr 9y ago
  Sounds like the no true scottsman fallacy to me.
- kstrauser 9y ago
  That's adorably quaint. I wonder if djb still believes that's the case?
  - X-Istence 9y ago
    qmail-smtpd is a very small binary that is run per connection received through tcpserver. There is no good reason to give it even a gigabyte of ram, let alone many multiple gigs. I would say the notion that small binaries working together (the unix way) would still allow him to believe to be the case.
    - lawnchair_larry 9y ago
      Nobody "gives" set amounts of memory to their processes at all, so this thinking is backwards to begin with. The vulnerability is legitimate.
      - yuubi 9y ago
        I seem to remember that the installation directions included something to limit memory size, and trying to install without reading the directions would fail well before opening a listener port.
      - X-Istence 9y ago
        systemd by default limits programs to a certain amount of memory (this bit me in the ass while working on getting OpenStack running on Ubuntu 16.04, and MySQL would get killed because of memory usage). Various other systems also limit with things like /etc/login.conf on FreeBSD. There is also /etc/security/limits.conf on Linux for non-systemd stuff. Limits for memory usage/open files/things of that nature are natural. You don't want one runaway process to cause the rest of your system to OOM.
- jwilk 9y ago
  http://www.guninski.com/qmailcrash.html http://www.guninski.com/qmailcrash.html http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html http://www.guninski.com/where_do_you_want_billg_to_go_today_...

featherverse 9y ago

According to this: https://en.wikipedia.org/wiki/Comparison_of_mail_servers https://en.wikipedia.org/wiki/Comparison_of_mail_servers qmail doesn't support SMTP over TLS or SSL. How is that "secure"?

czep 9y ago
Security of an email server has nothing to do with secure transport of emails. If you run qmail, nobody will ever root your server. Sure they'll be able to intercept and read your email, but they won't root your server! I did run qmail in 1998ish and it was quirky but rock solid. But that was coming from sendmail, which I'd never recommend. Now I'd say postfix is the way to go: quite secure and fully TLS capable.
geocar 9y ago
Well, if you sent an email to `|program` it didn't execute program. Seriously[1] [1]: https://www.tenable.com/plugins/index.php?view=single&id=10261 https://www.tenable.com/plugins/index.php?view=single&id=102... Indeed, many sysadmins of the time lauded qmail's lack of supporting "standard features" in the name of "security" which sadly was still a new concept on the Internet. Something to consider: SMTP over TLS offers some privacy and confidentiality between two mail servers that have established a trust relationship, but it offers no protection against an upstream network (who can simply fake some DNS records and get a letsencrypt certificate) or a state actor (who simply threatens the CA). I think referring to "SMTP over TLS" as "secure" is dangerous because it leads us to equate "more code" as providing security.
- ktRolster 9y ago
  Truly, the only way to have security is to encrypt the message with the receiver's public key.
  - featherverse 9y ago
    I find it discouraging that it's almost 2018 and this function of E-mail has not been made standard in all clients yet. I understand the concerns about trust, but why not make trust the extra step for now, and make encryption the standard. And in time we can standardize trust as well. (I know it's pretty standard already but I'm thinking about 'the average user') "Well I can't trust the source so why bother with encryption" is what we have presently, and that's just ridiculous.

danilocesar 9y ago

"write bug-free code" There's no such a thing, specially when you decide it's a good idea to rewrite libc. But yeah, the "stdio seem designed to encourage bugs" phrase seems pretty correct.

ktRolster 9y ago
That's missing the point. You can either learn from his techniques and improve your skill, or you can argue about definitions and not improve your skill. There is no doubt that DJB has good coding skills.
shadowsun7 9y ago
Because we need to have a little hero-worship here: http://www.aaronsw.com/weblog/001502 http://www.aaronsw.com/weblog/001502 (see section on writing bug free code) I personally find it hopeful that such people, and such techniques, exist.

SwellJoe 9y ago

For anyone considering QMail today, don't. When QMail was initially conceived, Sendmail was king, and Sendmail was awful (from a security perspective). Today there are multiple very good alternatives to Sendmail (I've used Postfix for many years with no complaints), and QMail has seen very sparse development. While Postfix has a moderately less stellar security record, it's still pretty darned good, and still under active maintenance. Many modern mail security features are either hacked onto QMail via patches from third parties (none of whom are as famous for their security chops as djb) or completely non-existent in QMail. The number of people running it today is extremely small, so you're going to find relatively few resources about it when you run into problems (and what resources you find will be very, very, very old, in most cases). If you're wanting a similarly limited SMTP server that is under active maintenance, opensmtpd from the OpenBSD folks might be an option (though I've never used it). It, at least, has people looking at it regularly and supports basic features lacking in QMail, like encryption, without patches. QMail has a tiny but rabid following (kinda like djb himself) who settled into their beliefs about the MTA landscape in 1998 and have ignored everything that's happened since. (Funny, or maybe just odd, story: When we removed qmail-ldap, an unmaintained patched version of QMail that adds LDAP authentication, from Virtualmin, I literally had someone bringing up companies that have been out of business for more than a decade as proof that it was still in active use and we should keep maintaining support for it, even though no one has asked a question about it in our forums in eight years. It was the most bizarre technical conversation I've had in a while. I was like, "But, umm...they have no website and every mention I can find of that company is from 2006. What makes you think they're still using qmail-ldap or would care that we're removing support for it?" Then again, they also wanted to rant for a couple dozen paragraphs about gay people oppressing them in our issue tracker and for an hour or so in our IRC channel, so he may not have been entirely connected to our reality.)

KillerDiller 9y ago
As a hardcore qmail (and qmail-ldap) user back in the days, I can confirm that this is all accurate and correct.
- JdeBP 9y ago

youdontknowtho 9y ago

He should... wait for it... hold... REWRITE IT IN RUST! Just kidding. The idea about mutually untrusted components is a great idea that just gets better and better all the time.

feelin_googley 9y ago

http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf

jlgaddis 9y ago
FYI: "Some thoughts on security after ten years of qmail 1.0" (by DJB, of course). Abstract: The qmail software package is a widely used Internet-mail transfer agent that has been covered by a security guarantee since 1997. In this paper, the qmail author reviews the his- tory and security-relevant architecture of qmail; articulates partitioning standards that qmail fails to meet; analyzes the engineering that has allowed qmail to survive this failure; and draws various conclusions regarding the future of secure programming.

linsomniac 9y ago

"It's too bad DJB is so abrasive, because he has some good ideas and nobody will listen to him because of it." This came from someone fairly famous, but I didn't ask to quote him so I won't. His name is on a definitive book in his field. Personality is important.

forapurpose 9y ago
> Personality is important. I agree, but I wonder how it factors in. Compare DJB to Linus Torvalds or Theo de Raadt or Steve Jobs or Steve Balmer or Travis Kalanick, as examples with a variety of outcomes (and I'm not trying hard to come up with those names; there are many more out there). Maybe the determining factor is something other than abrasiveness, maybe it's just balanced against demand for your project or other factors, maybe it depends on the market segment you're operating in - or maybe it's circumstance and luck that really matter.
- rtpg 9y ago
  I don't think that's the right way of looking at this. It's hard to deny that Linus would not lose influence by having a modicum of self control and not saying someone should have been aborted because of a bad patch. Sure, maybe DJB won't become uber-famous by being nicer, but at the very least he wouldn't generate these sorts of conversations every time he writes something. There's so many documented cases of people saying they don't want to work with Torvalds or Kalanick. In exchange for what? Being able to be some massive edgelord? If even a single good core Linux developer would otherwise be contributing, Torvald's abrassiveness would be a net negative I think.
  - adamkruszewski 9y ago
    But no one have mentioned licensing issues. Linux or *BSD do have quite liberal licenses comparing to QMail license or at least last time I read it, it was quite years ago. I have maintained my own set of patches with some of my own additions but it was a hurdle and it didn't make exchanging of those easy. My point it, maybe it is not only abrassiveness issue?

linsomniac 9y ago

I started using qmail in 1996-ish, and was a pretty big fan for a while. I wouldn't use it at this point though, it really has languished and is, IMHO, totally unusable without a lot of dicking around to get the right set of patches and the like. He kind of lost me when AOL increased their MX record to be larger than UDP could handle in a single packet. He stood firm that AOL was doing it wrong, meanwhile my users didn't care about what the RFCs said, they just wanted to e-mail their grandma like all their friends could. The qmail community collected a lot of people with similar personalities and I got tired of it. These days, I'm pretty happy with Postfix, and it has things a modern e-mail servers needs, supported in the core rather than requiring a ton of patches that haven't been eyeballed by the author.

jedisct1 9y ago

I still run qmail (in addition to postfix and opensmtpd) for one thing: ezmlm-idx. Is there something I can replace ezmlm-idx with, that would seamlessly import all the lists, subscribers and archives?

seschwar 9y ago
http://mlmmj.org/ http://mlmmj.org/ claims to be heavily inspired by ezmlm. I haven't used either so I don't know how well it works as a replacement, but it might be worth a look.

pilif 9y ago

Back in 2001 when I was investigating the dependencies I wanted to take on for a webmail service, qmail was on my list of possible candidates, also because of this security guarantee. However, I quickly learned that while that security guarantee probably was a good thing and valid, practically nobody was actually running vanilla qmail because it also had a very limited feature set. What people were running was a mixture of qmail with various patches of their own or downloaded from somewhere on the internet, none of them properly maintained and all of them likely full of security issues nobody was caring about. However, if you asked them what they were running, they were still saying qmail and they were still quoting the security guarantee which at that point was completely worthless. In my case I went with a "batteries included" solution that didn't provide a security guarantee but also came with all the features I needed built-in and which also got regular updates by its maintainer. Not needing to add third-party patches was more important than the design and guarantees of the base-product because the moment you patch the thing yourself, you own it and all the possibly given guarantees and positive aspects of the underlying architecture were null and void. The solution I went with in the end was exim and it still is the MTA on our central relay. It had more security issues than qmail or postfix over its history, but I also do not need to patch it for my solution with users-in-SQL. Meaning that whenever a security issues is found, I can rely on my distro to provide updates which will fix the issue. qmail and postfix provided a better security picture out-of-the-box but both would have needed manual patching for my needs which I deemed too risky. There is no question that the less functionality offered by a product, the more secure it is. If you don't need any features, then by all means go with a product that has no features and you'll automatically enjoy the best security: Features breed complexity. Complexity breeds security issues. But if you absolutely need a list of features that is offered by a tool, be careful in weighing up the risks of manually adding those additional, things compared to going with the full solution where somebody else is taking care of the security picture.

geocar 9y ago
> which at that point was completely worthless. I disagree. qmail's design decisions meant that a lot of the patches were insulated even from themselves. It also made me a better programmer and a better sysadmin.

eriksjolund 9y ago

The qmail security guarantee was challenging. I made it a try and actually I found a bug http://adivo.se/qmail/qmail-1.03.qmail_local_c.patch http://adivo.se/qmail/qmail-1.03.qmail_local_c.patch but it was no security bug. Unfortunately I can't find any mailing list archive of qmail where the bug was discussed.

JdeBP 9y ago
You've been on http://jdebp.eu./FGA/qmail-problems.html http://jdebp.eu./FGA/qmail-problems.html for about 14 years, and your patch was one of the ones that went into netqmail.
- eriksjolund 9y ago
  I'm glad that the patch came into use.