Slashdot Mirror

The summary: It's unfinished, the BIND company has poor implementations (like most everything else it implements), and won't provide a real increase in security. Interesting stuff.

Actually, it seems that an automatic pactch installer could totally render EULA updates null and void.

Windows EULAs are already null and void unless you sign a contract with Microsoft.

Yes. Yes, they do.

They start with a broken idea

Such as assuming that everyone is using UNIX. Download 50 megs of UNIX tools ported to Windows, just to configure the source code before compiling it? No. Write your own damn makefiles, you lazy turds.

As usual, djb's got the innovative ideas. Google for djb and redo.

Like the others who replied, I had trouble figuring this out. I presume you mean this?

Click here.

You're missing the point. The post 2-up was wondering about what rights you have though general copyright without using the GPL.

A good example is the package daemontools available from DJB. It is not redistributable. The tarball doesn't contain any LICENSE but does contain a copyright.

Now what can I do with this tarball? The previous poster what wondering if he could modify it as long as he doesn't redistribute the changes. Now logically that sounds reasonable but I don't know.

much, MUCH worse:

It was running wu-ftpd.

wu-ftpd. just. say. no.

Friends don't let friends use wu-ftpd. Or ProFTPD. Not even the OpenBSD ftpd. Instead, they make them use publicfile.

Yes, but I'm not of anyone who claims their software is "absolutely secure"

http://cr.yp.to/qmail/guarantee.html
http://cr.yp.to/djbdns/guarantee.html

Yes, but I'm not of anyone who claims their software is "absolutely secure"

http://cr.yp.to/qmail/guarantee.html
http://cr.yp.to/djbdns/guarantee.html

I don't disagree. I think that eventually we should move to a better email model - something like TMDA perhaps, where there is no guarantee that spammers can reach mailboxes. Or better legislation to make spamming punishable, controls on mail routers on million message mailouts, etc. Or djb's Internet Mail 2000, which moves the onus onto the senders network to store all 1m messages at a time, until people pick them up.

The other thing you can do is impose a microcost for mailing - at 1c/mail, spamming isn't economical any more. But then that is going to penalise the people who have legitimate reasons to send a million emails at a time - you'd have to have a very good micropayment system working on the Internet to do this.

However, those things need widespread change, and they need people in positions of power. Joe User at home can push for it, but they still get spam and they still want a short term solution. I suggest that even if they're filtering, the action of having to check their spam filter will make them irate enough. I see it as being like IPV6 - everyone would really have to change at once for the system to be most effective. (I use Freenet6, do you?)

Now that viruses are public, caught quickly, and Microsoft are being a lot less lax with security (I am in no way commending their effort, but they at least mostly fixed the Outlooks), you don't see people writing them nearly as often. I feel spam will get the same.

Making spammers pay for each spam they send? Sounds a lot like Daniel Bernstein's Internet Mail 2000 recommendation, except that this idea has far more potential for abuse. As much as I like Paul Graham's innovative ideas, this one is definitely both late on the scene and inferior to IM2000.

Jeremy

Don't forget DJB's replacement for SMTP, QMTP: http://cr.yp.to/proto/qmtp.txt

Here it is as a proper link: http://cr.yp.to/proto/qmtp.txt.

And the good thing about the SMTP-alternative QMTP is that it already exists and is in use. It is part of the qmail package.

Here it is as a proper link: http://cr.yp.to/proto/qmtp.txt.

And the good thing about the SMTP-alternative QMTP is that it already exists and is in use. It is part of the qmail package.

DJB's Internet Mail 2000 spec includes a method for interoperating with the existing mail infrastructure, by using low preference MX records as described below:

MXPS: the Mail Exchanger Protocol Switch

However, an MXPS client that supports QMTP and sees the MX record 12801 mailin-01.mx.aol.com will try a QMTP connection to mailin-01.mx.aol.com before trying an SMTP connection to mailin-01.mx.aol.com. The point is that QMTP is faster than SMTP.

Here is the general rule. Particular MX distances are assigned to protocols as follows:

• 12801, 12817, 12833, 12849, 12865, ..., 13041: QMTP. If the client supports MXPS and QMTP, it tries a QMTP connection to port 209. If the client does not support MXPS or QMTP, or if the QMTP connection attempt fails, the client tries an SMTP connection to port 25 as usual. The client does not try SMTP if the QMTP connection attempt succeeds but mail delivery through that connection fails.

