Slashdot Mirror

I wonder if Abit's latest motherboards actually support ECC or just claim to. And speaking of ECC, has anyone seen ECC CL2 PC3200 DIMMs?

What I hate most about the C family of languages, is that the only terminator for a string is a binary zero. It is not possible (at least in the implemention available to me) to ask 'how big is that string, physically'?

That's only if you use C strings. Use stralloc and you won't have that problem.

For the usual "feature" patches ("This patch adds pretty shiny things to the edge of your window"...), you're absolutely right: making any kind of large-scale change (like putting a new patch on 1000 machines) is a big deal. Even if it's all automated via network management tools, you'll need to test, prepare and then support it. Do you really need that little tweak added?

However, with security patches usually you have no choice. The only decision for some security patches is how long do you wait before deploying it. Don't wanna be the first ones to put a bad patch on now, do we?

That's a tough one. Deploying a patch seems like a big hassle, especially when you need to test it thoroughly and have a fallback option if it fails. Big hassle, that is, up until it's too late and you have to clear out a few dozen CodeRed or Nimda infected machines! Like insurance: seems too expensive, right up until you actually need it...

Of course, they don't seem to mention the alternative, of not needing to patch ;-) As Bernstein says, reliability means never having to say "sorry" - and never having to patch, either!

Have you seen this piece of software? Regardless of what your opinions are about DJB, he delivers what he promises. Companies like M$ which spread FUD about open-source software claiming that there's no liability or anyone to approach when shit happens should step up to the plate and hold themselves up to those same standards. Especially since they're charging their customers insane amounts of $.

Have you seen this piece of software? Regardless of what your opinions are about DJB, he delivers what he promises. Companies like M$ which spread FUD about open-source software claiming that there's no liability or anyone to approach when shit happens should step up to the plate and hold themselves up to those same standards. Especially since they're charging their customers insane amounts of $.

I think that it would be better to focus on server side protocol changes. The author of qmail hosts this site that talks about on alternate protocol to SMTP. Note that this would be entirely a server side change (it would affect relations between mail servers, while leaving existing protocols for client/server communication).

I sent you (Larry Seltzer) an email. Instead of using expensive certificates, I propose that we add a new type of record to DNS (call it an smtp record for now, someone can always come up with a better name later). The new record would tell what IPs (or FQDNs) are allowed to send email with a certain domain. For example, if an email address is me@slashdot.org, then only mail servers with SMTP records for slashdot.org would be allowed to send an email from me@slashdot.org. If a different mail server tries to send it, the receiving server can refuse the email.

