Slashdot Mirror

These new RFC's are good, but to really solve the problem of spam and mail storage, a fundamental change in the protocol is needed.

Check out http://cr.yp.to/im2000.html

I'm impressed with this person's ideas for protocols. And his webpage has a neat domain name too :-)

Dan Bernstein wonders why power supplies don't come with an internal UPS.
-russ

Bind 9.0 is safer because it was written from scratch with security in mind, unlike the prior versions. No, it is not. I completely understand why RedHat's corporate policy vis a vis open source software (nevermind the debacle of your original attempt to evaluate qmail for inclusion in 6.0)prevents you from including djb's software in your distribution, but let's not pretend for a moment that BIND 9 is any improvement. Please, throw money and engineers at DENTS or one of the other open-source name server projects.

What's the reason for not shipping qmail or djbdns at least as an option? You can distribute it freely, you can distribute the source, you can distribute patches to the source. So you can't distribute a patched source file or modified binary -- do you actually have such important patches that this holds you back?

As DJB says, coming from people who distribute a binary-only Netscape, this is pretty hypocritical.

Looks like another reason to use djbdns, which has a $500 security guarantee and is supposedly a lot more efficient than BIND.

For RedHat users, here's how to apply the fixes:

Download the appropriate RPMs to fix BIND.

At a shell, as root, type rpm -Ui package -- package of course being the name of the RPM.

Looks like another reason to use djbdns, which has a $500 security guarantee and is supposedly a lot more efficient than BIND.

For RedHat users, here's how to apply the fixes:

Download the appropriate RPMs to fix BIND.

At a shell, as root, type rpm -Ui package -- package of course being the name of the RPM.

And if you absolutely need a named server, run something that doesn't have a history of being cracked.

Like djbdns. See cr.yp.to for details.And while you're there replace inetd with tcpserver.

As for the latest (January 29) vulnerability (TSIG), and the worm that now exploits it, this is just yet another reason to run "named" unprivileged and chroot()'ed, and to keep up to date with advisories and patches...

As for the "$500 cash reward" for finding a security hole in djbdns, don't forget to read the fine print in the guarantee: "My judgment is final as to what constitutes a security hole in djbdns". Feh!

My ancestors evolved from primordial ooze, and all I got was this lousy Existential Angst!

Both Sendmail and BIND suffer from the same basic problem- they are huge monolithic programs that must be executed as root to perform their intended duties.

Why is qmail secure? The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:

Every few months CERT announces Yet Another Security Hole In Sendmail---something that lets local or even remote users take complete control of the machine. I'm sure there are many more holes waiting to be discovered; sendmail's design means that any minor bug in 41000 lines of code is a major security risk. Other popular mailers, such as Smail, and even mailing-list managers, such as Majordomo, seem just as bad.

I followed seven fundamental rules in the design and implementation of qmail:

1. Programs and files are not addresses. Don't treat them as addresses.

   sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.

   In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)

   Security impact: .qmail, like .cshrc and .exrc and various other files, means that anyone who can write arbitrary files as a user can execute arbitrary programs as that user. That's it.

2. Do as little as possible in setuid programs.

   A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.

   Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.

   Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.

3. Do as little as possible as root.

   The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.