In the far future, if all clients are upgraded to support QMTP, it will be possible for servers to switch from SMTP to QMTP, turning off SMTP. In the farther future, if all clients support QMTP and all servers have switched from SMTP to QMTP, it will be possible for clients to drop support for SMTP. In the short term, none of these simplifications are possible, but clients and servers can benefit from the speed of QMTP. History I proposed MXPS in the documentation for the first qmail release in 1996. In the original design, distances 12801 etc. were assigned to QMTP without an SMTP fallback; this type of assignment makes sense for potential future QMTP-only servers but makes current QMTP+SMTP servers unnecessarily difficult to set up.

im2000

D. J. Bernstein, the author of the supremely reliable and secure qmail mail server, wrote a proposal for a new Internet mail system a couple of years ago. It's called Internet Mail 2000. Check it out at:

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

The basic premise is this:

"IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility."

It's an interesting concept and worth a read.

Unfortunately it doesn't look like it would do much to stop spamming, which is the major problem with the current internet mail infrastructure. For that, we need some way to make sending bulk email costly to spammers. Actually I'd say that this could be done already with current technologies, it's just that ISPs and large network providers are not being responsible in ensuring that the users of their networks pay the appropriate price for sending out SPAM.

Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ...

I've wasted a dozen hours I couldn't afford trying to get Mandrake 9.1 working on a network on my very well-supported IBM laptop. It installs OK, but absolutely refuses to get correct DNS server information from DHCP.

No Windows client (9x, NT, 2K) has ever had a problem, but Mandrake refuses to let itself talk to the rest of the world, making it totally useless for anything more serious than frozen bubble.

I no longer have time to spend trying to figure out how to fix broken software, so I'm sticking with Windows on the desktop for another year or two.

It's sad really, I've been regularly giving Linux a try on the desktop since 1997, and it's never made the grade even once - that's right, not even one time have I had any Linux distro I've tried flawlessly install and allow access to the network.

This is pretty basic stuff, and I'm a 20-year Unix veteran, so I'm pretty capable, but I also have better things to do than chase endless bugs and misconfigurations in flaky distros - bugs that should have been fixed long before the software shipped.

It really is sad, but even today, Linux is still not up to snuff as a desktop, which is why it will have to remain confined to server duty for another year or two - until someone finally builds a distro that *does* work.

D.J.Bernstein has an insightful rant about how/why the transition to IPv6 is going too slow while some people claim the transition is already done.

greatest coders in the world still have bugs in their code.

I beg to differ.

~Will

I was wondering why the transition to IPv6 hasn't happened yet... I can't just switch my computer because 1) my ISP doesn't know anything about IPV6; 2) my software is half-baked with respect to IPv6 support; and 3) none of the big sites are on IPv6.

I was wondering why nobody was "taking the plunge".

Then I read this article by DJ Bernstein.

Ignore the general "djb-ness" of the article (i.e., I'm djb, I'm smarter than you, you assmunch), I suggest everyone read this carefully.

Basically he is saying that there is NO clear path from here to IPv6 nirvana. And I totally agree, this is what I was feeling all this time.

There is one addendum I would make though: IPv6 can happen globally when Microsoft decides to make it the standard. They are the only ones who can "centrally plan" the entire computer industry. Sad, yes.

Do we want IPv6ms?

Personally I vote for making NAT *much* more pervasive. Why does every ISP customer need an IP address, etc.?

The only valid complaint about NAT I hear is that it breaks FTP.... B. F. D.

This lack of automation is a huge obstacle to IPv6 deployment. How are you going to convince millions of users to configure IPv6 on their machines? It doesn't give them access to any new web pages, or let them talk to additional customers, or save time, or provide any other apparent benefits. So why should they bother?

It didn't have to be this way. All of the configuration difficulties come from a single mistake in the IPv6 addressing architecture. See cr.yp.to/djbdns/ipv6mess.html.

Using VNC - or any other non-MS approved remote desktop control/sharing program - with Windows XP is a breach of your EULA.

So? Unless you signed a contract when you purchased it, it is perfectly legal:

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

Dan Bernstien (of qmail fame) has a proposal for just such a thing. I don't think any software has been written for it, but I think it's a step in the right direction.