Also check out tmda.net. It uses a number of methods to prevent spam, including temporary addresses and whitelists built by challenges (and client actions). Unlike the previous two proposals, this requires client changes (on the receiver's side), but it does not require others to change the protocols they use. Except for the challenges, senders and intermediary servers do not even need to know it exists.

All three of these proposals could be started more simply and with less additional infrastructure than the certificate idea. The first two require changes to the way things are currently done, but only on the server side. The third is even simpler, only the receiver has to make changes (btw, these are both client and server changes).

IM2000 is an interesting concept, the sender is responsible for storing unrecieved mail. Sending mail anonymously would require a hacked machine or an anonymity service, which would then bear the responsibility associated with anything you send.

I'm suprised that nobody has mentioned IM2000 yet. Dan Bernstein came up with a bunch of ideas about how to reform email, the most important of which is the outgoing mail is stored on the sender's server until it is picked up by the recipient. There are lots of unanswered questions about the design, but the seeds are there.

Dave Bernstein's Internet Mail 2000 proposal offers a solution the largest problem- excessive bandwidth used by spam crippling the entire network.

Obviously, any system needs authentication; adding it to regular and "IM2000" systems would be an equal challenge. But in a sender (or sender's-ISP) hosted system, you're only sending a small flurry of notification packets, instead of a DDoS attack of full mail text.

Smart MTAs/MUAs could then automatically request and preserve local copies based on whitelists and user activity... and the system could coeexist with existing infrastructure, even SMTP. (Abusing an SMTP gateway would then 'only' clog the disk on the outgoing host, and generate a fairly inconsequential burst of notifications.)

Your SMTP servers should require authentication, anyway.

Protecting from spoofed headers is great, but don't expect every router along the internet to give a crap about anything inside the datagram. Authenticated mail may solve part of the problem for the end-user, but it doesn't solve the (DoS-level) problems on the network itself.

Monolithic, buggy programs like sendmail will always be a security nightmare. That doesn't mean that secure code can't be written in C. qmail, for example, is completely secure. If more programmers followed good coding practices, we would see fewer security disasters. A good start would be to stop using C strings and to start using the stralloc concept.

Monolithic, buggy programs like sendmail will always be a security nightmare. That doesn't mean that secure code can't be written in C. qmail, for example, is completely secure. If more programmers followed good coding practices, we would see fewer security disasters. A good start would be to stop using C strings and to start using the stralloc concept.

Monolithic, buggy programs like sendmail will always be a security nightmare. That doesn't mean that secure code can't be written in C. qmail, for example, is completely secure. If more programmers followed good coding practices, we would see fewer security disasters. A good start would be to stop using C strings and to start using the stralloc concept.

Fall-through addresses

Configurable bounce errors

Delivery to a piped process

Backup mail spooling

Support 'list' forwards

Access controls for relaying

Domain mirroring

Not only is this code ripe with pointer arithmetic and unchecked (locally) array bounds access, it even says right in it, "XXX overflow?" -- in other words, the author isn't even sure that what he's doing is correct. If the author's not sure, I don't see how it is "easy" to see that this code is secure.

I'd like to know where these "unchecked" array accesses are at in that code. I sure don't see any. You aren't understanding that comment. pos is a file offset, not a pointer. And that code is only used by qmail-newu, which is run locally by the admin to regenerate the users/assign database. Try looking at some other code, such as qmail-smtpd.c.

I was actually pretty surprised by the code (looking at a few files after that, I don't see any different) in qmail. Though I would believe that qmail is written by an expert C hacker who is paranoid about security, I don't think there is anything special about the code other than that that gives it extra security. Do you have any particular insight that I'm missing?

You must not be familiar with C. Did you not notice the lack of standard string routines? See this page for a list of reasons why qmail is secure.

Are you sure? Check the conditions

If this bug had been found in qmail, it wouldn't count.

Also, I dont use pop or imap myself at all. I still use pine (and no i will not change heh)

Switch to using maildir anyway. Seriously. Pine will work with maildir format, but now you can also hook other stuff on top : courier to provide imap service (I always do it over ssl myself), and web access (again over ssl) with either sqwebmail or squirrelmail. Best of all worlds!

qmail and postfix dont do near as much as sendmail.

And sendmail doesn't do as much as Exchange, so what's that got to do with it? The major weakness of sendmail compared to qmail is precisely that it's a monolithic beast that tries to do everything. Qmail's approach is to have small modules that perform one task, and perform it well (and securely - still no claims on the security guarantee in six years).

Thank you for preaching, please drive through.

Seems to be that like many others, it's the author of qmail that's your problem, not the actual software. So go on, tell us : what features does sendmail provide that can't be found in other MTAs?

Well, it's true that they have no known buffer overflow-style bugs--brute force can occasionally work.

They have no bugs of that nature due to the way they are written. If you read the source, it's easy to see why they are secure. They don't use static buffers and all network input is checked.

Most security problems with C code stem from the use of the standard C library. Dan doesn't use it. His C library makes it much easier to write secure code. If everyone writing C ditched the standard C library, we would see fewer security related bugs.

See this page for an explanation of why qmail is secure: http://cr.yp.to/qmail/guarantee.html

Where do I get my C web server

http://cr.yp.to/publicfile.html

Well, it's true that they have no known buffer overflow-style bugs--brute force can occasionally work.

They have no bugs of that nature due to the way they are written. If you read the source, it's easy to see why they are secure. They don't use static buffers and all network input is checked.

Most security problems with C code stem from the use of the standard C library. Dan doesn't use it. His C library makes it much easier to write secure code. If everyone writing C ditched the standard C library, we would see fewer security related bugs.

See this page for an explanation of why qmail is secure: http://cr.yp.to/qmail/guarantee.html

Where do I get my C web server

http://cr.yp.to/publicfile.html

djbfft is faster than FFTW

Have you tried djbfft? You might want to, as it's quality software from a hardcore mathematician.

I wonder when this benchmark was published, because the FFTW homepage already offers a 3.0beta for download, including SIMD support (SSE/SSE2/3DNow!/Altivec) support.

For applications where raw speed is not very important I recommend everyone to use the fftw library, it is already installed on a lot of systems and easy in use. Very fast are Intel's SDK version and DJ Bernstein's (only 256 points).

Very sorry. :-) As long as the mail server is running qmail and you have shell access, you can set up qmail files for any given "extension." .qmail is what happens to mail sent to username@domain.tld. .qmail-yahoo is what happens to username-yahoo@domain.tld

And, if you want to accept everything that starts with your username, you set up .qmail-default. That will catch everything that isn't just sent to username@domain.tld (that has to be handled by .qmail) and doesn't already have another file handling it.

So, you can have .qmail which handles mail to just username@domain.tld, a .qmail-yahoo that handles everything to username-yahoo@domain.tld, and .qmail-default which handles everything else that starts with your username.

This info is pretty much available in the man page "dotqmail" and some info may be found at the author's web site at http://cr.yp.to/qmail.html
or the Life With Qmail web site, http://www.lifewithqmail.com/.

Also there's Dr. Bernstein's djbdns

It's actually a group of programs: a caching nameserver "dnscache", a non-recursive nameserver "tinydns", a zone-transfer-handling program "axfrdns", reverse DNS wall "walldns" and some rbldns thing.

I used to run various mixes of the above on a few boxes at my last job. Nice software but read the fine instructions: tinydns is very different to Bind wrt administration.

Cheers
Stor

(BTW, what alteratives to BIND exist for Linux and *BSD? I actually don't know and would like to know.)

djbdns

It's a bit quirky but definitely functional. If you don't like qmail you may not like this. It shares similar philosophies, both being created by D. J. Bernstein.

Anyone looked at the DJ Bernstein proposal for Internet Mail 2000?

This is Dan "Qmail" Bernstein's Internet Mail 2000.

Dan Bernstein has a project called Internet Mail 2000, ment to design a new Internet mail infrastructure which makes mail storage the sender's responsibility.

Dan Bernstein has a project called Internet Mail 2000, ment to design a new Internet mail infrastructure which makes mail storage the sender's responsibility.

To make a closed-source app, yes you must pay Trolltech. However, I don't think that should make you turn your back on KDE.

You should read up on the history of KDE and Qt. The main issue is that back when KDE started, Qt was the best tool for the job, and I don't think Gtk even existed.

At the time, Qt wasn't even GPL yet, it was licensed more like qmail, where you can't distribute a modified version of it. This bothered many Free software purists, because if they wanted to add a new feature, the best they could do is send a patch to Trolltech and pray it gets added. The KDE team acknowledged this problem, but they decided that writing a toolkit is easier than writing a desktop environment (on kde.org, they mention at one point KDE had 800,000 lines of code, while Qt had 80,000). So the logic was that they could always go back and recode a free toolkit if Trolltech ever went bad. Eventually though, the KDE Free Qt Foundation was formed, which gives KDE the power to release the latest Qt under a BSD-like license. Basically, if Trolltech stops working on Qt for any reason, stops selling commercial licenses, wishes to change the license to Qt, or otherwise abuses or loses control of their position, all at the discretion of two signed KDE members, a BSD Qt gets released (at which point, KDE would likely start their own LGPL fork of it). I've read over the Foundation papers a few times, and I think Trolltech must have been on crack when they signed it, but I guess it worked out alright since they are hugely popular now because of KDE's succes.

In the meantime, the Harmony project, a reimplementation of Qt, had started. To quote kde.org: "... the solution doesn't lie in writing a new desktop from scratch but in writing an LGPL'ed Qt clone. This is what the Harmony Project does. Even for GPL purists there is no viable reason to refuse KDE since a Qt clone will be available in the not so far future. We believe that we have made the right decision by first building a desktop rather than first building a Qt clone. There would have been a good chance that we would have suffered the same fate that the GnuStep project had to endure if we had acted otherwise."

Today, Qt is GPL, and so Harmony ceases to exist, and the Free Qt Foundation is not really necessary anymore except for ensuring closed-source KDE applications are always possible.

I agree that probably 90% of security holes with any system are due to poor configuration. However, some packages (like sendmail) make it very easy to misconfigure. This is not to say that admins should be lazy, just that it helps when software doesn't make it so difficult to configure securely. qmail is a cinch, and despite your intimations it is very powerful.

For the record, there is a 2001 survey here with statistics on 958 SMTP servers found in a group of 1000000 randomly chosen IPs. If you will note, sendmail leads with 401 machines, IIS/exchange next with 176 and qmail with 167. I hardly think the fact that sendmail runs on less than 2.5 times as many machines as qmail is the cause of the 0 to 100 advisory differential between the two. You dont' hear as much about qmail because it just works...there's not some huge hole found in it with disturbing regularity. And it's practically fire and forget configuration-wise. Regarding features, there are plenty of add-ons that give it 99% of those that sendmail has.

When in doubt, check the facts.

Look, I'll freely admit to being biased, but... I'm a little baffled why Sendmail has not been more widely replaced, given that full understanding of its configuration file seems to require a Ph.d in computer science.

There are better (to my eye) alternatives. Postfix and qmail, just to name a couple. I just made the switch to Postfix, and my admin work got a lot easier overnight.

Is it just inertia that's keeping Sendmail in place?

he's written the license to make it very difficult for anyone but him to distribute modifications

I was under the impression that qmail (and all of djb's software) was completely unlicensed. He doesn't believe that software licenses would stand up in court, so he just relies on his copyright on the software. Basically, if you do violate his copyrights in a way he doesn't like, he'll sue you for copyright infringement. He has neither the right (under US law), nor the desire to prevent people from distributing modifications , as long as they keep them in patch form only. This is only a little bit inconvenient, not "very diffcult" as you say. In fact, a very large number of people have contributed patches.

Also, Wietse Venema is a better human being (aka not a hypocrite) like djb.

Oh? What grounds do you have to call Dan a hypocrite?

Bullshit. http://cr.yp.to/export.html

Well, I haven't used qmail, but Postfix is braindead simple to replace sendmail with.

Ditto qmail. (Hell, probably ditto every other nextgen MTA as well -- it's not exactly rocket science to duplicate /etc/aliases, .forward and provide a "sendmail" wrapper program.)

I haven't had much luck with DJB's other tools like the inetd replacement though or his tinydns. It works fine for awhile and then just starts hanging. It's enough to keep me using BIND 9.x. Someday I'll have to mess around with it and see what's up since I know tons of people use it so it's probably my fscked up system. ;-)

Most likely, yes. :) The djbdns mailing list is usually a good place to ask such questions, just try to document the problem thoroughly (as in: step by step what you did to install it) before posting.

One advantage of Postfix over qmail is that Postfix, from the outside, looks a lot more like Sendmail (which, if you're migrating, is a good thing).

This is not necessarily true. Qmail has officially supported tools to make it look indistinguishable from sendmail for 90% of all users. (e.g. support ".forward" files and /etc/aliases)

Qmail is not Free Software

This is true. Personally I think it's idiotic to consider that to be a "moral" issue, but whatever: assess your needs and choose the appropriate tool.

Wietse Venema is a better human being (aka not a hypocrite) like djb. For those reasons, I will never use qmail, and I advise all others to not use qmail.

This is stupid.

Eric Allman is a nicer guy than Wietse and Dan put together. Hell, probably nicer than the product of Dan's congeniality to the power of Wietse's social skills. I've hung out with him at Usenix conferences, and if I lived in the same area I'd probably invite him to parties.

I still wouldn't run sendmail on a bet.

DJB is an abrasive asshole. I've called him a sociopath directly on at least one occasion. I wouldn't want to be trapped at a cocktail party with him, and if I had a daughter I wouldn't want to date her.

I still ran qmail at companies that I had actual money invested in, because the code is that good.

Cutting off your nose to spite your face is stupid when you're the person who'll get called at 3 in the morning when your box gets rooted. Pick software based on quality and utility, not personality.

(I'd call qmail and postfix to be about equally matched for quality, so it comes down to a question of features and style preference for me.)

You want to replace your entire MTA, one of the most notoriously difficult-to-imlement pieces of software on any internet-connected host, and you want it to work perfectly, but you don't even want to spend a day on the task?

Rotsa ruck, man.

The closest I can offer to this: download qmail, along with fastforward and dot-forward.

Install qmail by following the directions in the "INSTALL" documents exactly, then read djb's qmail to sendmail migration checklist and follow it's instructions exactly.

Assuming you haven't done anything really gonzo with your sendmail config, you should have a working system in a few hours. Then go read Life with Qmail so that you'll actually have an idea of what you've just inflicted on yourself.

You want to replace your entire MTA, one of the most notoriously difficult-to-imlement pieces of software on any internet-connected host, and you want it to work perfectly, but you don't even want to spend a day on the task?

Rotsa ruck, man.

The closest I can offer to this: download qmail, along with fastforward and dot-forward.

Install qmail by following the directions in the "INSTALL" documents exactly, then read djb's qmail to sendmail migration checklist and follow it's instructions exactly.

Assuming you haven't done anything really gonzo with your sendmail config, you should have a working system in a few hours. Then go read Life with Qmail so that you'll actually have an idea of what you've just inflicted on yourself.

You want to replace your entire MTA, one of the most notoriously difficult-to-imlement pieces of software on any internet-connected host, and you want it to work perfectly, but you don't even want to spend a day on the task?

Rotsa ruck, man.

The closest I can offer to this: download qmail, along with fastforward and dot-forward.

Install qmail by following the directions in the "INSTALL" documents exactly, then read djb's qmail to sendmail migration checklist and follow it's instructions exactly.

Assuming you haven't done anything really gonzo with your sendmail config, you should have a working system in a few hours. Then go read Life with Qmail so that you'll actually have an idea of what you've just inflicted on yourself.

You want to replace your entire MTA, one of the most notoriously difficult-to-imlement pieces of software on any internet-connected host, and you want it to work perfectly, but you don't even want to spend a day on the task?

Rotsa ruck, man.

The closest I can offer to this: download qmail, along with fastforward and dot-forward.

Install qmail by following the directions in the "INSTALL" documents exactly, then read djb's qmail to sendmail migration checklist and follow it's instructions exactly.

Assuming you haven't done anything really gonzo with your sendmail config, you should have a working system in a few hours. Then go read Life with Qmail so that you'll actually have an idea of what you've just inflicted on yourself.

It's far more powerful than QMail

Excuse me, but what the hell are you talking about? Would you care to support this statement in some fashion?

Moderators, shame on you for giving points to this unsupported drivel.

Unbiased readers: compare and contrast for yourself. Qmail and Postfix are basically feature-equivilant, have roughly comperable performance, and both have stellar security histories. Both have plenty of 3rd-party tools to automate stuff like virtual domains, catch-all users and the like; both integrate nicely into a number of webmail and pop/imap servers.

Deciding between the two is largely a matter of taste: qmail's many small config files versus postfix's few large ones; different methods of handling aliases; etc etc etc.

• djbdns 1.05
• ucspi-tcp 0.88
• deamontools 0.76

• The whole "/package" and "/command" monstrosity is only part of version 0.76 of daemontools. Previous versions (0.70 is still available for download) of daemontools compile in /usr/local/src and install into /usr/local/bin like a sane program should.
• There is no requirement that you use the svscan functionality of daemontools. If you know exactly what it is you want started, just execute "supervise /service/whatever" manually or out of an init script.
• Likewise, you can dispense with daemontools altogether if you just exec the "/service/whatever/run" scripts directly. Of course, you lose auto-restarting and the like, but you may not care.
• If you don't care for the way that daemontools handles logfiles, the "splogger" program from djb's qmail package will take the stdout from a process and pipe it into syslog. (But since tinydns and dnscache log pretty verbosely, you may just want to pipe it to /dev/null.)
• Speaking of those "run" files: you really should read them (they're short), since that will give you a much better idea of what's going on, and why.
• Of course you need to start tinydns and dnscache as root: how else are they going to bind to a privleged udp port? Check the code; they setuid themselves to an unprivleged user soon after binding. (Axfrdns doesn't have this problem: the tcpserver instance runs as root, while axfrdns does not.)
• The contents of /service don't need to be actual directories; a tree of symlinks will do. (This should be a lot easier to build into a ramfs partition than all of the actual subdirs.)

• djbdns 1.05
• ucspi-tcp 0.88
• deamontools 0.76

• The whole "/package" and "/command" monstrosity is only part of version 0.76 of daemontools. Previous versions (0.70 is still available for download) of daemontools compile in /usr/local/src and install into /usr/local/bin like a sane program should.
• There is no requirement that you use the svscan functionality of daemontools. If you know exactly what it is you want started, just execute "supervise /service/whatever" manually or out of an init script.
• Likewise, you can dispense with daemontools altogether if you just exec the "/service/whatever/run" scripts directly. Of course, you lose auto-restarting and the like, but you may not care.
• If you don't care for the way that daemontools handles logfiles, the "splogger" program from djb's qmail package will take the stdout from a process and pipe it into syslog. (But since tinydns and dnscache log pretty verbosely, you may just want to pipe it to /dev/null.)
• Speaking of those "run" files: you really should read them (they're short), since that will give you a much better idea of what's going on, and why.
• Of course you need to start tinydns and dnscache as root: how else are they going to bind to a privleged udp port? Check the code; they setuid themselves to an unprivleged user soon after binding. (Axfrdns doesn't have this problem: the tcpserver instance runs as root, while axfrdns does not.)
• The contents of /service don't need to be actual directories; a tree of symlinks will do. (This should be a lot easier to build into a ramfs partition than all of the actual subdirs.)

• djbdns 1.05
• ucspi-tcp 0.88
• deamontools 0.76

• The whole "/package" and "/command" monstrosity is only part of version 0.76 of daemontools. Previous versions (0.70 is still available for download) of daemontools compile in /usr/local/src and install into /usr/local/bin like a sane program should.
• There is no requirement that you use the svscan functionality of daemontools. If you know exactly what it is you want started, just execute "supervise /service/whatever" manually or out of an init script.
• Likewise, you can dispense with daemontools altogether if you just exec the "/service/whatever/run" scripts directly. Of course, you lose auto-restarting and the like, but you may not care.
• If you don't care for the way that daemontools handles logfiles, the "splogger" program from djb's qmail package will take the stdout from a process and pipe it into syslog. (But since tinydns and dnscache log pretty verbosely, you may just want to pipe it to /dev/null.)
• Speaking of those "run" files: you really should read them (they're short), since that will give you a much better idea of what's going on, and why.
• Of course you need to start tinydns and dnscache as root: how else are they going to bind to a privleged udp port? Check the code; they setuid themselves to an unprivleged user soon after binding. (Axfrdns doesn't have this problem: the tcpserver instance runs as root, while axfrdns does not.)
• The contents of /service don't need to be actual directories; a tree of symlinks will do. (This should be a lot easier to build into a ramfs partition than all of the actual subdirs.)

• djbdns 1.05
• ucspi-tcp 0.88
• deamontools 0.76

• The whole "/package" and "/command" monstrosity is only part of version 0.76 of daemontools. Previous versions (0.70 is still available for download) of daemontools compile in /usr/local/src and install into /usr/local/bin like a sane program should.
• There is no requirement that you use the svscan functionality of daemontools. If you know exactly what it is you want started, just execute "supervise /service/whatever" manually or out of an init script.
• Likewise, you can dispense with daemontools altogether if you just exec the "/service/whatever/run" scripts directly. Of course, you lose auto-restarting and the like, but you may not care.
• If you don't care for the way that daemontools handles logfiles, the "splogger" program from djb's qmail package will take the stdout from a process and pipe it into syslog. (But since tinydns and dnscache log pretty verbosely, you may just want to pipe it to /dev/null.)
• Speaking of those "run" files: you really should read them (they're short), since that will give you a much better idea of what's going on, and why.
• Of course you need to start tinydns and dnscache as root: how else are they going to bind to a privleged udp port? Check the code; they setuid themselves to an unprivleged user soon after binding. (Axfrdns doesn't have this problem: the tcpserver instance runs as root, while axfrdns does not.)
• The contents of /service don't need to be actual directories; a tree of symlinks will do. (This should be a lot easier to build into a ramfs partition than all of the actual subdirs.)

I know how Mr. Bernstein feels about NSD and BIND...

From http://cr.yp.to/djbdns/other.html
NSD publishes DNS information from BIND-style zone files. Security history: Unclear. The NSD documentation includes bugs like ``Very strange coredump in hash_destroy() that happens sometimes'' without any analysis of their security impact. Is that an exploitable buffer overflow?

The Buggy Internet Name Daemon BIND is a monolithic server/cache; it also includes a client library, libresolv. Security history: IQUERY buffer overflow in BIND before 8.1.2-T3B (1998); NXT buffer overflow in BIND before 8.2.2-P4 (1999); nslookupcomplain buffer overflow in BIND before 4.9.8 (2001); TSIG buffer overflow in BIND before 8.2.3 (2001); CNAME buffer overflow in libresolv before 4.9.9/8.2.6/8.3.3/9.2.2 (2002); SIG buffer overflow in BIND before 4.9.11/8.3.4 (2002); getnetbyname buffer overflow in libresolv before 4.9.11 (2002). All of these allowed attackers around the Internet to seize control of the program.

When can we see a root nameserver running tinydns? I have been using it for years now... It's nice not worrying about exploits... it's even nicer having all my memory back...

I also don't understand your comment about having to ``learn'' daemontools. There aren't any decisions to make, and you aren't expected to read any of the daemontools documentation before using djbdns. All you have to do is install the programs so that djbdns can use them.

See This page

to see a summary of the things that daemontools does compared to other init strategies. You have to run something in inittab to ensure that process restarting is clean and reliable. The daemontools package also makes it easy for one daemon to check all the others, re-start the dead ones, add and/or remove services at will, signal them cleanly, and is available under all flavors of Unix.

You MAY think that is only an incremental improvement over init. I don't.

I think I understated the additional resources needed to track each email while it's being sent. In my opinion, it is an absolutely crushing burden and no ISP can afford to check with the sender for each email they receive.

Here's a good reference on smtp. Hope that helps.