Slashdot Mirror


Qmail At 10 Years — Reflections On Security

os2man writes "Qmail is one of the most widely used MTAs on the Net and has a solid reputation for its level of security. In 'Some thoughts on security after ten years of qmail 1.0' (PDF), Daniel J. Bernstein, reviews the history 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. A good read for anyone involved in secure development."

7 of 304 comments (clear)

  1. Good article by BadAnalogyGuy · · Score: 5, Informative

    I don't mean to be flippant, but this is a really good article. That it appears on Slashdot gives me a lot of hope that this site isn't just a hangout for system administrators but also for software engineers.

    The concepts Bernstein discusses regarding increasing security are very interesting, if not exactly obvious. Fix bugs immediately. Reduce LOCs to reduce the probability of bugs. And execute as much code as possible in untrusted mode. His discussion of running untrusted code in "prisons" is interesting, and I wonder what, if any, accomodation for this type of programming Windows has.

    It was really nice to see software engineering presented here for once. Thanks kdawson... kdawson? No way!

    1. Re:Good article by Ed+Avis · · Score: 5, Informative

      You're misunderstanding Alan Cox's message. The way djb is suggesting is to chroot() to somewhere empty and then drop root privileges so you can't chroot() again.

      (It's really unfortunate that you have to be root to chroot() to start with.)

      --
      -- Ed Avis ed@membled.com
  2. Re:license by Znork · · Score: 5, Informative

    "The good thing is that is easy to work with and works really good."

    I'd heard that it was really good too. Then I noticed that if I wanted IPv6 support I'd have to patch and compile it myself. Thanks for playing, but there are more modern secure MTA's available.

    "The bad thing is that the license is NOT FOSS."

    Yep, and that's probably why qmail ends up lacking in some areas. Perhaps it could be called a security feature, but I prefer spending time learning applications that dont depend on some single person for having any future at all.

  3. Re:license by larien · · Score: 5, Interesting
    Between the non-FOSS license and the author's enormous ego, it becomes difficult to get anything done with qmail. Sure, it's secure, but it's a pain to do certain things. One of my biggest bugbears with it was that he didn't seem to see a problem where a mail sent to multiple group aliases might end up appearing twice in users' inboxes if a user was in more than one of the lists. It caused us some confusion when we started using qmail and all responses seemed to be "why wouldn't you want multiple copies of the same mail in your inbox?".

    Yes, some of his refusal to compromise mean that qmail is still secure, but in terms of usability, it's a bitch unless you're willing to work with patches & diffs to add the functions you need.

  4. Re:File system layout standards by MichaelSmith · · Score: 5, Funny

    Geez, how about some thoughts about file system layout standards, after 10 years?

    Count yourself lucky that it doesn't all go under /djb

  5. Security by not evolving by gullevek · · Score: 5, Insightful

    if you use qmail "out of the box" it might be secure, but its not usable nowadays anymore. You often have to compile in so many patches that at the end there is no security there anymore.

    I rather start with an up to date MTA, rather then fight with something like qmail ever (EVER) again.

    Just the fact that you have a fixed layout, fixed start tools that need to be there to actually start it, etc etc makes it so horrible, that I wouldn't touch it ever again with a 100 yard pole.

    --
    "Freiheit ist immer auch die Freiheit des Andersdenkenden" - Rosa Luxemburg, 1871 - 1919
  6. Re:license by Ed+Avis · · Score: 5, Interesting

    But from an individual site's point of view, it does make a big difference to have your MTA drop incoming connections immediately on getting an invalid address, rather than accept the mail and send back a soft bounce. Lots of spam is sent to random.address@known.site in the hope of getting somewhere. While accepting these messages ties up the spammer's resources, it also ties up your machine's resources.

    --
    -- Ed Avis ed@membled.com