Slashdot Mirror

``Have zone files which someone might be able to read and make any sense of.'' No sane human-interface designer would choose BIND's

4.3.2.1.in-addr.arpa. 86400 IN PTR lion.heaven.af.mil.
lion.heaven.af.mil. 86400 IN A 1.2.3.4

(even worse, in two separate files!) over the tinydns-data equivalent:

=lion.heaven.af.mil:1.2.3.4

See the upgrade-from-BIND page, under Administration, for a list of ten time-saving features in the data format.

Even more important is that the data format is easy for programs to read and write. There are tinydns management tools supporting several different administrative tastes: MySQL, LDAP, a web interface, etc. Development of these tools was faster for tinydns than for BIND, and will remain faster, because I'm not throwing artificial barriers in the way of implementors.

``Have zone files which someone might be able to read and make any sense of.'' No sane human-interface designer would choose BIND's

4.3.2.1.in-addr.arpa. 86400 IN PTR lion.heaven.af.mil.
lion.heaven.af.mil. 86400 IN A 1.2.3.4

(even worse, in two separate files!) over the tinydns-data equivalent:

=lion.heaven.af.mil:1.2.3.4

See the upgrade-from-BIND page, under Administration, for a list of ten time-saving features in the data format.

Even more important is that the data format is easy for programs to read and write. There are tinydns management tools supporting several different administrative tastes: MySQL, LDAP, a web interface, etc. Development of these tools was faster for tinydns than for BIND, and will remain faster, because I'm not throwing artificial barriers in the way of implementors.

``Have zone files which someone might be able to read and make any sense of.'' No sane human-interface designer would choose BIND's

4.3.2.1.in-addr.arpa. 86400 IN PTR lion.heaven.af.mil.
lion.heaven.af.mil. 86400 IN A 1.2.3.4

(even worse, in two separate files!) over the tinydns-data equivalent:

=lion.heaven.af.mil:1.2.3.4

See the upgrade-from-BIND page, under Administration, for a list of ten time-saving features in the data format.

Even more important is that the data format is easy for programs to read and write. There are tinydns management tools supporting several different administrative tastes: MySQL, LDAP, a web interface, etc. Development of these tools was faster for tinydns than for BIND, and will remain faster, because I'm not throwing artificial barriers in the way of implementors.

``Have zone files which someone might be able to read and make any sense of.'' No sane human-interface designer would choose BIND's

4.3.2.1.in-addr.arpa. 86400 IN PTR lion.heaven.af.mil.
lion.heaven.af.mil. 86400 IN A 1.2.3.4

(even worse, in two separate files!) over the tinydns-data equivalent:

=lion.heaven.af.mil:1.2.3.4

See the upgrade-from-BIND page, under Administration, for a list of ten time-saving features in the data format.

Even more important is that the data format is easy for programs to read and write. There are tinydns management tools supporting several different administrative tastes: MySQL, LDAP, a web interface, etc. Development of these tools was faster for tinydns than for BIND, and will remain faster, because I'm not throwing artificial barriers in the way of implementors.

Similarly, TSIG is an optional standard. I don't support it because I have better tools for the same thing: for example, IPSEC and ssh.

As for DNSSEC, the protocol isn't even finished, let alone required. Basic features are still in flux, and the system won't work without a centralized key-management system that doesn't exist.

Similarly, TSIG is an optional standard. I don't support it because I have better tools for the same thing: for example, IPSEC and ssh.

As for DNSSEC, the protocol isn't even finished, let alone required. Basic features are still in flux, and the system won't work without a centralized key-management system that doesn't exist.