4. Move separate functions into mutually untrusting programs.

   Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.

   In fact, these programs don't even trust each other. They are in three groups: qmail-smtpd, which runs as qmaild; qmail-rspawn and qmail-remote, which run as qmailr; and qmail-send, the queue manager, which runs as qmails. Each group is immune from attacks by the others.

   (From root's point of view, as long as root doesn't send any mail, only qmail-start and qmail-lspawn are security-critical. They don't write any files or start any other programs as root.)

5. Don't parse.

   I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces.

   The essence of user interfaces is parsing: converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data.

   When another programmer wants to talk to a user interface, he has to quote: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data.

   This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.

   When the original data is controlled by a malicious user, many of these bugs translate into security holes. Some examples: the Linux login -froot security hole; the classic find | xargs rm security hole; the Majordomo injection security hole. Even a simple parser like getopt is complicated enough for people to screw up the quoting.

   In qmail, all the internal file structures are incredibly simple: text0 lines beginning with single-character commands. (text0 format means that lines are separated by a 0 byte instead of line feed.) The program-level interfaces don't take options.

   All the complexity of parsing RFC 822 address lists and rewriting headers is in the qmail-inject program, which runs without privileges and is essentially part of the UA.

   Keep It Simple, Stupid

Both Sendmail and BIND suffer from the same basic problem- they are huge monolithic programs that must be executed as root to perform their intended duties.

Why is qmail secure? The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:

Every few months CERT announces Yet Another Security Hole In Sendmail---something that lets local or even remote users take complete control of the machine. I'm sure there are many more holes waiting to be discovered; sendmail's design means that any minor bug in 41000 lines of code is a major security risk. Other popular mailers, such as Smail, and even mailing-list managers, such as Majordomo, seem just as bad.

I followed seven fundamental rules in the design and implementation of qmail:

1. Programs and files are not addresses. Don't treat them as addresses.

   sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.

   In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)

   Security impact: .qmail, like .cshrc and .exrc and various other files, means that anyone who can write arbitrary files as a user can execute arbitrary programs as that user. That's it.

2. Do as little as possible in setuid programs.

   A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.

   Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.

   Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.

3. Do as little as possible as root.

   The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.

