Qmail At 10 Years — Reflections On 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."
Which is worth more... (Score:1, Insightful)
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 (Score:5, Insightful)
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.
Secure programming by DJB (Score:5, Insightful)
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
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...
security is paramount (Score:5, Insightful)
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:license (Score:4, Insightful)
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:I just love qmail (Score:3, Insightful)
qmail is not suitable for use (Score:2, Insightful)
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".
Re:license (Score:3, Insightful)
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.
Re:Qmail going public domain? (Score:3, Insightful)