That is the idea behind D. J. Bernstein's proposal for a next generation mail protocol if I'm not mistaken. Details can be found here. It should also help curb spam; system resource requirements become greater at the sender's end than the receivers. It is a way to tax the sender without having to explicitly charge them.

Has the legal status of EULAs been clarified? 1) You don't sign them

They're not enforcable: http://cr.yp.to/softwarelaw.html

1. It's not proftpd, it's pure-ftpd. 2. I don't like silly command line wrappers. 3. Only communists required you te be like everybody else

Also xinetd eats up a whole lot more memory than minit:

root 28484 0.0 0.0 24 16 ? S Jun22 0:00 /sbin/minit

Try to match that with any other superserver! Well maybe runit or daemontools would yeld close figures. I also like the way you can start and stop services.

that you're using BIND. When you get r00ted next week when the LATEST hole is dicovered, maybe you'll switch to a real DNS server.
Yes, Nehril, this is a troll.

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

If that doesn't log enough info for your tasts, combine 'publicfile' with 'recordio'.

Nonesuch@Chicago

http://www.eff.org/bernstein/

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

http://news.com.com/2100-1023-225508.html?legacy=c net

There are no licensing restrictions on qmail

If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute.

Yeah, well, that's why some qmail people are moving to Courier instead.

I started with qmail, because I liked Maildirs much better than mbox format. But then I needed an IMAP server. And then I needed a webmail server. And then I needed e-mail filtering.

So instead of installing all the pieces separately, I just installed Courier.

While the DJB-style configuration directories are kinda interesting, I perfer Courier's more mainstream configuration files.

Still using DJBDNS though. Small and simple, which is what I like.

Another "questionable" practice that would be affected are services like monster.com, which send mail (usually resumes) to subscribers (companies hunting employees), but forge the sender address as being the real address of the individual, not of monster.com itself.

The simple solution here is for monster.com to do the right thing and only "forge" the From line in the header, not the envelope sender address. The envelope sender should use VERP, which would allow monster to know when a specific email bounces.

Apparently you can use rblsmtpd as a front-end with blocking of RBL-listed sites. It calls your "real" smtpd (such as Qmail or Sendmail) if the IP of the sender is not on the RBL.

I am not bothered enough in bandwidth terms to use this yet, plus I am too paranoid about false positives.

On these nameservers, override the zones for the biggest spyware domains and also for AIM, Yahoo Chat and the like, adding wildcard A records directing the request to the IP address of an internal machine running a HTTPd, or to 127.0.0.1.

The effect is twofold -- this will break 90% of the spyware programs, and you will have a log of all of the internal clients with spyware installed.

I use DJBDNS for the nameserver and publicfile for the HTTPd, but the same effect can be obtained with BIND and Apache.

There are a few programs out there that use or will fall back to hardcoded IP addresses, but these can be dealt with by adding NULL routes at the appropriate gateway routers.

On these nameservers, override the zones for the biggest spyware domains and also for AIM, Yahoo Chat and the like, adding wildcard A records directing the request to the IP address of an internal machine running a HTTPd, or to 127.0.0.1.

The effect is twofold -- this will break 90% of the spyware programs, and you will have a log of all of the internal clients with spyware installed.

I use DJBDNS for the nameserver and publicfile for the HTTPd, but the same effect can be obtained with BIND and Apache.

There are a few programs out there that use or will fall back to hardcoded IP addresses, but these can be dealt with by adding NULL routes at the appropriate gateway routers.

djb (of qmail fame) has some rather uncomplimentary things to say about the accuracy of FFTW's speed claims.

Spam doesn't work the same way as something like a webpage (or Usenet, or IRC, etc). With most systems (HTTP for example), you must actively request the data you want. With email, the spammer makes that decision for you. That's the real problem with email, it's the IETF's equivalent of the Windows Messaging system (which, coincidentally, also gets spammed).

Personally, I am leaning towards using a "web of trust" system, with confirmed authentication to prevent relaying of spoofed email.

Why?

If the problem with email is that it's a push service, why not fix that instead of just accepting it? Ok, you need part of it to be push, so you know that someone wants to send you something, but it doesn't have to be very much.

IBM PC XT 4.7 Megahertz to Pentium 4 at 3 Gigahertz. (3,000 Megahertz) It seems a little shy of 10,000 times unless you factor going from an 8 bit processor to a 32 bit processer.