FWIW, I tried djbdns (via Debian's .deb wrapper that goes and gets it off cr.yp.to) at home. Then I reinstalled BIND. I didn't like installing all his other software to support djbdns and I didn't feel up to maintaining mods to change it--mods that would be violating the spirit of the license. I neither pirate commercial software nor rip off GPL'ed software: since I cannot use djbdns in the spirit of Bernstein's license, I will not use it.

Stop trolling. ``all his other software to support djbdns'' consists of one package: daemontools. And if you felt like setting up djbdns by hand, it would even work without that. Though, I don't see any reason why you wouldn't want daemontools installed. Unless, of course, you don't care if your services stay up without you constantly watching them. daemontools is useful for many things, not just djbdns.

The rest of your post is complete FUD. You are completely allowed to modify djbdns however you see fit. Patches are allowed and encourged. Although, there is no reason you should have to patch it, as the software works fine. The only thing you can't do is distribute modified versions of the software. Distributing patches is just fine.

That's likely to be it's only failure mode in the future - stick a wrapper around it that restarts it when it dies, and you'll be right as rain.

What, like supervise from daemontools?

Nah. It'll never work.

He doesn't need to. djbdns doesn't have a license and doesn't need one: http://cr.yp.to/softwarelaw.html

It would be more accurate to say that djbdns has the default licence that implicitly attaches to creative works by default application of copyright law -- in the absence of an explicit licence grant. The terms of that default licence, described by Prof. Bernstein mostly accurately (other than, according to John Cowan, those concerning modifications) at the URL you posted, are those of proprietary software, rather than open source. (Thus, any software instance issued without an explicit licence is proprietary by default.)

BIND 9 has had security holes.

Tell the whole truth, please: A BIND9 version was subject to one type of DoS attack. Sending a specific DNS packet to the daemon triggered that instance going into some sort of test mode where it performed an internal consistency check, effectively shutting it down.

Rick Moen
rick@linuxmafia.com

You say the djbdns "license" is "more restrictive" than Microsoft's "shared source license".

You don't know what you're talking about. Dan Bernstein does not allow you to redistribute FORKS of djbdns. You are very explicitly allowed, in perpetuity, regardless of what Dan says next year, to redistribute djbdns source tarballs with a specific MD5 checksum. Obviously, you are also allowed to publish patches and detailed vulnerability reports. You're simply not allowed to distribute adulterated source code or your own "fixed" binaries.

This is of course a moot point. There has never been a published vulnerability in the qmail or djbdns codebase. qmail is one of the most widely used MTAs on the Internet. The incentive to find vulnerabilities is huge. Bernstein's methodology is correct and his understanding of the Unix secure coding problem is complete.

You say that there hasn't been a djbdns release since last year and offer that as evidence that djbdns is going "stale".

You don't know what you're talking about. There hasn't been a new qmail release in years. qmail remains one of the most popular MTAs on the Internet, contending seriously only with the diminishing Sendmail hegemony and Microsoft's products. There are no new qmail releases because qmail is complete, hasn't had any security problems, and does virtually everything anyone wants an MTA to do. There hasn't been a new djbdns release because djbdns is complete, hasn't had any security problems, and does virtually everything anyone wants a DNS server to do.

True; however, can you now re-distribute (in a magazine, say) that doctored picture of Dubya? Not necessarily. This is where the "fair use" doctrine applies; satire (like a moustache on Dubya) is covered. A source patch to djbdns -- unclear.

You can distribute instructions on how to draw the moustache. That is the same thing as source patches. Patches are covered under software law.

Has Bernstein put permission to redistribute any patches against djbdns in writing? If so, then the license becomes roughly equivalent to the Trolltech QPL.

He doesn't need to. djbdns doesn't have a license and doesn't need one:

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

What about for porting the program to operating systems that don't fit Bernstein's idea of how the directory structure should be laid out, such as Windows 2000 Server or Windows .NET Enterprise Server?

djbdns is UNIX software. If you really want to run it on Windows, then fix Cygwin so that it works under that. But if you really want to port djbdns to Windows and distribute the patches, then that is fine. You simply can't distribute a compiled version.

Buggy? At least the vulnerability mentioned in the article does not affect most recent version of BIND 9.x.

BIND 9 has had security holes. djbdns never has and never will.

May I suggest Dnsmasq [freshmeat.net], which is described by its creators as a "lightweight, easy to configure DNS forwarder designed to provide DNS (domain name) services to a small network where using BIND would be overkill".

Don't run that. Run dnscache, which is part of the djbdns package. djbdns will out perform everything else and has security guarantee backed by a cash reward for security holes. djbdns has never had a security hole and never will. Why run anything else?

May I suggest Dnsmasq [freshmeat.net], which is described by its creators as a "lightweight, easy to configure DNS forwarder designed to provide DNS (domain name) services to a small network where using BIND would be overkill".

Don't run that. Run dnscache, which is part of the djbdns package. djbdns will out perform everything else and has security guarantee backed by a cash reward for security holes. djbdns has never had a security hole and never will. Why run anything else?

May I suggest Dnsmasq [freshmeat.net], which is described by its creators as a "lightweight, easy to configure DNS forwarder designed to provide DNS (domain name) services to a small network where using BIND would be overkill".

Don't run that. Run dnscache, which is part of the djbdns package. djbdns will out perform everything else and has security guarantee backed by a cash reward for security holes. djbdns has never had a security hole and never will. Why run anything else?

May I suggest Dnsmasq [freshmeat.net], which is described by its creators as a "lightweight, easy to configure DNS forwarder designed to provide DNS (domain name) services to a small network where using BIND would be overkill".

Don't run that. Run dnscache, which is part of the djbdns package. djbdns will out perform everything else and has security guarantee backed by a cash reward for security holes. djbdns has never had a security hole and never will. Why run anything else?

Find a vulnerability and you're not even allowed to release a fixed version!

True, but you CAN release patches agains the source. (see this, among others) And anyone who's going to buid and run this thing should have no problem applying patches.

Has Bernstein put permission to redistribute any patches against djbdns in writing? If so, then the license becomes roughly equivalent to the Trolltech QPL.

His stated and written position is that he doesn't need to give any such permission because he has no legal authority to tell you you can't do it, and neither does anyone else.

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

djbdns is a great codebase, but it's starting to suffer from a few issues. Find a vulnerability and you're not even allowed to release a fixed version! The license is in some ways _more restrictive_ than (dare I say it) Microsoft's Shared Source.

There hasn't been a djbdns release since 12-Feb-2001 and the project is bound to go stale sooner or later if djb does not renew his interest. How many companies or networking professionals out there are going to use DNS software which has a single human point of failure? I won't even go into the "hit by a bus" argument.

Granted, djbdns comes with some cute gimmicks like the "security guarantee". But for all of BIND's problems, the fact that it's open source makes it the better option in this case. Better the devil you know..

> Does TinyDNS support internal and external views?

Yes. This page shows you how http://cr.yp.to/djbdns/tinydns-data.html

That refrence you give talks about licenses with regards to restricting rights of a consumer - basically, shrink wrap licenses that limit (perhaps illegally) my ability to resell a product or modify it for my means.

Yes, which is precisely the issue being discussed here. Are you trying to distribute a modified version of qmail? No? Then why does it concern you? If you want to modify your own version of qmail, then you are perfectly free to do so. If you want other people to use your modified version, then either install it for them or give them patches.

Not being able to distribute modified binaries is a Good Thing. Read the qmail or vchkpw mailing list for a while. Users are stupid. Very stupid in many cases. It is amazing how badly people can screw things up when installing from the original, unaltered source. Now you want to let just anyone distribute screwed up binaries? Think of the support issues involved with that. If people want to install modified versions, they can patch the source themselves.

``Why can't we rename your files? Compatibility is essential. Files must be accessible by the same names on all systems.''

However, even though I may have the right to resell my copy of Windows XP Retail, I don't have the right to make 100 copies and sell them.

Yes, but because of copyright law, not because of the license. You can buy a book and resell it. You can't make copies and sell them. The same goes for software. You can buy a copy at Best Buy and then sell it. You can't make copies and sell them.

So what is http://cr.yp.to/qmail/dist.html then?

That refrence you give talks about licenses with regards to restricting rights of a consumer - basically, shrink wrap licenses that limit (perhaps illegally) my ability to resell a product or modify it for my means. That's wrong. However, even though I may have the right to resell my copy of Windows XP Retail, I don't have the right to make 100 copies and sell them.

Qmail, along with DJBDNS (and a lot of other DJB's software) has a copyright that restricts distribution of modified binaries. Which means, if DJB get's hit by a truck tomarrow and dies, Qmail's developement is legally frozen.

And before anyone complains about the license of QMail/ezmlm, yes, that sucks. The license is a royal pain in the butt, as it doesn't allow direct distribution of modifications, only patches. It still works though, and works really well.

qmail does not have a license and does not need one:

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

``What does all this mean for the free software world? Once you've legally downloaded a program, you can compile it. You can run it. You can modify it. You can distribute your patches for other people to use. If you think you need a license from the copyright holder, you've been bamboozled by Microsoft. As long as you're not distributing the software, you have nothing to worry about.''

I can only second that. qmail runs like a charm and scales.

Check out cr.yp.to/qmail.html and www.qmail.org

Download the tools from cr.yp.to for doing DNS queries (if you're running a *nix variant) and do a

dnstrace a www.slashdot.org a.root-servers.net | dnstracesort | less

The results are available on my website as a text file; take a look if you don't have the tools above.

dnstrace is a great program for seeing how DNS resolvers resolve names to IP addresses. To see a visual diagram try dnsbajaj. It gives a graph of how it got to a domain from a root server, and which nameservers are qualified to answer for those queries.

There's a fairly terse intro to how DNS actually works at http://cr.yp.to/djbdns/intro-dns.html.

The documentation uses examples in tinydns data format, as it is the software the author has written to handle DNS queries.

There's a fairly terse intro to how DNS actually works at http://cr.yp.to/djbdns/intro-dns.html.

The documentation uses examples in tinydns data format, as it is the software the author has written to handle DNS queries.

The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal).

Wrong. DNS is done using UDP queries. Authoritative name servers are only required to respond to UDP queries. TCP is used as a fallback method if a response will not fit in 512 bytes. This is almost never needed (since servers control what data they publish) and as a result, TCP service is not used by many sites. Blocking UDP port 53 will completely break DNS:

http://cr.yp.to/djbdns/tcp.html

And a few of us don't care what version of BIND ships with the operating system, because we immediatly chuck it and use djbdns instead, which generally suffers only from D.J. Bernstein's infamous Spartanism rather than from the incredibly baroque design flaws of BIND.

Hey, that's neat - didn't know about it, since I always have used BIND.

There's no time like the present to make the switch!

Set the expire times to 12 hours a few days in advance, 4 hours on the last day, then half an hour in the last 5 or so hours, and three to five minutes for the last forty minutes?

Why bother? With tinydns, you can specify a timestamp for each record and automatically handle updates:

You may include a timestamp on each line. If ttl is nonzero (or omitted), the timestamp is a starting time for the information in the line; the line will be ignored before that time. If ttl is zero, the timestamp is an ending time (``time to die'') for the information in the line; tinydns dynamically adjusts ttl so that the line's DNS records are not cached for more than a few seconds past the ending time. A timestamp is an external TAI64 timestamp, printed as 16 lowercase hexadecimal characters. For example, the lines

+www.heaven.af.mil:1.2.3.4:0:4000000038af1379
+www.heaven.af.mil:1.2.3.7::4000000038af1379

specify that www.heaven.af.mil will have address 1.2.3.4 until time 4000000038af1379 (2000-02-19 22:04:31 UTC) and will then switch to IP address 1.2.3.7.

Set the expire times to 12 hours a few days in advance, 4 hours on the last day, then half an hour in the last 5 or so hours, and three to five minutes for the last forty minutes?

Why bother? With tinydns, you can specify a timestamp for each record and automatically handle updates:

You may include a timestamp on each line. If ttl is nonzero (or omitted), the timestamp is a starting time for the information in the line; the line will be ignored before that time. If ttl is zero, the timestamp is an ending time (``time to die'') for the information in the line; tinydns dynamically adjusts ttl so that the line's DNS records are not cached for more than a few seconds past the ending time. A timestamp is an external TAI64 timestamp, printed as 16 lowercase hexadecimal characters. For example, the lines

+www.heaven.af.mil:1.2.3.4:0:4000000038af1379
+www.heaven.af.mil:1.2.3.7::4000000038af1379

specify that www.heaven.af.mil will have address 1.2.3.4 until time 4000000038af1379 (2000-02-19 22:04:31 UTC) and will then switch to IP address 1.2.3.7.

I've seen a calender tool too but i'm not sure where it is. If you get QMail, Horde, IMP and Courier (IMAP for Horde/IMP) running you should have no problem finding the calender stuff.

Qmail is here
Horde/IMP is here You need horde to run IMP (and PHP).

I highly suggest buying QMail Handbook it saved my sanity.

OU 31 CU 24 (ABC 2:30pm CST this saturday, I'll be there!)

True, but then again Qmail has offered a USD $500 security guarantee since 1997, which so far remains unclaimed. Sendmail does not, and since then they've had a number of security issues to deal with.

As for its usage, Qmail at one stage included Hotmail among its users, so it has had a reasonable amount of testing and use.

I'm not trying to torch anybody's favorite software here, but both djbdns and qmail have drawbacks.

The biggest issue is the license. Qmail is limited to source-code only distribution, with an exception being made for precompiled binaries if they behave exactly the same as qmail normally behaves. Information here. This means that if you want qmail not to throw all of its binaries under /var and ignore most of /etc for configuration files (which it normally does), you have to compile and patch it by yourself. Also, there is no distributing patched versions, so if D. J. Bernstein dies tomorrow, qmail development is effectively frozen until qmail passes into the public domain decades later. That includes any security/performance patches, as well as ports to other architectures. Djbdns has a similiar license.

There is also compatability. Djbdns does not support certain zone transfer mechanisms. It ignores some IETF standards entirely and impliments its own version instead. I get upset when Microsoft twists and corrupts public standards for its own ends, and I get upset when Bernstien does it as well. I'm lazy, I don't want to have to doublecheck if my DNS servers supports a certain standard if my cofiguration changes. Qmail is more of a quibble, I don't like how it throws everything in /var. (And I'm not sure why the world needs qmtp)

I'm not saying that a lot of people and smaller sites won't find qmail/djbdns (and the rest of Bernstein's software) useful. They seem to be secure, and they do their job as long as everything is compatible.

However, one of the reasons why I avoid proprietary software for many tasks is that I don't want to hitch my wagon to somebody else's horse. If I go with a MTA that is wildly used and is GPL or BSDl, I am assured that development does not rest solely on one person. And if I go with standards-compliant software, it ends up being less of a hassle in the long run.

Djbdns and Qmail aren't bad. But they have licenses that limit distribution and development, and they break interoperability.

Maybe I just haven't bothered to look hard enough,

Like maybe an actual search?

but I didn't know there were any other Open Source name servers out there.

You mean, like these?

• CustomDNS
• DENTS
• djbdns
• dnsmasq
• DNSJava
• dProxy
• MaraDNS
• MyDNS
• pDNSd
• Posadis

djbdns doesn't count and we both already know that

Ah, I see. It's not "Open Source" software because it isn't published under an "Open Source" license, right? (sigh) Dan Bernstein is a total security freak. He doesn't trust ANYBODY. He especially doesn't trust anybody to distribute modified, binary versions of his software, ruining his reputation when one of their "enhancements" results in a security hole. This already happened once when a Qmail add-on was discovered to have a security problem, and thereby tarnished Qmail's otherwise perfect security record.

So he ONLY authorizies distribution of his ORIGINAL source code. No modifications allowed, except as diffs to the originals. And if you apply those diffs and something breaks, don't blame him; blame the author of the diff.

You might disagree with Dan; he's a hard-nosed, inflexible so-and-so. But he's got style, and his programs are a beautiful model of efficiency.

The Open Source community could use a few more people like Dan.

and we both already know that so don't bother with beating that dead horse.

Such Style! Such Wit! Such Argument! Such Rhetoric! Such Unquestionable Authority!

Such a sterling example of my sigfile:

And if you don't want to "nice" the root servers...bind to query the root servers.

1. 
   Friends don't let friends run BIND
   
2. 
   I'm not adversely affecting the root nameservers, and they're designed to handle a great deal more traffic than they do. Heck, even under a DDOS attack, about half of them stayed responsive.
   
3. 
   Since I run djbdns, my DNS is more reliable than my ISP's, anyway.
   

And if you don't want to "nice" the root servers...bind to query the root servers.

1. 
   Friends don't let friends run BIND
   
2. 
   I'm not adversely affecting the root nameservers, and they're designed to handle a great deal more traffic than they do. Heck, even under a DDOS attack, about half of them stayed responsive.
   
3. 
   Since I run djbdns, my DNS is more reliable than my ISP's, anyway.
   

If you're concerned about spyware, be very careful about who's DNS server you list in your PC.

Mine all use 192.168.100.1...anything that's not locally cached gets looked up at the root servers, IIRC. Once it's cached, a website comes up much more rapidly than if it had to be looked up through the ISP's nameserver.

You don't need that many machines to get the bandwidth for those attacks, but doing it the DDOS way might make it harder to block. If the attack is coming for one machine they can just block a single ip address.

Not for SYN floods or DNS floods. Both of those are usually done using spoofed source addresses. Of course, SYN floods are easy to deal with using SYN cookies.

Last night I thought about that, and came up with a couple of ways to do it. I need some time to test them out...

I wrote a wrapper for nistp224 in python; that'll take care of the auth/key exchange issue (elliptic curve keys are faster to compute and smaller than RSA/etc keys). I picked python because there already are a few python-based IM clients. Plus I wanted to figure out how to extend python.

You're assuming a few things that you don't acknowledge:

1. The dns lookup cache has infinite / enough RAM to hold all the entries without expiring the root servers.
2. The software in question was not restarted yesterday as a part of routine maintenance / reconfiguration / time limits.
3. Your ISP knows more about DNS resolution / software configuration than you do.

These are not always true. I always configure myself, and my customers, to use their own Linux box running dnscache to query and cache DNS requests because it is fast, secure, and uses a stable memory size. Relying on my ISP for DNS service is solely a backup plan (your OS does allow you to specify backup DNS servers, right?), regular resolution is done by each machine's copy of dnscache.

Those that survived were running DJBDNS (ok, stupid troll)

Correct, I know of no DNS servers, even djbdns [cr.yp.to] DNS', which restrict queries to a limited IP range as is common with SMTP. There's not really a large risk in opening up your DNS to everyone, in fact, you there are plenty of alternate DNS root servers [jerky.net].

You don't know what you are talking about. There are two different types of DNS servers: authoritative servers and recursive resolvers. djbdns comes with tinydns, an authoritative server and dnscache, a recursive resolver. The two are completely separate. BIND includes both in the same server, which is why many people are confused into thinking they are the same thing.

tinydns does not restrict queries to only certain IP addresses. However, it can return different information depending on the source address of the query. This is usually called split horizon DNS.

dnscache does have access control. You do not want just anyone to be able to query your recursive resolvers. With dnscache, you need to explicitly allow access for IP's that can query it.

There are not risks in opening your content (authoritative) DNS servers to everyone. There are risks in opening up your resolvers to everyone.

Why?

It's really easy to setup a system which dumps your SQL database out to a TinyDNS file. TinyDNS is provably secure software. I would expect that you would use it on the root servers, since it's designed to work at very high levels of output/uptime, and be attack resistant to the point of being attack proof.

Say what you will about D. J. Bernstein, he does have a very capable DNS solution available.

Why?

It's really easy to setup a system which dumps your SQL database out to a TinyDNS file. TinyDNS is provably secure software. I would expect that you would use it on the root servers, since it's designed to work at very high levels of output/uptime, and be attack resistant to the point of being attack proof.

Say what you will about D. J. Bernstein, he does have a very capable DNS solution available.

Why?

It's really easy to setup a system which dumps your SQL database out to a TinyDNS file. TinyDNS is provably secure software. I would expect that you would use it on the root servers, since it's designed to work at very high levels of output/uptime, and be attack resistant to the point of being attack proof.

Say what you will about D. J. Bernstein, he does have a very capable DNS solution available.

Correct, I know of no DNS servers, even djbdns DNS', which restrict queries to a limited IP range as is common with SMTP. There's not really a large risk in opening up your DNS to everyone, in fact, you there are plenty of alternate DNS root servers.

Now, to the other purpose of my message - you mention awk/sed scripts to run across a mail spool, do you happen to know of any that would run across a spool and remove messages by age? I maintain several (RFC822) spools for use in my IMAP clients at all my various locations, mostly mailing lists, digests, etc. and have searched Google in vain for a script that will parse out old messages. The only other viable solution I've found is to simply bulk-archive the entire spool at xxx interval, which is, to say the least, an imperfect solution. I'd write it myself, but I'm not quite comfortable enough with sed/awk to prune entire messages, and I'd likely wind up going through a hundred test spools before I got it right. :) Any pointers would be greatly appreciated.

Do your self a favor and stop using mbox format. It sucks. You should be using maildir. With maildir, every message is a separate file. This means no locking, no corruption, no crazy message scanning, etc. Want to delete every message over 180 days old? Easy:

find /home/user/Maildir/ -atime +180 -exec rm -f {} \;

There are scripts to convert mbox to maildir and vice versa.

Does a two year stint at the ISC maintaining the BIND 8 resolver and tree propagation code count? Moreover, I'd like to think that there are those who are perhaps younger and smarter than me who might be able to "fuck with" and actually do something new with the given software. That's what open source is all about.

Oh, I get it now. You are spreading FUD about Dan's software because he can write secure DNS software and you can't?