Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Qmail At 10 Years — Reflections On Security

kdawson posted more than 6 years ago | from the eliminating-code dept.

Security 304

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."

cancel ×

304 comments

Sorry! There are no comments related to the filter you selected.

pdf? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21252129)

as if link to a pdf on front page.

Re:pdf? (1, Informative)

Anonymous Coward | more than 6 years ago | (#21252337)

google html of the pdf (perhaps as bad in some ways as a pdf):

http://preview.tinyurl.com/33lvkr [tinyurl.com]

Help! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21252135)

Dear friends, my girlfriend has a problem with odor in her lady parts. It smells like rotten mackerel to be honest, and her feelings are hurt when I won't lick the damn thing. Should I break up with her just because she has a smelly pussy?
 
captcha: hormone

10 years of qmail without... (0)

Anonymous Coward | more than 6 years ago | (#21252139)

So when was the last update to the official release?

license (4, Informative)

raffe (28595) | more than 6 years ago | (#21252141)

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 (3, Informative)

Anonymous Coward | more than 6 years ago | (#21252183)

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 (5, Informative)

Znork (31774) | more than 6 years ago | (#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:license (5, Interesting)

larien (5608) | more than 6 years ago | (#21252243)

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:license (2, Interesting)

ta bu shi da yu (687699) | more than 6 years ago | (#21252269)

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 (4, Interesting)

MichaelSmith (789609) | more than 6 years ago | (#21252331)

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 (4, Interesting)

Antique Geekmeister (740220) | more than 6 years ago | (#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 (5, Interesting)

Ed Avis (5917) | more than 6 years ago | (#21252903)

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.

Re:license (1)

Antique Geekmeister (740220) | more than 6 years ago | (#21252961)

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:license (2, Informative)

gmack (197796) | more than 6 years ago | (#21253489)

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 relay.

Unpatched Qmail is a form of an open relay. A couple years after running it for the first time someone started bouncing email off it and eventually it got so bad that I had thousands of emails in my queue at any given moment. This has been the case for every customer I've run into that is using Qmail.

People need to stop referring to Qmail as "secure." It just isn't.

Re:license (1)

Antique Geekmeister (740220) | more than 6 years ago | (#21253585)

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:license (3, Insightful)

Carewolf (581105) | more than 6 years ago | (#21252771)

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.

Re:license (2, Interesting)

Asmodai (13932) | more than 6 years ago | (#21252277)

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.

Re:license (4, Interesting)

irc.goatse.cx troll (593289) | more than 6 years ago | (#21252371)

The log files are useless, last time I had to debug qmail it involved writing a bash script to race to strace as soon as the qmail process was ran (I forgot why I didn't just hook the parent process, but I digress).

Qmail going public domain? (4, Interesting)

Bogtha (906264) | more than 6 years ago | (#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:license (1)

QuietLagoon (813062) | more than 6 years ago | (#21253295)

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 to install qmail with the directory structure djb wants, otherwise you violate the license.

qmail has not seen development by the author (djb) in many years.

Look to Postfix if you want to use a simple, modern, secure and up-to-date MTA.

Good article (5, Informative)

BadAnalogyGuy (945258) | more than 6 years ago | (#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:Good article (-1, Troll)

ta bu shi da yu (687699) | more than 6 years ago | (#21252295)

He also states that you should "prohibit filesystem access: chdir and chroot to an empty directory."

Uh-huh.

"If you have the ability to use chroot() you are root. If you are root you can walk happily out of any chroot by a thousand other means."

Alan Cox, Sept 19, 2007. [kerneltrap.org]

Re:Good article (1)

HonIsCool (720634) | more than 6 years ago | (#21252345)

Drop root privileges after chroot()?

Re:Good article (5, Informative)

Ed Avis (5917) | more than 6 years ago | (#21252481)

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.)

Re:Good article (1)

ta bu shi da yu (687699) | more than 6 years ago | (#21252499)

Ah... so it appears.

Re:Good article (1)

caluml (551744) | more than 6 years ago | (#21252809)

It's also really stupid in this day and age that you need to be root to bind to Require root to bind to ports below 1024.
I'd untick it in a flash.

Re:Good article (1)

eneville (745111) | more than 6 years ago | (#21253187)

I think the openbsd installation allows www-root to bind to :80. Of course, you have the source, why don't you take a look and make the alterations, I'm all for something like a system where you put the ports you don't mind about in /proc/sys/net/ipv4/ports file or something.

Re:Good article (1)

caluml (551744) | more than 6 years ago | (#21252815)

Repeated, converting less-thans to <

It's also really stupid in this day and age that you need to be root to bind to <1024. There's just NO need for that any more that I can see. Can we get a compile time kernel option? <*> Require root to bind to ports below 1024.
I'd untick it in a flash.

PS. Postfix is much more friendly.

Re:Good article (1)

amorsen (7485) | more than 6 years ago | (#21253045)

It's also really stupid in this day and age that you need to be root to bind to <1024. There's just NO need for that any more that I can see.

You trust all your software to not try to bind to port 25 and steal your mail? Or to port 80 and deface your web site? If you trust all your software, why not just run everything as root in the first place?

Re:Good article (1)

caluml (551744) | more than 6 years ago | (#21253101)

You trust all your software to not try to bind to port 25 and steal your mail? Or to port 80 and deface your web site?
Frankly, yes. If I can't trust a Listen 80 statement in Apache, who can I trust. Plus, if something's already bound there, other things can't bind. My system boots, it starts Apache and Postfix - nothing else can bind to those ports. Also, I don't generally run software I can't "trust".

Re:Good article (0)

Anonymous Coward | more than 6 years ago | (#21253149)

Local non-root program started by malicious user is waiting and monitoring port 80, Apache crashes or restarts for some reason (like a security update), local non-root program quickly grabs port 80 and emulates Apache while presenting forged content, harvesting user credentials, etc...
 

Re:Good article (1)

caluml (551744) | more than 6 years ago | (#21253333)

Sure, if you have untrusted users on your box. Plus, you can use things like LIDS or GRsec to restrict things like what capabilities programs have. Like I say, a compile option, or possibly a sysctl entry.

Re:Good article (1)

Antique Geekmeister (740220) | more than 6 years ago | (#21253609)

And if you don't bother to install an HTTP daemon, then I get to take it away from you and you have to break mine to get your port back. That's too awkward to manage.

Re:Good article (1)

stevied (169) | more than 6 years ago | (#21252661)

Note that djb says an *empty* directory. Assuming that you can't mkdir() in that directory, then there's nowhere to move the chroot to. I presume that's why he explicitly mentioned the emptiness :)

Re:Good article (1)

ta bu shi da yu (687699) | more than 6 years ago | (#21252665)

Unless you chroot down a directory. But... I missed his original point, which was to briefly elevate privileges and then drop them.

Re:Good article (1)

Eunuchswear (210685) | more than 6 years ago | (#21252853)

Uh, if the directory is empty where can you "chroot down" to?

Re:Good article (1)

ta bu shi da yu (687699) | more than 6 years ago | (#21253105)

I could be misreading something I suppose. When I read "empty" directory, it seems to me to be a directory without any files or directories.

If you chroot to /home/test/root/ then chroot to /.. then it will chroot to /home/test.

Re:Good article (2, Informative)

Eunuchswear (210685) | more than 6 years ago | (#21253159)

No, if you chdir to /home/test/root, then chroot to /home/test/root, then chdir to .. you'll still be in /home/test/root.

From man 2 chroot:

      The .. entry in the root directory is interpreted to mean the root
      directory itself. Thus, .. cannot be used to access files outside the
      subtree rooted at the root directory.

How root gets out of a chroot is:
  1. make, or find, a directory under the current chroot
  2. chroot there, but don't chdir there
  3. now ".." in the old chroot is its real parent, not itself.


Of course DJB was suggesting that you drop root privs immediately after the chroot, so this is moot.

Re:Good article (1)

ta bu shi da yu (687699) | more than 6 years ago | (#21253407)

The superuser can escape from a 'chroot jail' by doing 'mkdir foo; chroot foo; cd ..'.

Re:Good article (-1, Flamebait)

ta bu shi da yu (687699) | more than 6 years ago | (#21253505)

How the hell is my post a troll?

Re:Good article (1)

zootm (850416) | more than 6 years ago | (#21252717)

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 too agree. (1)

www.sorehands.com (142825) | more than 6 years ago | (#21252743)

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 (including myself) have the tendency to microoptimize the interesting code.

File system layout standards (0)

Anonymous Coward | more than 6 years ago | (#21252163)

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

Re:File system layout standards (5, Funny)

MichaelSmith (789609) | more than 6 years ago | (#21252321)

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

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

Re:File system layout standards (1)

deniable (76198) | more than 6 years ago | (#21252723)

Geez, how about some thoughts about file system layout standards, after 10 years?
Count yourself lucky that it doesn't all go under /djb

That would be too obvious and useful.

Re:File system layout standards (1)

sqldr (838964) | more than 6 years ago | (#21253367)

If djb worked at a fire station:

Caller: my house is on fire!

DJB: your sprinkler system is configured wrong *click*

Secure? Ha. (-1)

Anonymous Coward | more than 6 years ago | (#21252171)

It lacks even the modern security infrastructure like STARTTLS, so what was the point again?

pfft what a joke (1, Funny)

timmarhy (659436) | more than 6 years ago | (#21252201)

yeah right qmail is so secure, because it's so horrible to use and so under featured it's not even a target.

Qmail and the patchset of doom (2, Informative)

Neo-Rio-101 (700494) | more than 6 years ago | (#21252249)

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.

Sure it may be fast and secure... but unfortuantely scalable it is not (and if it is, it is far from obvious how).
Does anybody run an ISP mail system with Qmail featuring predominately as MTA of choice?

Re:Qmail and running an ISP. (0)

Anonymous Coward | more than 6 years ago | (#21252301)

ISTR plesk, the control panel thingy that keeps quite a few low end webhosters afloat, uses qmail.

Re:Qmail and the patchset of doom (1)

MichaelSmith (789609) | more than 6 years ago | (#21252307)

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:Qmail and the patchset of doom (2, Informative)

Gricey (154787) | more than 6 years ago | (#21252543)

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 management, scaling to a godzillion users, policy based mail routing, multiple actions on a mail before its delivered, db lookups, intelligent filtering, etc. These things are either unavailable or a third party (after the fact) bolt-on.

If it's license wasn't so badly the suck, then it probably would be as current and featureful as any other MTA in wide use today. As a result of its silly license, the barrier to maintain and extend it is too high for most people and it's stuck in 1997.

-- incubus

Re:Qmail and the patchset of doom (0)

Anonymous Coward | more than 6 years ago | (#21252669)

you obviously haven't used it much. i have been using it with a database of gazillion users for many a year now in a complex deployment, and it has done fine. but whatever rocks your boat.

Re:Qmail and the patchset of doom (2, Funny)

aproposofwhat (1019098) | more than 6 years ago | (#21252613)

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:Qmail and the patchset of doom (1)

mrjackson2000 (733829) | more than 6 years ago | (#21252715)

1 patch. John Simpson [jms1.net] has made a combined patch set [jms1.net] including some of his own improvements/fixes. he also has alot of other documentation and is quite active on a couple mailing lists related to qmail.

Re:Qmail and the patchset of doom (0, Troll)

snemarch (1086057) | more than 6 years ago | (#21252725)

Ho humm, is qmail really that great? A lot of what DJB writes makes sense, but he seems to have a whole bunch of zealot followers who will flame you to death if you rise any questions about qmail stability/security. While some of the points in http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html [uni-dortmund.de] are near the point of irrelevance, it certainly still doesn't give me a lot of confidence in qmail.

Re:Qmail and the patchset of doom (2, Informative)

discord5 (798235) | more than 6 years ago | (#21253153)

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
  • writing a perl/bash/whatever script that goes somewhere in the Big Qmail Picture [nrg4u.com]
  • muttering curses and djb's name for the licensing

I can't really bring myself to bashing qmail over these things because it's served me well and I've hardly had any "unexpected" things happen to me, which is something I can't really say of other MTAs I've tried and I've never had any security problems (altough you might want to read this page [uni-dortmund.de] ). There's a lot of information available on qmail [qmail.org] , and you can check out this guide [lifewithqmail.org] (although this may now be quite dated). An indispensible tool is qmHandle [sourceforge.net] for inspecting and manipulating the qmail queue in case something did go wrong.

Finally, I have to admit that when I left that company my own mailhosting services are currently being run by postfix, simply because I don't have the time to build my own qmail packages whenever I need some feature. If you look at the postfix design, any qmail user will see similarities and the fact that you're not patching and rebuilding it whenever you need feature X sort of grows on you.

I know that if I were to start hosting a large mailserver, I'd have a hard time deciding between the two and I'd do a lot of testing before I made a choice.

Re:Qmail and the patchset of doom (1)

harmonica (29841) | more than 6 years ago | (#21253265)

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).

Which is worth more... (1, Insightful)

Anonymous Coward | more than 6 years ago | (#21252299)

...writing a navel-gazing paper after ten years or re-licensing the code so it doesn't devolve into an antiquated relic burdened with conflicting and hacked up patches just so it can be barely useful to a modern userbase? This is one more area where the licensing rubber meets the road: when you can do an "apt-get install exim4" because the license allows for modified binaries versus a download / patch / fix conflicting patches / compile / fix broken code / compile / install cycle every time you need an MTA, with future patches for missing features a guarantee, admins will eventually vote with their fingers and stop installing qmail. Much like the free software belief that draconian licensing terms will eventually be the death of the licensors' products, the lack of a license will eventually do the same to djb products. The right licensing is freedom, and freedom adds more to the vitality of a piece of software than any post-decade academic paper will ever do. I guess we should have known the academic would value publishing over community-friendly, viable, real-world-issues-comprise-more-than-security software.

Call it an experiment and warn serious users away. Or free qmail. Until then, I'll be making sure I actively migrate away from it when given the opportunity.

Security by not evolving (5, Insightful)

gullevek (174152) | more than 6 years ago | (#21252333)

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.

Re:Security by not evolving (1)

buga (314334) | more than 6 years ago | (#21252399)

I agree with the parent a hundred percent. Qmail is too much of a chore to setup and admin. And when something does go wrong, it's very hard to troubleshoot. Personally I prefer postfix anytime. I have done setups for both and just prefer the config layout for postfix. Of course you can change the postfix config layout anytime, since it's configurable.

Re:Security by not evolving (1)

fruey (563914) | more than 6 years ago | (#21252565)

I used Postfix for a long time. I'm no longer an MTA admin, but looking at QMail install procedure & Postfix procedure, I decided that Postfix was the way to go. It probably still is.

One other thing was that DJB's quirks (even if he may be right about a lot of the things he believes in) mean you have to adopt his style of doing things to get things to work. It's the same with djbdns.

The paper is still a worthwhile read though, if you're a serious software engineer you should, like him, be looking back over your last 10 years and asking yourself if you're better today, and whether you were right to adopt certain approaches.

qmail in the public domain? (1)

sekra (516756) | more than 6 years ago | (#21252419)

According to one of DJB's slides [cr.yp.to] it might happen this month that qmail will be placed into public domain [gmane.org] . I hope this will become true as it might help qmail to get rid of its obsolescence.

The patches make it still worthwhile (2, Informative)

rainer_d (115765) | more than 6 years ago | (#21252427)

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]

Re:The patches make it still worthwhile (1)

nuba (660398) | more than 6 years ago | (#21252975)

vpopmail can be used with postfix

Is a sandbox a security solution? (0, Redundant)

phoebe (196531) | more than 6 years ago | (#21252445)

So has DJB talked with Alan Cox recently?

From the article:

... bugs can compromise security. Let's see how we can fix that.
...
* Prohibit filesystem access: chdir and chroot to an empty directory.

Re:Is a sandbox a security solution? (2, Informative)

ta bu shi da yu (687699) | more than 6 years ago | (#21252675)

Already pointed this out, but DJB is just gaining access to chroot, then dropping privileges.

qmail and reiserfs (1)

MichaelSmith (789609) | more than 6 years ago | (#21252455)

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.

Re:qmail and reiserfs (1)

ta bu shi da yu (687699) | more than 6 years ago | (#21252559)

You aren't use Envince, are you? I'm having problems also.

Re:qmail and reiserfs (1)

ta bu shi da yu (687699) | more than 6 years ago | (#21252601)

If so... bug has been filed [gnome.org] .

Re:qmail and reiserfs (1)

MichaelSmith (789609) | more than 6 years ago | (#21252639)

You aren't use Envince, are you? I'm having problems also.

Yes, I am. When I select text in the right column of text the entire left column gets selected.

Re:qmail and reiserfs (1)

ta bu shi da yu (687699) | more than 6 years ago | (#21252685)

Thought so. I just filed a bug [gnome.org] about this one.

Re:qmail and reiserfs (2, Funny)

aproposofwhat (1019098) | more than 6 years ago | (#21252625)

I hope DJB's not married...

One of the most widely used ??? (3, Informative)

inflex (123318) | more than 6 years ago | (#21252551)

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:One of the most widely used ??? (2, Informative)

wfWebber (715881) | more than 6 years ago | (#21252735)

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:One of the most widely used ??? (2, Informative)

tokul (682258) | more than 6 years ago | (#21253167)

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:One of the most widely used ??? (2, Informative)

thanosk (946232) | more than 6 years ago | (#21253351)

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.

Secure programming by DJB (4, Insightful)

Gadzinka (256729) | more than 6 years ago | (#21252635)

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 (4, Interesting)

deniable (76198) | more than 6 years ago | (#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:I just love qmail (2, Interesting)

gwynevans (751695) | more than 6 years ago | (#21252821)

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:I just love qmail (2, Insightful)

deniable (76198) | more than 6 years ago | (#21252883)

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.

Re:I just love qmail (2, Informative)

tokul (682258) | more than 6 years ago | (#21253253)

> 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 ALRM to qmail-send process.

kill -s ALRM `pidof qmail-send`

robbIE's latest efforts to suck-up to advertisers, (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21252697)

& perfect his censorship devise, is yet another disappointment/study in greed/fear/ego based 'publishing/marketeering'. many more 'clicks' for robbIE, if one wishes to read the comments of the little peepoles. reminds us of the GNU dating service that only failed for a year or so before it went away. it would all be laughable, if it weren't so pathetically buyassed/desperate. gooed luck?

meanwhile, yOUR fearful 'leaders' develop more&more unusual ways to create additional debt & disruption for most of US, while our fellow humans across the water continue to explode by yOUR hand.

infactdead corepirate nazis still WAY off track
(Score:-1, Offtopic)
by Anonymous Coward on Saturday September 01, @09:35AM (#20433195)
it's only a matter of time/space/circumstance.

previous post:
mynuts won 'off t(r)opic'???
(Score:-1, Offtopic)
by Anonymous Coward on Thursday August 30, @10:22AM (#20411119)
eye gas you could call this 'weather'?

http://video.google.com/videoplay?docid=8004881114 [google.com] [google.com] [google.com] 646406827 [google.com]

be careful, the whack(off)job in the next compartment may be a high RANKing corepirate nazi official.

previous post:
whoreabull corepirate nazi felons planning trips
(Score: mynuts won, robbIE's 'secret' censorship score)
by Anonymous Coward on Wednesday August 01, @12:13PM (#20072457)
in orbit perhaps? we wouldn't want to be within 500 miles of the naykid furor at this power point.

better days ahead?

as in payper liesense hypenosys stock markup FraUD felons are on their way out? what a revolutionary concept.

from previous post: many demand corepirate nazi execrable stop abusing US

we the peepoles?

how is it allowed? just like corn passing through a bird's butt eye gas.

all they (the nazi execrable) want is... everything. at what cost to US?

for many of US, the only way out is up.

don't forget, for each of the creators' innocents harmed (in any way) there is a debt that must/will be repaid by you/US as the perpetrators/minions of unprecedented evile will not be available after the big flash occurs.

'vote' with (what's left in) yOUR wallet. help bring an end to unprecedented evile's manifestation through yOUR owned felonious life0cidal glowbull warmongering execrable.

some of US should consider ourselves very fortunate to be among those scheduled to survive after the big flash/implementation of the creators' wwwildly popular planet/population rescue initiative/mandate.

it's right in the manual, 'world without end', etc....

as we all ?know?, change is inevitable, & denying/ignoring gravity, logic, morality, etc..., is only possible, on a temporary basis.

concern about the course of events that will occur should the life0cidal execrable fail to be intervened upon is in order.

'do not be dismayed' (also from the manual). however, it's ok/recommended, to not attempt to live under/accept, fauxking greed/fear/ego based pr ?firm? scriptdead mindphuking hypenosys.

consult with/trust in yOUR creators. providing more than enough of everything for everyone (without any distracting/spiritdead personal gain motives), whilst badtolling unprecedented evile, using an unlimited supply of newclear power, since/until forever. see you there?

security is paramount (4, Insightful)

Edgewize (262271) | more than 6 years ago | (#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.

Re:security is paramount (1)

harmonica (29841) | more than 6 years ago | (#21253365)

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.

Its FAR from secure (1)

Alan Doherty (87875) | more than 6 years ago | (#21252797)

qmail gives the impression of security from a programatic standpoint, and was designed to be so. but unfortunatly wasn't designed for or by someone who understood the security needs/wants of a mail administrator or how those may change. otherwise it would never have been be one of the biggest contributers to backscatter {see end of http://en.wikipedia.org/wiki/Backscatter [wikipedia.org] also security is seldom achieved through feature stripping which appears to be the case the fact it is still used by many non-proffessionals is a testiment more to its original and ongoing hype and buy-in to the myth by the uninformed

qmail is not suitable for use (2, Insightful)

Arrogant-Bastard (141720) | more than 6 years ago | (#21252967)

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 recommendation (based on nearly three decades of experience running mail systems) that qmail be avoided in favor of superior packages such as sendmail, postfix, and exim. (Although the latter, unfortunately, appears to be making increased use of an abusive, spam-supporting feature known as "callbacks".) These packages are actively maintained and their authors have made, and continue to make, efforts to make them standards-compliant and well-behaved (despite the increasing stress placed on them by all forms of mail-related abuse).

As an aside, readers interested in the history of qmail should query a Usenet archive for "a tribute to the programming style of Eric Allman".

qmail. 10 years and still in beta (1)

ThirdPrize (938147) | more than 6 years ago | (#21252985)

oops! thats gmail.

Of course it's secure (1)

nmg196 (184961) | more than 6 years ago | (#21253019)

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 based mail server usable:

http://www.qmailrocks.org/install_rh.htm [qmailrocks.org]

I got a comparable Windows based server up and running in under 20 minutes. Try doing that with qmail.

Once again, it's only free if your time has no value.

Re:Of course it's secure (1)

beheaderaswp (549877) | more than 6 years ago | (#21253169)

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 software cost). Draw your own conclusion Vs. "Uptime".

But in reality, I often question the sanity of admins who use Qmail since I can't rationalize wanting to live that "close to the code". It's not 1997 anymore, and there are huge swaths of FOSS which have sufficient Q&A to get the job done. Working from source, which is an excellent skill, certainly doesn't garner the advantages it once did.

So in essence your comparing "Current Crap (Windows)" to "Oldish Crap (Qmail)" and declaring a winner. Fine.

But the time payoff comes from the machine being up for a year without incident- not the install time.

If you are worried about install time, I've got a copy of ASIP Server V5 around here somewhere- it will install in about 5 minutes. Just don't plug it into *anything*.

Re:Of course it's secure (1)

nmg196 (184961) | more than 6 years ago | (#21253507)

> 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 crashed (except for our one Linux box, which runs out of RAM every few weeks for reasons that not even RedHat are able to tell us). Even my Vista workstation hasn't been rebooted for three weeks (and even that was only so I could flash my RAID controller BIOS).

> So in essence your comparing "Current Crap (Windows)"

It's spelt "you're". Why do people stop taking English after the age of 8.

I'm not comparing any Windows "Crap". The mail server software I use on Windows is FAR from crap (no I'm not talking about Exchange). You're assuming the software I'm using is crap without even knowing what it is!

> But the time payoff comes from the machine being up for a year without incident- not the install time.

The only linux boxes I've seen which have uptimes of a year, are unmaintained ones which aren't being used. How can you patch a kernel without rebooting the machine? I've NEVER EVER seen a modern Windows server crash or lock up. The only reason my servers ever go down is because I've told them to. I think you're thinking of Windows 3.1 from 10 years ago which admittedly crashed fairly often.

qmail and \n (0, Offtopic)

ajs318 (655362) | more than 6 years ago | (#21253131)

Is qmail the MTA that refuses lines without a \r before the \n?

As a former Amiga user and now a committed penguin-shagger, I find this highly annoying.

Re:qmail and \n (1)

tomstdenis (446163) | more than 6 years ago | (#21253157)

It's part of the specs I reckon, check out the HTTP specs, same deal. You can't just send \n\n for two lines.

Re:qmail and \n (0)

Anonymous Coward | more than 6 years ago | (#21253279)

"\r\n" for line breaks is used in all the "text based" internet protocols. Telnet, FTP, HTTP, SMTP, etc. And it's a standard that's older than UNIX; it dates back to teletypes where you needed a "carriage return" to move the print head back to the start of the line and a "line feed" to scroll the paper up a line.

In this instance it's Windows that's following the standard and UNIX that's ignoring it. Apple, however, have no excuse whatsoever.

djbrocks (1)

main() (147152) | more than 6 years ago | (#21253189)

I have to say I am sad to see so many negative reactions to djb and his software.

I'm not sure where the accusations of arrogance against Bernstein come from. I've never met the guy but having studied his code I would say, if anything, his programming style exudes humility. He doesn't trust client software, he doesn't trust the standard libraries and he doesn't trust himself. I think if you look closely at his "style" (for want of a better word) you will find a lot worth emulating.

Personally, I still use qmail and tinydns on my own boxes, where appropriate. At work I don't have any problem recommending his software either and have used qmail for projects relaying over 8 million messages a day without issue. Saying it "doesn't scale" is, in my opinion, untrue. Or at least misleading.

Anyway, djb, I for one salute you!

Si

Signed integer overflow (0)

Anonymous Coward | more than 6 years ago | (#21253331)

DJB says:

Another surprise for the programmer is that y can be
much smaller than x after y = x + 1. ... The closest that qmail has come to a security hole was
a potential overflow (pointed out by Georgi Guninski) of a
32-bit counter that I had failed to check.
This reminds me of the following thread on the full-disclosure list where GCC optimized a naively-written security check out, because, according to the C standard, signed integer overflow is undefined:

http://archives.neohapsis.com/archives/fulldisclosure/2007-01/0280.html [neohapsis.com]

It would be interesting to see DJBs opinion on the problem discussed in this thread.

Postfix makes for a good read (3, Interesting)

andawyr (212118) | more than 6 years ago | (#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.

qmail security holes (0)

illuminatedwax (537131) | more than 6 years ago | (#21253411)

I'm really disappointed that he didn't at least mention or defend the actual security hole found in qmail on 64-bit machines (to be fair, it required allowing qmail to get more than 4GB of memory).

Re:qmail security holes (1)

illuminatedwax (537131) | more than 6 years ago | (#21253473)

Oops, there's the mention of it buried in the paper. Thanks for letting me edit my comments Slashdot

Extreme jail? (1)

IkeTo (27776) | more than 6 years ago | (#21253421)

> 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 sound like a good idea that a program that want to *lower* its privilege has to run as root. If nothing else, the system administrators will probably go mad staring at all those suid root programs (much more mad than all the non-standard procedures needed to run the current programs of djb indeed). Unluckily for all of us, POSIX-compliant Unix is still the way to go. I expect that an "extreme sandbox" would be much easier to build (and much more useful!) with a system like Hurd, only that it won't be ready for use outside the Hurd developers' spare PC in any foreseeable future.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?