You don't need to go that far back to history to see a really big difference. Just compare the FPU speed of i287 and Athlon. i287 took minimum of 90 cycles for FMUL, minimum of 70 cycles for FADD and at least 30 cycles for a floating point load. Compare that to Athlon that can do two loads, FMUL and FADD every cycle. So, something that took i287 at least 90+70+2*30 = 220 cycles, Athlon can do every clock cycle. In addition to that, Athlon is running at 2GHz instead of 10MHz. So one could argue that current Athlon is 2000/10*220 = 44000 times faster than about a 20 year old FPU (when was 287 released anyway?). In addition to that, we have MMX, SSE and SSE2 that can further boost best case scenarios but I think it's safe to say that current x86 CPUs are at least 10000 times faster than 20 year old ones. Not to count more advanced caches -- not too many years ago L2 cache was external and optional. Of course, if you compare 20 year old Gray and a CPU inside modern portable device the difference is much smaller.

I think that this operates rather backwardly. Instead of making /bin a symlink to some new directory, it would make more sense to make a conglomerate directory that includes the contents of /bin, /usr/bin, etc.

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

Lets say you have your cable modem and you enter and execute the command "host xxx.xxx.xxx.xxx" where the xxx octects are filled with your ip number. What is returned is the PTR to that ip which would be your domain name assigned to that ip, which probably looks something like cablemodemxxx-xxx-xxx-xxx.isp.net.

This record/entry can be changed by your ISP if you request it, so instead of cablemodemxxx-xxx-xxx-xxx.isp.net they could point it to something like machine.yourowndomain.com. There are several ISP's that allow this and several more that don't. The ISP owns the ip's, if you have a static ip you should have no problem requesting this as it's static and never changing and you essentially own it. Dynamic is different as you don't own any of the ips, they are obviously changing (even if yours never changes) and the ISP has one less thing to deal with.

Now a mail server should always have a MX record (Mail Exchange record) when you enter a MX record into your DNS config for whatever (bind,tinydns,etc) that MX record should have a pointer regardless of what you call it. Some people simply don't have this as to evade reverse lookups on their ip's. It doesn't really stop one from looking up where a block of ip's belongs to and starting to investigate from there but it's quite annoying. The only other logical reason that exists it just a poor setup on the DNS administrators part. Alot of people setting up DNS don't take the time to understand what exactly they are doing, they also don't take the time to implement it correctly or understand that an A record and PTR record can't be used interchangeably and that things like a CNAME record should be used sparingly. So just like your ip which is mapped to a machine that has a pointer to cablemodemxxx-xxx-xxx-xxx.isp.net, mail servers should have the same because they are nothing but machines, quick example. If you ran a mail server your reverse would be cablemodemxxx-xxx-xxx-xxx.isp.net. When mail is sent to my mail server my server says ok, lets reverse lookup what machine this is coming from; oh?? you don't have a PTR record?? sorry, I cannot accept mail from you because you're an anonymous machine. If you have a PTR my mail server looks it up and says OK cablemodemxxx-xxx-xxx-xxx.isp.net you are now free to send mail to whatever domains you have access to from here.

I hope this helps. I recommend the Oreilly book DNS and BIND for an understanding of the Domain Name System as well as reading newsgroups, mailing list and anything else you can get your hands on. I don't recommend you use BIND as a DNS server for it's lack of security and bloat. However I do recommend you use an alternative which you should investigate on your own. Personally I use Tinydns which is apart of the DjbDNS package.

Lets say you have your cable modem and you enter and execute the command "host xxx.xxx.xxx.xxx" where the xxx octects are filled with your ip number. What is returned is the PTR to that ip which would be your domain name assigned to that ip, which probably looks something like cablemodemxxx-xxx-xxx-xxx.isp.net.

This record/entry can be changed by your ISP if you request it, so instead of cablemodemxxx-xxx-xxx-xxx.isp.net they could point it to something like machine.yourowndomain.com. There are several ISP's that allow this and several more that don't. The ISP owns the ip's, if you have a static ip you should have no problem requesting this as it's static and never changing and you essentially own it. Dynamic is different as you don't own any of the ips, they are obviously changing (even if yours never changes) and the ISP has one less thing to deal with.