4. Move separate functions into mutually untrusting programs.

   Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.

   In fact, these programs don't even trust each other. They are in three groups: qmail-smtpd, which runs as qmaild; qmail-rspawn and qmail-remote, which run as qmailr; and qmail-send, the queue manager, which runs as qmails. Each group is immune from attacks by the others.

   (From root's point of view, as long as root doesn't send any mail, only qmail-start and qmail-lspawn are security-critical. They don't write any files or start any other programs as root.)

5. Don't parse.

   I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces.

   The essence of user interfaces is parsing: converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data.

   When another programmer wants to talk to a user interface, he has to quote: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data.

   This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.

   When the original data is controlled by a malicious user, many of these bugs translate into security holes. Some examples: the Linux login -froot security hole; the classic find | xargs rm security hole; the Majordomo injection security hole. Even a simple parser like getopt is complicated enough for people to screw up the quoting.

   In qmail, all the internal file structures are incredibly simple: text0 lines beginning with single-character commands. (text0 format means that lines are separated by a 0 byte instead of line feed.) The program-level interfaces don't take options.

   All the complexity of parsing RFC 822 address lists and rewriting headers is in the qmail-inject program, which runs without privileges and is essentially part of the UA.

   Keep It Simple, Stupid

You do realize that you are wrong, right? You can too patch djbdns and change it any way you like. You just can't redistribute modified copies. If DJB allowed this, then everyone would send out shitty copies to try and get the $500 reward.

Remember, the 'all bugs are shallow with enough eyeballs' only apply if the bugs are under GPL.

You can download the source and look for yourself here.

Nope, I think most reasonable people who reads this site will agree that it better to be rooted than to run a free secure alternative.

Thank God you don't work for my company. You, sir, are a twit.

Well, djbdns isn't really Free. I can't patch it, add some security holes, and redistribute it as the original, like I can with BIND.

That is not 100% correct. See http://cr.yp.to/distributors.html. The only restriction is on redistribution of djbdns. These restrictions are not to make himself rich (if anything, he will lose money on djbdns). The restrictions are so that djbdns stays useful, functional and compatible across all platforms.

Tripwire? If you were a real admin you would look at the source for BIND, declare it garbage, and run djbdns instead.

Run BIND on production servers? Not if my life depended on it. djbdns runs chroot()'d, non-root by default and even then the author still puts up a $500 reward for anyone who can find a security hole.

I'm so glad we modern admins have a choice. djbdns is a real, safe, fast, and well documented alternative to BIND and if I were your boss I'd fire you for not switching.

Friends don't let friends run BIND!

Tripwire? If you were a real admin you would look at the source for BIND, declare it garbage, and run djbdns instead.

Run BIND on production servers? Not if my life depended on it. djbdns runs chroot()'d, non-root by default and even then the author still puts up a $500 reward for anyone who can find a security hole.

I'm so glad we modern admins have a choice. djbdns is a real, safe, fast, and well documented alternative to BIND and if I were your boss I'd fire you for not switching.

Friends don't let friends run BIND!

If you're still running BIND instead of, say, djbdns, well, what the hell is wrong with you? Death to the Buggy Internet Name Daemon.

There are way to many machines running full services when only one or two listening processes are really needed, if that.

DNSSEC

DNSSEC is a project to have a central company, Network Solutions, sign all the .com DNS records. Here's the idea, proposed in 1993:

...

Even if DNSSEC is someday put into place, it will continue to allow attacks through Network Solutions itself. What happens if a Network Solutions employee is bribed? Are the Network Solutions computers secure? An attacker who breaks into one critical Network Solutions computer will have control over the entire Internet.

Or Network Solutions, now VeriSign, could simply be incompetent.

I believe that the best way for Freenet to garantue it's survival is to put it into use for as many "non-suspicious" purposes as possible, e.g.:

• WWW (could easily use it, just use a new URL scheme and/or build proxies),
• Usenet (could use gateways, i.e. newservers that don't use NNTP to exchange postings with other newsservers but Freenet), or
• E-Mail (could switch to something like IM 2000, which could also utilize Freenet).

If Freenet is only used by those who require the freedom, then it is easy to claim that "Freenet is only used by criminals" and to "outlaw the use of technologies such as those utilized by Freenet" - with the obvious result that Freenet will not be available for legal - but "suspicious" - purposes.

see OpenNIC...this is exactly what they do. Add a new server into resolv.conf, and you can resolve the tld's that they've created.

Or use superroot.org's root servers. DJBDNS users can simply put

199.166.24.1
195.117.6.10
199.166.24.3
199.166.31.250
199.166.31.3
199.5.157.128
204.57.55.100
204.80.125.130
205.189.73.10
205.189.73.102
207.126.103.16
216.13.76.2
216.196.48.66

into their {mumble}/dnscache/root/servers/@ file. BIND users use these instructions instead.

The hack gives your access to all the usual TLDs AND SuperRoot's plethora of TLDs without sweat.

// Klaus
--

The man page is dead, simply because there are more HTML browsers than nroff browsers.

See Dan Bernstein's slashdoc standard.
-russ

Here's an interesting presentation by Felix von Leitner called "Writing Small and Fast Software" . Unfortunately, it's a PDF but it's worth reading. Felix is the author of the "diet" libc, a lowfat reimplementation of libc inspired by DJ Bernstein's minimalist C coding style (qmail, djbdns).

But that's not true. What the owner obtains are exclusive rights (within one field) to use the trademark in commerce. Read the law:

• 15 U.S.C. 1114(1)(a) applies only to actions ``in commerce.''
• 15 U.S.C. 1114(1)(b) applies only to documents ``intended to be used in commerce.''
• 15 U.S.C. 1125(a)(1) applies only to actions ``in commerce.''
• The new cybersquatting prohibitions, 15 U.S.C. 1125(d)(1)(a), and 15 U.S.C. 1129(1)(A), apply only to people acting with an ``intent to profit.''

I recently announced my plans to set up freebugtraq, a non-commercial competitor to bugtraq. I was promptly threatened with a trademark lawsuit. Where do trademark owners get the idea that they can control non-commercial activities?

Actually, djb's software is not open source, because it does not come with permission to distribute modified packages.

djb's qmail license is very famous in distributor circles. Its restrictiveness is the primary reason why qmail is not included in most major linux distributions.

As for djbdns, as near as I can tell the djbdns package comes with NO license at all (please someone correct me if I'm wrong), which means that with regards to djbdns you and I have only the rights allowed under fair use, and nothing more. (Interestingly, djb has written an entire page addressing this very point.)

I agree that open source software offers business opportunities, but djb's software sadly is not open source.

Actually, djb's software is not open source, because it does not come with permission to distribute modified packages.

djb's qmail license is very famous in distributor circles. Its restrictiveness is the primary reason why qmail is not included in most major linux distributions.

As for djbdns, as near as I can tell the djbdns package comes with NO license at all (please someone correct me if I'm wrong), which means that with regards to djbdns you and I have only the rights allowed under fair use, and nothing more. (Interestingly, djb has written an entire page addressing this very point.)

I agree that open source software offers business opportunities, but djb's software sadly is not open source.

2. You can't modify it

This is not true. You're not allowed to distribute modified versions, but as long as you don't redistribute the package, you're free to do with it as you please - according to Bernstein.

1. It's free beer. I don't mind free beer software: I use quite a bit of it. I prefer stuff that can actually be modified as needed, however, and not by distributing patches. If this were the only problem, Debian might be able to distribute it as non-free sotware, but then there's the second problem...
2. You can't modify it, and it has its own ideas about where to install stuff in the name of compatibility. Now I'm all for compatibility, but I think this kind of fiat is a really wrong way to try to go about it. I don't want to install this program on the grounds that it's going to mess up my nicely-structured Debian system. Debian's layout is as arbitrary as any other, really, but they've made it nice and consistent. The kind of solipsism demonstrated here by Bernstein is not welcome on my computer.

Maybe BIND sucks, but it's still got my vote for now. I'd buy Mr Vixie lunch if he was ever in the area.

Have a gander at djbdns. This is software done right people.

Instead of upgrading to the latest version of bind because of yet another security hole, I decided to switch. And I've been happy ever since.

I've been searching for an alternative forever and I still can't believe I hadn't come across djbdns until someone on Slashdot posted it. There must be others like me.

Since qmail has already had one exploit in its history, why should we believe that the rest of DJB's software is any more secure?

To answer your rhetorical question, I don't think anyone believes that djbdns is inherently more secure than qmail (although it is a lot easier to configure qmail in an insecure way, if for no other reason than that it's capable of running programs from .qmail files). I trust both of them a lot more than I'd ever trust BIND, though, even if that isn't saying much at this point.

Looks like it's time to replace BIND with djbdns

Funny you should say that - after reading about the BIND priesthood's latest moves I decided to do exactly that. The man's a pain in the rear sometimes but over the years I've learned that his software works, and works well.

djbdns takes an entirely different approach to DNS serving, breaking the problem apart into completely separate components which are addressed by completely separate programs. This takes some getting used to, and it's not always immediately apparent how you can address every esoteric situation that you could with BIND's kitchen-sink approach (mainly because the different programs can't, of course, share port 53). Plus, you have to tread down the slippery slope of DJB replacements for a score of core system services - inetd, init, and so on. But so far I've got DNS servers running in 1/5 the memory footprint, serving queries about 10% faster, from a source that history suggests is all-but-guaranteed to be free of security problems.

Up to now, I hadn't even considered replacing BIND with anything else - just salivating hungrily when new versions came out, in hopes that they might actually run for more than a month or two without an urgent security upgrade. I guess it seemed somehow easier to use the same package everyone else did, if only because experts and books are easy to come by. But now that their long-awaited conclusive answer to the constant plague of security problems is to formally and officially sweep them under the rug, it looked like time to hitch my wagon to a new star. Obviously the underlying problem is not getting solved anytime soon.

I've discussed this with a few admin partners and the BIND problem is something that always takes significant amounts of time to stay on top of. Seems the timing is right for either a code fork, or more effort on alternatives. I don't like the licensing sound of dbj-dns, so I don't think that's the answer. It's not really clear what the license is.

Something that has an application front-end with a database back-end would provide better security and other features. The dbase could be replicated to off-line servers for redundancy in case of faults. This could also be used for load-balancing and backups as well. The front-end for administration could be web-based with a php or perl api for ease of expanding the application. I'd be interested in seeing active development on this project and would definitely contribute. Note that MySQL is GPL, so the potential for this type of thing happening again would be eliminated.

Linux rocks!!! www.dedserius.com

Djbdns is to BIND what qmail is to sendmail. Not only is it written with security in mind, it even has a security guarantee. A refreshing change of pace.

Djbdns is to BIND what qmail is to sendmail. Not only is it written with security in mind, it even has a security guarantee. A refreshing change of pace.

Unless I'm horribly mistaken, there is such a competitor:
http://cr.yp.to/djbdns.html

This was about a month before the big BIND vulnerability became public. The timing wasn't ESP, it was pro-active security, but it sure made our group look good when the announcment hit 'mainstream' news sources.

Let me get this straight. Some of you are willing to tie up your nuts in an NDA to keep using spaghetti code just because it's GPL (or because "everybody" else is using it)? Isn't this the same crowd who jumped the Windows ship for Linux?

Why are so many of you so desperately clinging to something so flawed when something so obviously superior can make your lives easier? Which do you value more: the GPL or your own happiness? Jeez, some of you remind me of the People's Front of Judea Suicide Squad (or was that the Judean People's Front?).

At least take a look at djbdns. Think about these questions as you do. How the hell can you crack it? What of value does the license actually prevent you from doing; and of how much value is that really? Why would a multi-million dollar organization use BIND instead? What love should they have for the GPL? Why would any BIND administrator get to keep his job after getting cracked, when he could have been using djbdns? Why would BIND improve if it didn't face the threat of extinction for its sins? How many assholes are among your favorite artists? Scientists? Businessmen? Why have you not thrown out their work with their party invitation?

Get your head out of your ass and choose something that actually does what it's supposed to do, without holes!

-B...

Sendmail also has a viable alternative in DJB's qmail.
The license is not *that* bad. Sure it's not GPL, but I don't find it particularly restrictive for the average user. Basically DJB wants to ensure that his packages maintain their integrity when redistributed.
If you read up on Dan, you'll see that he firmly believes that software licences and law allow for a user to modify the code as they wish. See http://cr.yp.to/softwarelaw.html.
So you can't bundle up your changes and redistribute - big deal. Just release your patch and let others apply as they wish. Happens all the time with qmail.

If you are worried about null-terminated strings, perhaps in light of Theo de Raadt's estimate that half of all calls to stncpy() and strncat() were botched, there are alternative representations available that are easy to use correctly and have withstood extensive real-world testing.

Forget bind and Mr. Vixie's shenanigans -- get Dan Bernsteins awesome replacement: djbdns. You've heard of qmail and how famously reliable and secure it is, right? Well Dan's done the same thing with DNS as he's done with email. Anyone still running BIND on a authorative nameserver had really ought to consider switching. I did, and it's made my DNS life much much simpler.

Real soon now, we'll be releasing a management interface that plugs right into djbdns too -- http://dajoba.com/projects/nictool/ ..

Abe

Seems like BIND is a problem, and DNS in general is crazy. I'm in the process of trying out djbdns (in order to deal with the new BIND problems!) from cr.yp.to.

Check out this: http://cr.yp.to/djbdns/namedroppers.html. This is info on how closed the process of dealing with DNS issues already is. The guy that wrote this is the guy that wrote Qmail...

Please mod this up, I think it has important implications for this topic!

Seems like BIND is a problem, and DNS in general is crazy. I'm in the process of trying out djbdns (in order to deal with the new BIND problems!) from cr.yp.to.

Check out this: http://cr.yp.to/djbdns/namedroppers.html. This is info on how closed the process of dealing with DNS issues already is. The guy that wrote this is the guy that wrote Qmail...

Please mod this up, I think it has important implications for this topic!

Use djbsdns (from the author of qmail) if you want a secure DNS server. http://cr.yp.to/djbdns.html

Now where did you got that load of crap from? Certainly not from the documentation, because those (QMail FAQ) state:

Is qmail compatible with sendmail? Answer: Yes. qmail supports .forward, /etc/aliases, binmail deliveries to a central mail spool in the usual mbox format, the /usr/{lib,sbin}/sendmail interface for mail injection, and the normal UNIX user database in /etc/passwd. There is a checklist for large sites moving from sendmail to qmail.

Do get the facts right before drawing conclusions whether something is or isn't possible.

I upgraded to BIND 9 and had problems right off the bat, to say nothing of the fact it's 10X the size of BIND8. DJBDNS is one Slick package. It rawks. Very, very elegant. http://cr.yp.to/djbdns.html

BIND 9 is supposed to have been written by a "team of professionals". From where? Microsoft? Guys that were "let go" because they wrote code too buggy and bloated for M$? DJBDNS shows once again one guy with a major clue beats a "team of professionals" every time.

Thanks for getting us this far, Vix and Co., but you can sit down now.

I'd agree that "prickly" is a good word to describe Bernstein; a while back I wrote a chapter of a book on email and while I was writing it I had nightmares about him reaming me for a minor error. Luckily, the book seems to have escaped his notice.

Having used qmail for a few years, I can indeed say that it is a safe and reliable product. But I wouldn't recommend it for a novice sysadmin; DJB is a really smart guy, and he seems to have little patience for those who aren't.

As to his views on licensing, here is the distribution policy for his software. He strictly forbids distribution of qmail except in forms approved by him:

http://cr.yp.to/qmail/dist.html

• By keeping all the data in one file, mbox should use disk space more efficiently as there will be no overhead for directory or inode entries.

  This may be important on a big mail server where inodes or disk space may wind up being scarce commodities.

• By keeping all the data in one file, mbox keeps all the eggs in "one basket;" there is correspondingly less risk of corruption with Maildir .
• Since the mbox format is a longstanding "tradition," there are lots of libraries that work with it. There are fewer to manipulate Maildir .

There are then nontechnial issues.

The creator of Maildir , Dan Bernstein, is a, um, "somewhat prickly character." Take a look at his criticisms of Postfix for some mild material. Comparative discussions of Postfix and qmail have resulted in extremely inflammatory discussions. And Bernstein's attitudes towards the GPL seem similarly "inflammatory." This appears to have put some people off his software, whether rightly or wrongly.

Personally, I use Postfix as my MTA, and push messages through Maildir as interim step to pushing them into MH, which is only a fairly small step removed from Maildir...

• By keeping all the data in one file, mbox should use disk space more efficiently as there will be no overhead for directory or inode entries.

  This may be important on a big mail server where inodes or disk space may wind up being scarce commodities.

• By keeping all the data in one file, mbox keeps all the eggs in "one basket;" there is correspondingly less risk of corruption with Maildir .
• Since the mbox format is a longstanding "tradition," there are lots of libraries that work with it. There are fewer to manipulate Maildir .

There are then nontechnial issues.

The creator of Maildir , Dan Bernstein, is a, um, "somewhat prickly character." Take a look at his criticisms of Postfix for some mild material. Comparative discussions of Postfix and qmail have resulted in extremely inflammatory discussions. And Bernstein's attitudes towards the GPL seem similarly "inflammatory." This appears to have put some people off his software, whether rightly or wrongly.

Personally, I use Postfix as my MTA, and push messages through Maildir as interim step to pushing them into MH, which is only a fairly small step removed from Maildir...

• By keeping all the data in one file, mbox should use disk space more efficiently as there will be no overhead for directory or inode entries.

  This may be important on a big mail server where inodes or disk space may wind up being scarce commodities.

• By keeping all the data in one file, mbox keeps all the eggs in "one basket;" there is correspondingly less risk of corruption with Maildir .
• Since the mbox format is a longstanding "tradition," there are lots of libraries that work with it. There are fewer to manipulate Maildir .

There are then nontechnial issues.

The creator of Maildir , Dan Bernstein, is a, um, "somewhat prickly character." Take a look at his criticisms of Postfix for some mild material. Comparative discussions of Postfix and qmail have resulted in extremely inflammatory discussions. And Bernstein's attitudes towards the GPL seem similarly "inflammatory." This appears to have put some people off his software, whether rightly or wrongly.

Personally, I use Postfix as my MTA, and push messages through Maildir as interim step to pushing them into MH, which is only a fairly small step removed from Maildir...

This comes in two parts- 'tinydns', which only handles serving authoritative data, and 'dnscache' which only handles providing caching DNS services.

Installation is somewhat complex, but the software works like a charm once you get past that.

BSD users are still screwed if they downloaded the source and compiled from source. The changes to BSD's BIND 4 are only for those people that used open BSD's implementation of BIND4.

There are severl alternatives, and having used them all, we had to switch back to bind because of interoperative problems or performance issues. Some solutions are.....

• djbdns
• Windows DNS server
• Dents
• lbnamed in PERL

  Maybe one of these solutions will work for you.

I doubt djbdns has received the attention that BIND has. If djbdns was used on every server instead of BIND, there'd probably be problems found with it too.

DJB is willing to bet that there won't be and even though djbdns is not in wide use, his other project, Qmail, which carries a similar guarantee is widespread even in high-profile high-risk locations like Hotmail. No security related bug has ever been found AFAIK.

Regards,
Xenna (who bets his servers on it)