Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Programming IT Technology

Qmail At 10 Years — Reflections On Security 304

Posted by kdawson from the eliminating-code dept.
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."
This discussion has been archived. No new comments can be posted.

Qmail At 10 Years — Reflections On Security More

Qmail At 10 Years — Reflections On Security

Comments Filter:

  • license (Score:5, Informative)

    by raffe ( 28595 ) * on Tuesday November 06, 2007 @03:34AM (#21252141) Journal
    The good thing is that is easy to work with and works really good. The bad thing is that the license is NOT FOSS. Sure, you can see the code and modify it but....from authors site: [cr.yp.to]

    If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute.

    • Re: It works really well? was: license (Score:3, Informative)

      by Anonymous Coward

      The good thing is that is easy to work with and works really good.
      Amazingly, this is already flamebait. Yes, some people like it. No, other people absolute despise the djb-preferred way of doing things. Me, I'm one of those heretical djb-dislikers. I'm not saying you can't have your preferences, though; I am pointing out they're not universal. If you want the lowdown on large-scale qmail deployments today, ask NANAE.

    • Re:license (Score:5, Informative)

      by Znork ( 31774 ) on Tuesday November 06, 2007 @03:49AM (#21252221)
      "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.

      • Re: (Score:3, Informative)

        by einhverfr ( 238914 )
        I run Qmail still. I intend to move to Postfix fairly soon.

        There is only *one* reasonable advantage of Qmail, that the security engineering is one of the best I have seen (there is still room for improvement, for example a missing rcpthosts file should not turn a SMTP server into an open relay-- it is better to fail to safe conditions and reject everything).

        The major disadvantages are:
        1) I don't see any attempts by DJB to modernize the software. I would therefore suggest that the project has been orphane

    • Re:license (Score:5, Interesting)

      by larien ( 5608 ) on Tuesday November 06, 2007 @03:52AM (#21252243) Homepage Journal
      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.

      • Re: (Score:3, Interesting)

        by ta bu shi da yu ( 687699 )
        And thus the fallacy of "super-security". Security is only as good as what it allows a user to do. Sure, my computer will be secure if I put in a locked room with no access to the Internet, but it wouldn't be very useful.

        If the program is not functional, it doesn't matter how secure it is.

        That said, qmail is actually still pretty useful. However, pride cometh before a fall. The author's arrogance is going to let him down one day.

        • Re:license (Score:5, Interesting)

          by MichaelSmith ( 789609 ) on Tuesday November 06, 2007 @04:14AM (#21252331) Homepage Journal

          If the program is not functional, it doesn't matter how secure it is.

          In wonder how much of the worlds spam traffic is a result of qmail sending bounces from a different socket connection and process, instead of sending the response back through the connection which the message arrived in.

          But yeah it is very secure. Back when I first ran servers on the internet I bought a book on configuring sendmail. The ultimate conclusion in the book was to run qmail.

          • Re:license (Score:5, Interesting)

            by Antique Geekmeister ( 740220 ) on Tuesday November 06, 2007 @05:10AM (#21252611)
            Not much. Most of it, according to the last numbers I saw from the notes of the MIT Spam Conference, is rootkitted Windows boxes. There are just too many of them and it's just too easy to get more for any such operational feature of the servers themselves to make much of a dent.

            I agree that sendmail was horrid to configure. The m4 wrappers have made it better, and Postfix provides an easy to configure tool that actually allows you to rebundle it with the configurations you want. Dan Bernstein's precious ideas of no documentation, his own peculiar and poorly explained licensing, no publication of forks of his code, and mixing the binaries in with the mail spool itself for various reasons are so nasty that many of us working with open source won't touch his utilities.

            • Re:license (Score:5, Interesting)

              by Ed Avis ( 5917 ) <ed@membled.com> on Tuesday November 06, 2007 @06:31AM (#21252903) Homepage
              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.
              • Ahh, I see your point. SPF version one is even better that way, by dropping it at the "FROM" line for the bounce address before even getting to the "From:" line and bouncing back to a forged target. That's probably a bigger advantage during a big email worm attack, rather than during a spam attack. But I see your point.

                • Re: (Score:3, Informative)

                  by gmack ( 197796 )
                  The lack of SPF should be no excuse to allow for a broken mail server implementation. When I set up a server the ability for a user to gain a shell on the system is only one of the forms of security I look at. I also need to consider if any of the resources on my machine can be used by an outside to inflict harm on other servers. I need to make sure that my name servers can't be used for a reflector attack, my CGI scripts can't be used to send email to other people and my email server can't be used to re
                  • Oh, that's "outside the scope" of the Qmail security, just like what chunk of the filesystem software lives on is "outside the scope" of any of Dan Bernstein's packages. By focusing on a particular, small, tractable problem, and then stomping on everyone else's conventions, he makes very "secure" packages that leave the other problems "to the reader". Bernstein doesn't want to play there, and doesn't allow repackaging, so he will never have to.

                  • Re: (Score:3, Insightful)

                    by Antique Geekmeister ( 740220 )
                    Also note: bouncing undeliverable email is part of the specification for SMTP, because mis-addressed or randomly guessed email is indistinguishable from temporarily undeliverable email. If you don't bounce it, the sender (who may be legitimate!) has no way to know it hasn't arrived. Dropping it on the floor becomes a real problem.

                    What you've described as an open relay really isn't: it's a "Joe Job", a forgery pretending to be from somewhere else, exactly what SPF was designed to block. Now, *throttling* suc

                    • Re: (Score:2)

                      by gmack ( 197796 )

                      What you've described as an open relay really isn't: it's a "Joe Job", a forgery pretending to be from somewhere else, exactly what SPF was designed to block. Now, *throttling* such connections seems completely reasonable, but as someone who's run SMTP servers, I submit to you that discarding the messages silently is not.

                      How many SMTP servers could you have possibly run if you didn't know that it's possible for the server to refuse the email in the first place and let the SENDING mail server handle the

            • Re:license (Score:5, Informative)

              by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Tuesday November 06, 2007 @10:06AM (#21254443) Homepage
              No documentation?? Every executable has a man page, even executables that the system runs (e.g. qmail-local or qmail-remote).
              His licensing isn't poorly explained. But then again, you can't run 'man' so no wonder you couldn't Google for "djb licensing" and find http://cr.yp.to/distributors.html [cr.yp.to]
              Your third allegation was true until the publication of this PDF which you obviously didn't read since it included a dedication of qmail to the public domain.
              The binaries aren't "mixed in with the mail spool". Binaries are in /var/qmail/bin, the queue is in /var/qmail/queue.

              1 for 4. 25%. That's a failing grade in every school I know of.

      • Re:license (Score:4, Insightful)

        by Carewolf ( 581105 ) on Tuesday November 06, 2007 @05:52AM (#21252771) Homepage
        Seriously if the user has subscribed to multiple mailing lists and the same mail is send to more than one of them he SHOULD get more than one copy.

        It is incredibly confusing when some stupid mail-provider along the way decides to snuff one copy. This means the mail doesn't appear where it should in my email-program. Each mail the the different mailing list creates a separate thread of responses WITHIN that mailing-list. That is TWO not ONE, but TWO different discussion threads, which should be represented with two entries in you email program.

        • Seriously if the user has subscribed to multiple mailing lists and the same mail is send to more than one of them he SHOULD get more than one copy.

          Group alias != mailing list. If those multiple copies are the result of different Message-IDs, then you should get multiple copies. However, if your CEO sends out an internal announcement and copies five distribution groups that you're a member of then you'll get only one message since that's the equivalent of doing a "RCPT TO: <you@yourdomain.com>" five times.

        • Only if they're actually different messages.

          If they're the exact same message just relayed to you twice, then it doesn't make sense to deliver two copies; you should get one -- and the problem you're describing regarding filing is a MUA one, not an MTA issue. (IMO, a good MUA would let you have the same message in two views/folders, and show it in multiple threaded discussions if it's referred to there.)

          But anyway, aside from that, I agree that qmail sucks and I hate it for many reasons besides its handling
      • Sounds like someone has a bad MUA behind their MTA. Upgrade to Cyrus IMAP. It's very smart and culls duplicates by message ID with a sliding window, tunable by the administrator.

        This MTA behaviour is, like it or not, the correct behaviour at the MTA level. Postfix (my secure MTA choice for the past 9 years, and [IMO] a far superior one to Qmail) behaves identically regarding duplicates, as does every other MTA I've looked at. I wouldn't be surprised if this was written up in an RFC on SMTP as the correc

    • Re: (Score:3, Interesting)

      by Asmodai ( 13932 )

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

      Last time I had to reconstruct a particular email's flow through various MTAs including Qmail ended at the Qmail MTA since it the log files it uses offer little to system administrators to do proper troubleshooting.

      That alone is one major reason to never ever consider it for production use.

    • Qmail going public domain? (Score:5, Interesting)

      by Bogtha ( 906264 ) on Tuesday November 06, 2007 @05:07AM (#21252591)

      The bad thing is that the license is NOT FOSS.

      Actually, that might be changing in the immediate future. Check out the slides to go with this talk [cr.yp.to], in particular, page 10 where there's a timeline including:

      2007.11: $500 -> $1000;
      qmail placed into public domain.

      • Re:Qmail going public domain? (Score:5, Informative)

        by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Tuesday November 06, 2007 @10:09AM (#21254473) Homepage
        I can confirm this. djb send me, John Levine and Dave Sill (prominent qmail book authors) an email saying that he was going to put qmail into the public domain.
    • The good thing is that is easy to work with and works really good.

      It is an awful package to work with. If you want to do anything (like, say, IPv6 support) beyond the very, very basic things that were coded in qmail many years ago, you have to apply dubious thrid-party patches. Patches that are not coordinated, patches that conflict with each other, patches that introduce nasty bugs.

      qmail configuration files are cryptic (though, to be fair, not nearly as bad as Sendmail's config files). You have t

  • Good article (Score:5, Informative)

    by BadAnalogyGuy ( 945258 ) <BadAnalogyGuy@gmail.com> on Tuesday November 06, 2007 @03:37AM (#21252157)
    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!

    • Re: (Score:2)

      by zootm ( 850416 )

      His discussion of running untrusted code in "prisons" is interesting, and I wonder what, if any, accomodation for this type of programming Windows has.

      Windows Vista introduced Protected Mode [msdn.com] for IE, which presumably does this sort of thing. I assume this sort of sandboxing can be applied to other processes too, but I've not looked into it.

    • I don't usually see much on real software development and design here (outside of book reviews).

      While some of the things are "Duh!!" people don't think of it. Many of the metrics programmer skill is based on LOC and bugs per LOC. This type of metric is counterproductive. Articles on the subject correctly reward low bug count more than LOC. But none of this takes into account the efficiency of the code, therefore encourages slow code with no bugs, and lots of lines. He is right, I think some developers (in

  • Comment removed (Score:3, Informative)

    by account_deleted ( 4530225 ) on Tuesday November 06, 2007 @03:53AM (#21252249)
    Comment removed based on user account deletion

    • I'd use Qmail, except that the licence means that in order for Qmail to scale, it has to be patched about fifteen squillion times over ... all thanks to the restrictive licence.

      Seeing that netqmail is distributed legally as a qmail distribution plus patches with a script which applies the patches, I wonder if I could get away with releasing a patched qmail as a repository in a DSCM tool like mercurial [selenic.com] since that just maintains the base version plus optional patches.

    • Re: (Score:2, Informative)

      by Gricey ( 154787 )
      I heard Yahoo! use it... or a derivative.

      I used it in an ISP environment but at a certain point it becomes impossible to manage. The qmail queue is like a tub of nitroglycerine - fine, but if you touch it, it explodes.

      Qmails strength its its simplicity. It then achieves security because it is a simple program. For small mail installations it is fine, high performance, small footprint, etc. Each component part is easy to debug.

      It becomes unwieldily when you need to do things which aren't simple, queue ma

    • Re: (Score:2, Funny)

      by aproposofwhat ( 1019098 )
      Yes - Yahoo! use it (or so the headers report).

      I've encountered problems with users sending to multiple recipients in the same domain from a Yahoo! account, where Qmail sends the email not just once, but N times (where N is the number of users), resulting in N^2 emails being processed by the recieving server.

      I conclude from this behaviour that Qmail is fundamentally broken, and am a firm believer in Postfix (all hail the mighty Big Blue!).

      :P

    • Re: (Score:3, Informative)

      by discord5 ( 798235 )

      Does anybody run an ISP mail system with Qmail featuring predominately as MTA of choice?

      At my previous job we used to run qmail for our mailhosting boxes. I can tell you that we were really happy with qmail back then, with the right patches it can be a really flexible mailserver, and once you're used to how it works you'll be in SMTP bliss. However, when you need functionality that isn't provided by qmail, you're doing one (or some) of the following:

      • patching qmail, recompiling, testing, deploying
      • writi
    • Does anybody run an ISP mail system with Qmail featuring predominately as MTA of choice?

      RTFA: section 1.2 lists big users (source: qmail.org).
    • Rediffmail uses qmail. 60M users and counting.

  • Security by not evolving (Score:5, Insightful)

    by gullevek ( 174152 ) on Tuesday November 06, 2007 @04:14AM (#21252333) Homepage Journal
    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.
    • EXACTLY. I couldn't have said it better myself.

      After taking a peek a qmail once, I ran the hell away from it. I've used courier-mta in the past and these days I use postfix and couldn't be happier.

  • The patches make it still worthwhile (Score:3, Informative)

    by rainer_d ( 115765 ) on Tuesday November 06, 2007 @04:34AM (#21252427) Homepage
    Bill Shupp's patch plus Matt Simerson's Mail-Toaster Perl-library still make a difference.
    With postfix or sendmail, you've got to write all the provisioning-tools yourself, but qmail+vpopmail+qmailadmin delivers something out-of-the-box.

    http://www.shupp.org/ [shupp.org]
    http://mail-toaster.org/ [mail-toaster.org]

  • In the PDF at the end of section four he talks about making compromises in the design of the configuration files and the inadvisability of working around file system problems. I can't quote it because my PDF reader is doing strange things with selection but it occurred to be that DJB has some approaches to software in common with Hans Reiser, and that maybe DJB is the right person to drive reiserfs development in the future.

  • One of the most widely used ??? (Score:4, Informative)

    by inflex ( 123318 ) on Tuesday November 06, 2007 @04:58AM (#21252551) Homepage Journal
    Where did the submitter get their information from for saying that it's one of the most widely used mail servers ? I suppose if you "widen" your limits a fair way it could come in as being moderately popular.

    Sendmail, Postfix, Exchange... sure, they're up there in the high levels.

    Anyhow, would love to see a site/page showing the breakdown of mail servers around the net.

    • Re: (Score:2, Informative)

      by wfWebber ( 715881 )
      There, Googled it for ya:

      http://www.securityspace.com/s_survey/data/man.200710/mxsurvey.html [securityspace.com]

      And, at 0.17%, I'd say it wasn't as widely used as the poster wants us to think.

      • Re: (Score:2, Informative)

        by tokul ( 682258 )

        Server provided banner - 1,521,596 - 85.95%
        Server banner identifies software in use - 921,048 - 52.03%

        Qmail does not provide banner that allows to identify software. 0.17% is for Qmail toaster.

      • Re: (Score:2, Informative)

        by thanosk ( 946232 )
        Well the way that survey was conducted it relies on the 220 answer from the MTA
        to identify which Mail server it is.
        Qmail does NOT identify itself and as a result it cannot be counted using this method

        Also note that for only 52% of the queried MTA they were able to determine the
        software used.

        • Re: (Score:2)

          by inflex ( 123318 )
          So... qmail is like the 'dark matter' of the internet - people postulate it's there but we can't directly detect it ;)

  • Secure programming by DJB (Score:5, Insightful)

    by Gadzinka ( 256729 ) <rrw@hell.pl> on Tuesday November 06, 2007 @05:17AM (#21252635) Journal
    The programming model used by DJB is more or less:

    Implement only a subset of protocols, ignore the parts that you don't like, or might be insecure or are too boring to implement. Bonus points if you ignore actual features depended on by the users. Double bonus, if you manage to make it non interoperable by nazi-strict implementation of protocol, ignoring the rule ,,be strict as possible when sending, and liberal as possible when receiving''. If you can destroy other systems functionality especially designed for email (like multiple mx-es?), huuuge karma boost.

    Then refuse to implement needed features, pointing to third parties and their patches, and offer a prize for successful hack of your software. And ignore the insecurity of the patches. They're third party, after all.

    Robert

    PS I was so glad when some mature alternatives to sendmail and qmail apeared...

  • I just love qmail (Score:5, Interesting)

    by deniable ( 76198 ) on Tuesday November 06, 2007 @05:21AM (#21252657)
    I was in a weird situation where there were two of us looking after a company part time. The other guy, a typical djb fanboy, replaced *most*[1] of exim with qmail, vpopmail, and daemontools. Oh what fun this was when he was 'unavailable.' The included 'docs' were garbage. Here's some fun questions for the audience:
    1. How do you start / stop your MTA? /etc/init.d/... or delete a file and recreate it to restart.
    2. How do you configure software? Config files or adding and removing files from a magic directory?
    3. How do you kick the mail queue? Buggered if I can remember.

    Having a few years of experience looking after various 'nixes is nothing to being thrown at djb's stuff without warning. Add to this the attitude from the fanboys I've met [2] and I hate anything touched by djb. The other fun thing I can remember from some doc was djb's suggested solution to one problem was to change fork().

    [1] mailq ran, but obviously freaked out.
    [2] The worst examples of the stereotype, however, I've seen stuff posted online from some very nice people. My sample size was small but annoying.

    • Re: (Score:2, Interesting)

      by gwynevans ( 751695 )
      Well, I've got to say that I have found daemontools to be rather useful in a few scenario's where I need to have some controllable, 'always-up' processes. As for qmail, however, while I've not needed to use it, I have looked at it & while it did look useful back at the start, even then it seemed to me that djb could have done with a little more 'third-party' input to provide a less 'focused' view...

      • Re: (Score:3, Insightful)

        by deniable ( 76198 )
        I don't doubt the usefulness of daemontools, it's just that if you haven't seen its unique way of doing things you wouldn't believe it. Who buries a service startup in a combination of inittab and the /srv (?) directory? Once you know, it isn't a problem, but when someone 'forgets' to tell you, it can be quite frustrating.
        • And refuses to document it. Don't forget that DJB's infamous "LOC" or lines of code tends to leave out things like documentation, configuration examples, software installers that put things in the right places, or his other bugaboo, "parsers" to pre-test the configuration files and make sure they're valid.
        • > Who buries a service startup in a combination of inittab and the /srv (?) directory?

          Well, I hate it when someone starts daemontools from inittab.
          I usually create a normal startupscript. The BSDs I use don't have inittab anyway.
          The directory is called "service", in FreeBSD-land usually ln'ed to /var/service, where again the symlinks to the supervise-directories sit.
          FreeBSD also has a plugin-mechanism for mail-related commands. If setup correctly, "mailq" calls qmail-qstat.
          Obviously, your guy forgot to d

    • Re: (Score:2, Informative)

      by tokul ( 682258 )
      > 1. How do you start / stop your MTA? /etc/init.d/... or delete a file and recreate it to restart.

      http://cr.yp.to/daemontools/svc.html [cr.yp.to]

      svc -d /service/qmail - stops
      svc -u /service/qmail - starts
      svc -t /service/qmail - terminates the service and daemontools restart it.

      > 2. How do you configure software? Config files or adding and removing files from a magic directory?

      http://www.qmail.org/qmail-manual-html/man5/qmail-control.html [qmail.org]

      > 3. How do you kick the mail queue? Buggered if I can remember.

      send ALR
    • Although I appreciate your frustration, anyone who's worked both with and without init.d structures has been through this before.

      That said, most qmail installations don't need restarting for any reason for many moons, so unless you were fiddling with it, or it was improperly configured in the first place (both not a fault of daemontools or qmail itself), then it probably isn't even relevant.

  • security is paramount (Score:5, Insightful)

    by Edgewize ( 262271 ) on Tuesday November 06, 2007 @05:50AM (#21252763)
    Regardless of whatever else you might think of him or his software, DJB is a promoter of "security at any cost", for which everyone should give him some respect. If there's anything we should have learned in the past ten years, it's that you can't half-ass security.

    Too much software is written as if security concerns are on equal footing with features and performance. That should never be true. If your program deals with untrusted input and has access to sensitive information, then security must be the primary concern during the entire development process. Security is not something that you can "patch in" after the architecture is settled.

    There can be no trade-offs when it comes to core internet services. If one mail server is 10x faster than another but also contains a remote execution exploit, it is not 10x better -- it is useless.

    You can debate DJB's personal approach to security, but you cannot fault his priorities.
    • You can debate DJB's personal approach to security, but you cannot fault his priorities.

      While his emphasis on security is commendable, the various problems with qmail (as others have pointed out) make it less or not at all usable. If the secure software isn't used, nobody wins. To put it differently, he places usability at such a low level that the security bonus of his software is outweighed. In the end, it does make his priorities appear questionable.

  • Qmail -- whatever its security merits, and it does have some -- is not suitable for use on the public Internet because it fails to comply with not only de jure standards (RFCs) but de facto standards (best practices). The author has refused to correct these defects -- which is certainly his prerogative as an author, but has as a byproduct serious operational impact on not only users of the package, but other mail server operators who communicate with those run by users of the package.

    It's my professional

  • Of course it's secure - it hardly does anything. To even get the most rudimentary features a mail server needs to have, you have to patch the living daylights out of it and link it up with loads of third party software. You end up losing the security anyway when you add these features. It's not a usable mail server in it's native form for most companies - it's just far too basic and takes too long to configure for most real-world setups.

    Look at how much extra stuff and TIME it takes to get a small qmail bas
    • I knew there would be a day when a Windows MTA would be compared to Qmail. I didn't think I'd live to see it- but I knew it would happen.

      Let's forget for a moment that Qmail (or sendmail/postfix) takes a long time to setup.

      And let's remember that in the big-dog multi domain server world, a Windows server fails.

      It takes me a about a day (with testing and hardware verification) to get a traditional MTA up and running for multi domain use- complete with on the fly virus scanning and spam filtering (at zero sof

      • Re: (Score:2)

        by nmg196 ( 184961 ) *
        > And let's remember that in the big-dog multi domain server world, a Windows server fails.

        Er no! It certainly doesn't. Millions of companies use Windows mail servers with no problems or complaints. It's only linux fanboys that think that Windows keeps crashing. Usually that's because they don't actually use it themselves and don't really have a clue if it crashes often or not. Personally, I've never seen a blue screen of death in my entire life. I've never had to reboot a server because it's just crashe
        • Well not to enter into a personal discourse...

          And your nit picky spelling issues aside.

          1. I happen to admin 6 Windows Server 2003 boxes.

          And....

          2. I have gone a year where the *nix KERNEL didn't need an upgrade against the machine's application. Assuming the KERNEL update wasn't needed- no reboot. There's no reason to patch for local security issues on a mail server that only allows hardware terminal access (Aside from SMTP). Especially where uptime issues are considered. Additionally, I actually READ the pa
          • There's no reason to patch for local security issues on a mail server that only allows hardware terminal access (Aside from SMTP).

            Well that's just silly. All you need is one remote exploit that gives a user access to a non-privileged shell, and you're boned. Local exploits are only local as long as there are no remote exploits...
        • > And let's remember that in the big-dog multi domain server world, a Windows server fails.

          ---Er no! It certainly doesn't. Millions of companies use Windows mail servers with no problems or complaints. It's only linux fanboys that think that Windows keeps crashing. Usually that's because they don't actually use it themselves and don't really have a clue if it crashes often or not. Personally, I've never seen a blue screen of death in my entire life. I've never had to reboot a server because it's just cra

  • Postfix makes for a good read (Score:4, Interesting)

    by andawyr ( 212118 ) on Tuesday November 06, 2007 @08:10AM (#21253355)

    A good read for anyone involved in secure development.

    You would be wanting the Postfix source code, then. I've learned a tremendous amount about how secure, well designed software can be constructed. Wietse is a very smart guy, and his code is some of the tightest code I've seen. Go through it, and you'll be a better software developer for it.

    I've never looked at the qmail code. It could be just as good, I don't know.
  • > Imagine running the jpegtopnm program in an "extreme
    > sandbox" that doesn't let the program do anything other
    > than read the JPEG le from standard input, write the
    > bitmap to standard output, and allocate a limited amount of
    > memory. Existing UNIX tools make this sandbox tolerably
    > easy for root to create:
    > ... (working on RLIMITs, do chroot, fork, setuid, etc etc)

    Hm... even if not allowing the program to reuse the filesystem and other programs in the system is tolerable, it doesn't s
    • A FreeBSD jail does almost what you ask for. It can shut off kernel commands from the get-go, stop root progression, eliminate fs mounting tricks as seen in Linux chroot, and many other nasties. In the security modes, then we get into apphend-only files and not being able to mount kernel structures.

      It really gets "nasty" for the hackers.
  • I'm kinda surprised by all the complaining in this thread. Here's a very competent software engineer who created several highly secure and useful applications that we can all use for free, and he's giving us his retrospective thoughts on the engineering choices and...

    Everyone is posting "djb sucks" and such? What a bunch of useless pricks we can be.

    DJB - thanks for qmail. It's odd but pretty cool and has never fucked up my system. And I found the paper pretty interesting.

    Cheers.

Slashdot Top Deals

"Facts are stupid things." -- President Ronald Reagan (a blooper from his speeach at the '88 GOP convention)

Close