Now a mail server should always have a MX record (Mail Exchange record) when you enter a MX record into your DNS config for whatever (bind,tinydns,etc) that MX record should have a pointer regardless of what you call it. Some people simply don't have this as to evade reverse lookups on their ip's. It doesn't really stop one from looking up where a block of ip's belongs to and starting to investigate from there but it's quite annoying. The only other logical reason that exists it just a poor setup on the DNS administrators part. Alot of people setting up DNS don't take the time to understand what exactly they are doing, they also don't take the time to implement it correctly or understand that an A record and PTR record can't be used interchangeably and that things like a CNAME record should be used sparingly. So just like your ip which is mapped to a machine that has a pointer to cablemodemxxx-xxx-xxx-xxx.isp.net, mail servers should have the same because they are nothing but machines, quick example. If you ran a mail server your reverse would be cablemodemxxx-xxx-xxx-xxx.isp.net. When mail is sent to my mail server my server says ok, lets reverse lookup what machine this is coming from; oh?? you don't have a PTR record?? sorry, I cannot accept mail from you because you're an anonymous machine. If you have a PTR my mail server looks it up and says OK cablemodemxxx-xxx-xxx-xxx.isp.net you are now free to send mail to whatever domains you have access to from here.

I hope this helps. I recommend the Oreilly book DNS and BIND for an understanding of the Domain Name System as well as reading newsgroups, mailing list and anything else you can get your hands on. I don't recommend you use BIND as a DNS server for it's lack of security and bloat. However I do recommend you use an alternative which you should investigate on your own. Personally I use Tinydns which is apart of the DjbDNS package.

A 2.2 Ghz P4 (I assume) is not 88 times faster than a 25 MHz 386/486. You're buying into the megahertz myth; the modern processor has many more optimizations that make it more faste.

Yep, current CPUs do much more in one clock than 386. For example, 386 took 9-38 clocks for a single 32b multiply. Even P3 can do effectively (pipeline) a single 32b multiply in 1 clock and floating point multiply in 2 clocks (or better if you use 'multimedia' instructions). Athlon can do both in 1 clock (in fact, it can do two loads, add and multiplication with floating point numbers in one clock). I couldn't find timings for P4, but I think it can do integer multiplication in one clock but requires quite more for floating point multiplication.

Hmmm. You mean something like this?

to build on what you stated, Dan Bernstein (of qmail fame) pondered on this a few years back. his website http://cr.yp.to/im2000.html makes a few of these observations. he also has a mailing list about this very subject. interesting concept -- i'd love to see something like it implimented. it would really make life for a spammer difficult, which is a "good thing(tm)"

I know I've read about a formalized version of this idea here. Somebody post it again.

D.J. Bernstein's Internet Mail 2000

I think Unix/Linux integrators keep frittering away opportunities, since they don't want to really standardize on a directory layout/interface for common utilities. I think some of this happens due to laziness (two competing versions are implemented concurrently but the authors don't unify their interfaces), but as djb says there is a short term local reward for fragmenting the interface that the integrators choose in spite of the long term global penalty. This has held Unix/Linux back in my opinion, since code developers and administrators hate how these incompatibilities make it difficult to configure/install software properly.

Local IPv6 addresses don't offer any advantages over 10.* IPv4 addresses.

Global IPv6 addresses don't work. Most client computers around the Internet can't talk to a server on a global IPv6 address, and most server computers around the Internet can't talk to a client on a global IPv6 address. Sure, a few people could connect to my IPv6 addresses; so what? Why should I go to extra effort to make those addresses work?

All the operating systems I use have been claiming ``IPv6 support'' for years. But they still require manual action by the system administrator before they can talk to IPv6 addresses. What do I gain by spending time setting up IPv6?

(All of this boils down to a small protocol design error in IPv6. A small change to IPv6 software would make IPv6 addresses work without any administrator action. I have a web page, http://cr.yp.to/djbdns/ipv6mess.html, explaining this in much more detail.)

• 
  a proposal where e-mail could simply consist of a delivery notice being sent, whereas the actual e-mail itself would be held on the sender's server itself, until the recipient decides to get the message

The only protocol that I have heard proposed is IM 2000. Is this what you were talking about, or do you know of others?

Charging per email should be the last resort. It is unfair on those who do not abuse email (unless the price of the email is received by the person who bears the other cost of the message). It also increases the complexity of email. It would not eliminate spam.

A better way of easing the spam problem is to make the sender bear the cost of sending messages (not to artificially impose costs on the sender, but to relieve the recipient of the costs of spam). Why is Internet Mail 2000 not a suitable solution?