Slashdot Mirror

What makes you think that this is going to do anything for junk email. Until the burden of the spam is placed on the sender and not the receiver this problem will never go away. See http://cr.yp.to/im2000.html for a workable solution.

Or there's Internet Mail 2000, which is unfortunately-named but does what you're talking about. As for DNS, well, it's a mess.

=sensor-a.someclient.ny.us.hyperglobalmegacorp.com :1.2.3.4:60

The IPv6 transition could have been done better, but I'm afraid it's a bit late for that.

For meaningfull discussion of that point, take a look at what djb says:

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

Richard Stallman urges a boycott of them. The article he links to from his website is: http://cr.yp.to/writing/ieee.html

Richard Stallman urges a boycott of them. The article he links to from his website is: http://cr.yp.to/writing/ieee.html

Crikey, to confuse Richard Stallman and Dan Bernstein on /.
Now I've seen it all...

I'm posting this anon as I really don't want my name getting back to anyone in a position of authority at the IEEE (I know some of them, and... well, let's just say I'd rather stay anon), but this article pretty much sums up the sheer profiteering that goes on in academia today. My particular target is the IEEE, who - if you look at their most recent accounts - have net assets of something like $300 million, charge a fortune for membership (the lowest levels of which get almost nothing for their money, really), force you to transfer your copyright over to them when submitting to a journal or conference they sponsor or run, etc.

Richard Stallman urges a boycott of them. The article he links to from his website is: http://cr.yp.to/writing/ieee.html

Read it - it's important! We ran a conference sponsored by the IEEE in the last 24 months, and we had to pay 14% of our gross expenses to them as an 'administration fee', despite them doing absolutely nothing to help us whatsoever other than to allow us to use their logo (if you want your conference to be a success and regarded highly, you need their name attached really, which is sad as it gives them so much control). If we'd lost money, they would've - at most - given us 10% of our expenses back to help us. Whatever happens, they profit, despite their tremendous net assets.

I'd love to see what sort of salaries the upper echelons of the IEEE staff are making.... all thanks to the academics who are pretty much forced to use them....

Sorry, DJB's software is released under no license at all - he claims that simple copyright law is all that's needed:

"In the United States, once you own a copy of a program, you can back it up, compile it, run it, and even modify it as necessary, without permission from the copyright holder. See 17 USC 117".

"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."

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

Unfortunately, I think BIND (in its infinite brokenness) didn't handle that very well or something.

BIND seems to handle it just fine; I don't know of any problems with UTF-8 in BIND. I still don't get why punycode was invented, and this is the one issue where I agree with Daniel J. Bernstein. See his page on the issue.

http://pi.cr.yp.to/

As a side note, it's interesting that Slashdot says this link is at cr.yp.to.

... have already been explained.

Uh-oh, don't tell DJB; he may throw a conniption fit at you for violating his license terms.

Uh-oh, don't tell DJB; he may throw a conniption fit at you for violating his license terms.

I figured that the Qmail license is at:
http://cr.yp.to/qmail/dist.html

How does permission differ from license? (IANAL, but is there a difference?)

You are right that the license is not certified by OSI, but it does meet their definition due to paragraph 4 (which seems like it was written specifically for Qmail).

There are researches directed toward post quantum cryptography, to find asymmetric cryptography resistent to quantum computer, you can google for post quantum cryptography or look here:

http://postquantum.cr.yp.to/

or here:

http://eprint.iacr.org/2004/297.pdf

Seriously, no one should use OpenDNS. The solution to Charter's fuckery is to run your own caching DNS. The ideal software for this is djbdns. Just switching from your ISP's DNS servers to some fly-by-night third party's servers is RETARDED.

Paul Mockapetris, chief scientist at Nominum Inc. and founder of the DNS system, recently suggested that DNS operators keep a current copy of root zones in order to isolate themselves from future root-server attacks. Sexton points out that if local root zones were a common practice, DNS operators would seldom notice any root-server outages. An obstacle to this approach is the perception that it requires considerable technical expertise. Furthermore, the localized DNS automatically updates Root Zone data. This configuration allows the casual user to have up-to-date personal mirrors of root-server data without an intimidating hurdle of configuration. Such an approach could also be adapted for ISP or corporate DNS servers. The root-slave approach allows DNS operators to avoid the risk of future root-server attacks and, if implemented on a wide scale by individuals using a localized DNS or other DNS operators, it could reduce the motivation for future root-server attacks.

The method you illustrate will not allow for localdev access, will not allow for sound (unless you do some major work with esd as you mentioned earlier in your post), AND still requires you keeping an additional machine up-to-date. It can be done (I did it what a laptop so I could have a wireless "thin-client") Do a little more research before you begin attacking something. You clearly do not understand how LTSP works.

I think you missed a closing tag; sorry I missed this.

Sound is as easy as creating an esound system user on the thin-client and throwing sudo -u esound esd -tcp -public -nobeeps -terminate into its /etc/inittab—though for X and ESD process management, I prefer using supervise, part of DJB's daemontools. Many clients Just Work without setting ESPEAKER on the environment; for others, set that in ~/.xsession.

A thin-client is always an additional machine, and needs to be kept up-to-date as anything else. It runs software that gets new features and is subject to security problems from time to time: the Linux kernel, the X server, the sound server, any daemons to permit remote utilization of removable devices and media, SSH, and soforth. You're probably right in that I'm not familiar with many recent aspects of LTSP; it's been years since I've used it. I found that using a mainstream Linux distribution on my thin-clients gives me excellent package-management, extensibility, and doesn't require me to install "black-box" packages on the system running my workstation software.

There was a guy who proposed something called RSS-mail a few years back. It was the same guy who came up with SPF I think.

Quite possibly you are thinking of Dan Bernstein, the guy behind QMail, and his Internet Mail 2000.

He now has to store all of them on his server for some period of time so that you can pick them up.

Actually, no, all he has to do is implement a server that emits the same message every time somebody asks for one. You don't have to store a million emails to send a million emails, you just have to store one.

Yes. Software developers should adopt /package for their software, giving their users atomic upgrades and downgrades, and easy side-by-side installations. Also see sptools and spftools for managing these types of packages.

Please explain the juvenile fascination with the ability to make exact copies of your media. What's the point of bringing this up?

You can do lots of things with it that Apple/Microsoft/... don't want to acknowledge and are very motivated to eliminate.

1. First-sale Doctrine
The courts said, "We held that the exclusive statutory right to vend applied only to the first sale of the copyrighted work..." Treats the music like software. You own it despite what the mega-corps would have you believe. http://cr.yp.to/softwarelaw.html

2. Audio Home Recording Act of 1992 "fair use privilege"
In stark contrast, the court held that the Rio is entirely consistent with copyright law's fair use privilege that gives consumers the right to make copies of works for their personal use. Once a music file passes through a computer, it is not legally required to impose restrictions on consumer freedoms... http://www.eff.org/cafe/cafe_case_analysis.html

I'm willing to bet both arms and both legs that Microsoft has this one covered legally. The writing of EULAs has become a finely honed art. They will cover this in the EULA, and there won't be a damn thing that people who have agreed to the EULA can do about it.

This type of attack has been mentioned before per DJ Bernstein's paper on "Cache-timing Attacks on AES":

http://cr.yp.to/papers.html#cachetiming

PDF format:
http://cr.yp.to/antiforgery/cachetiming-20050414.p df

PS format:
http://cr.yp.to/antiforgery/cachetiming-20050414.p s

This type of attack has been mentioned before per DJ Bernstein's paper on "Cache-timing Attacks on AES":

http://cr.yp.to/papers.html#cachetiming

PDF format:
http://cr.yp.to/antiforgery/cachetiming-20050414.p df

PS format:
http://cr.yp.to/antiforgery/cachetiming-20050414.p s

This type of attack has been mentioned before per DJ Bernstein's paper on "Cache-timing Attacks on AES":

http://cr.yp.to/papers.html#cachetiming

PDF format:
http://cr.yp.to/antiforgery/cachetiming-20050414.p df

PS format:
http://cr.yp.to/antiforgery/cachetiming-20050414.p s

I have been thinking of finding a decent daemon for DNS caching, but I don't want something I'll have to fiddle with alot to get working or uses a huge amount of resources. (I don't want to use bind)

dnscache (part of djbdns) works well and has a small footprint.

All of these solutions have flaws. I'm with deBoynePollard on this:

• SPF is harmful
• Anti UBM don't work

An interesting take is to make the sender responsible for storing mail: suggested by Dan Bernstein (DJB), the qmail guy.

There's always politics in it. Some people don't like DJB's attitude and they're anti-qmail and go for Postfix or sendmail.

Wietse Venema, the postfix guy, isn't too happy about SPF either: but he does provide plugins for Postfix.

SPAM needs a solution, but breaking SMTP isn't the way to go IMHO. I think a well configured email server, RBLs, requiring reasonable RFC compliance and such will eliminate much SPAM. Spending energy on evangelising good mail server configuration is still the best way to go.

I'd love to use IPv6, but reading djb's take on ipv6 really makes me wonder if we're ever going to get there. I don't know what the current situation is, but from reading djb's comments it looks like if I deploy servers on IPv6 only, then I'd have a network that would be completely separated from IPv4!

The IPv6 mess by D. J. Bernstein
The IPv4 address crunch
Computers on the Internet talk to each other through IPv4, version 4 of the Internet Protocol.
Each computer on the Internet has its own public IPv4 address, similar to a phone number: for example, 131.193.178.181. The target of each packet of data is identified by a public IPv4 address.

Problem: There are only a few billion public IPv4 addresses. Many of those addresses have already been allocated. What happens when we run out of public IPv4 addresses?

Partial solution: Do all these computers really need to be on the Internet? A company with 20 computers browsing the web doesn't need to put all those computers on the Internet. It can have a single computer on the Internet (a ``proxy'') that retrieves data from web servers on behalf of the other 19 computers, forwards telephone-over-IP calls from the other 19 computers, etc.

Most people agree, however, that proxies merely delay the inevitable.

Long-term solution: IPv6, version 6 of the Internet protocol, has many more addresses. There are other improvements from IPv4 to IPv6, but we can survive without them; what's really important is the expansion of address space.

Basic interoperability issues
Suppose someone sells you a public IPv6 address. You put your computer on that address. You find that you can't reach the CNN servers or the Google servers or your company's web servers. How will you react?
This is an example of what's called an interoperability failure. Right now, many---in fact, most---Internet servers can't talk to clients on public IPv6 addresses. Until this changes, using a public IPv6 address instead of a public IPv4 address will be a disaster for clients.

Similarly, many---in fact, most---Internet clients can't talk to servers on public IPv6 addresses. Until this changes, using a public IPv6 address instead of a public IPv4 address will be a disaster for servers.

Conclusion: Before clients can be safely deployed on public IPv6 addresses, practically every server will have to learn how to talk to those clients. Before servers can be safely deployed on public IPv6 addresses, practically every client will have to learn how to talk to those servers.

Public IPv6 addresses have an inherently lower cost than public IPv4 addresses, because there are many more of them, but this cost advantage won't matter as long as public IPv6 addresses are noticeably less useful than IPv4 addresses. Right now, public IPv6 addresses are practically useless.

(In response to this page, one commentator said that he had set up public IPv6 addresses, and that those addresses could talk to various public IPv6 addresses at other sites. This doesn't mean that those addresses are useful. The entire Internet is reachable through IPv4; only a small part of the Internet is reachable through IPv6. The sysadmin could eliminate his public IPv

"inertia to change" is not a simple binary flag that gets set when you are old and crotchety.

The main reason it gets set is because people have to pay bunches of money and do a hell of a lot of work, and the payoff is basically that things work about as well as before, except for a bunch of inevitable glitches that could annoy paying customers.

Not providing a sensible transition mechanism was a major failing of IPv6.

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

What you also didn't know is that I was building computers with discrete transistors forty-three years ago; I suspect you might have been in diapers at that time.

You realize that you've completely discredited yourself by writing that, right? You've shown that even though you really should should know better, you don't.

Pointing to an article that has somebody summarily dismissing IPv6 (which was a perfectly legitimate thing to do in 2004, but not anymore), when IPv6 is in fact being deployed, does not help your case. Using inappropriate terminology doesn't help either.

What does assembling now-obsolete computers have to do with IP networking, anyway? You might as well have said that you have a Ph.D. in Mathematics. While possibly impressive, it's irrelevant to the topic at hand. You're outside your field of expertise.

IPv6 is happening whether you like it or not. Yes, there might have been a better way to handle the transition (which clueful people like Dan Bernstein have already discussed), but it's happening and for good reasons.

Spot on. I was only thinking about time cost and not really considering storage cost. The paper you reference, for those interested in trading some of the storage cost I cite for some additioinal time cost, is available here.

You are mistaken. Elliptical curve cryptography is broken by quantum computers. And yes, I am a quantum physicist.

It's true that you probably won't get a system-crashing memory error every week, but memory errors do occur, and they can crash systems or applications and corrupt data. Certainly you recognize that.

I suggest that everyone read Bernstein's advice regarding ECC memory here.

The same reason why Dan Bernstein used the 1955 RAND tables to generate a constant for a public-key signature system he designed: It's very unlikely that somebody 20+ years ago, with the technology that was available 20+ years ago, would be able to craft a Thompson hack that would successfully insert a backdoor into something like gcc 4.0, which hadn't even been imagined at the time.

Of course, if you don't already have an old Tandy machine, and you instead try to acquire one from eBay, you won't really know that it hasn't been modified more recently.

Now you start to seem like you have a too broad view of what algorithmic improvement is. Algorithms have nothing to do with code, they're a level of abstraction above (as you can see in any scientific paper presenting a new algorithm, they rarely give anything more than pseudocode). Instruction scheduling is NOT an algorithmic improvement, it's an platform dependent implementation detail.

Their FAQ answer which says compilers aren't good at it just shows that they also think a human is better at optimizing code.

Even the only one which doesn't mention asm explictly is speaking about registers, which you can't manipulate directly in C. I don't want to sound like an ass but at least show some knowledge regarding what we're talking about...

And to clarify: my point is there a good assembly programmer can often do much better than any compiler, and that things will stay that way for some time to come. Eventually the situation may be the opposite, but right now it surely isn't!

Correction: your C compiler is fater at multiplying by 9 than crappily written assembler. Thats a pretty small corner you've got yourself and your case into there.

The more abstract a language is, the better a compiler can understand what you are doing

Except it doesn't. Nobody has written a compiler that smart, and I don't care what anyone says: I don't think anyone ever will.

Learning how to invent and develop algorithms is important. Learning how to translate those algorithms into various languages is important. And knowing how the compiler will translate those algorithms into machine instructions- and how the CPU itself will process those machine instructions, will yield a lot more performance than choice of languages.

Consider djbfft, one of the fastest FFT implementations, outruns many FFT implementations in Java, Haskell, Lisp, or assembly, and yet it's written in C.

Don't confuse me: I'm not saying C is fast, or C is good, I'm saying djbfft is good. Reordering the instructions in the C code will lower the efficiency- even if the code is otherwise equivelent.

That said, I agree with almost everything else in your post.

Not many years ago (with gcc), I got an 80% speed improvement just by rewriting a medium sized function to assembly.

An expert assembly programmer in a CPU which he knows well can still do much better than a compiler.

--
This .sig intentionally left blank

http://cr.yp.to/
http://freenet.sf.net/

The IPv6 mess explains why a fundamental mistake on the part of the IPv6 designers has had giganitc effects on the cost of making an IPv6 Internet work in practice.

Just set up your servers with single stack IPv4/6 and listen on the v6 port, and you're done

No, I'm not “done.” I still need to

1. acquire my own public IPv6 address, and
2. announce that address in DNS alongside my public IPv4 address,

or else IPv6 clients won't be able to connect to my server.

Besides, you missed Bernstein's point. If you're asking me to configure extra options, you've already lost. His solution to the address crunch is better that the current IPv6 specification because he has come up with a way to make the transition to 16-byte addresses happen automatically as part of regular software/hardware upgrades, with no extra configuration.

What are you trying to argue? That an automatic transition would be a bad thing? That an automatic transition has higher costs associated with it than a nonautomatic transition? I suggest you reread The IPv6 mess carefully.

Where did DavyGrvy mention turning off IPv4? They work together, you know. Do even Slashdotters not understand that adding IPv6 to a network does nothing to reduce IPv4 connectivity? It's win-win.

How is it “win-win”? It costs money and effort for every administrator of a computer on a public IPv4 address to also acquire and enable a public IPv6 address. What exactly is their reward for spending time setting up useless IPv6 addresses their perfectly functional IPv4 machines?

IPv6 tunnels over IPv4. IPv4 tunnels over IPv6. Machines running IPv4 can talk to machines running IPv6. Machines running IPv6 can talk to machines running IPv4. IPv6 still has issues, to be sure, but interoperability with IPv4 isn't one of them.

The showstopper with IPv6 is that it was not designed with a coherent transition plan in mind. Sure, once everyone is using IPv6 it should work fine, but making the switch from IPv4 to IPv6 has enormous costs associated with it.

The IPv6 mess by D. J. Bernstein has much more detail:

“The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.

“In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other. The specifications could have defined a functionally equivalent public IPv6 address for each public IPv4 address, embedding the IPv4 address space into the IPv6 address space; but they didn't.

“This might sound like a very small mistake: after all, once IPv6 is working, we can move everything to IPv6, so who cares about IPv4? The problem is that this mistake has gigantic effects on the cost of making IPv6 work in the first place.

“In short, because of this mistake in the IPv6 design, making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address—and, for the same reasons, every administrator of a client on a public IPv4 address—has to go to extra effort to acquire and enable a public IPv6 address.

“Example of the difference: As of 2002.11, Google hasn't published IPv6 addresses for www.google.com. What exactly is Google's reward for spending time setting up useless IPv6 addresses for its perfectly functional IPv4 machines? In contrast, they've had IPv6 software for years.

“Under the current IPv6 specifications, to make the magic moment happen, not only do we have to convince a few thousand network programmers to do something with no immediate benefit, but we also have to convince millions of computer administrators to do something with no immediate benefit. This is an incredibly bad way to handle a transition.”

We would have had a significant IPv6 population by now if interoperability were baked in, like the MX mail record transition. Instead we have funky ways to support both setups (6to4, Teredo, etc). So IPv6 is a toy for admins, with little real benefit, except to alleviate the bogeyman address crunch in the indeterminate future. End result is balkanization and a few golden bridges.

DJB still has it right: http://cr.yp.to/djbdns/ipv6mess.html .

If there was a decent ISP that provided both IPv4 and IPv6 connectivity with little to no overhead, I'd seriously start looking and doing pilot projects. Until that happens or the IPv6 killer app comes along, I don't see much movement from IPv4.

This is the killer bit for me, I recently moved my network from a /26 to a /28 Ipv4 (it was faster) ... and it cost a non-trivial amount. I asked about only having a /29 with ipv4 and having ipv6 too, assuming it would be cheaper (and I could handle a bunch of machines being ipv6 only), but my ISP doesn't offer any ipv6 ... and they said it's because it would cost them more than just getting ipv4 addresses.

Even discounting the whole ipv6 migration problem, the fact you can't even realistically get ipv6 conectivity years, and years after it was introduced is stopping it.

I wonder if he'll open them up to the general public now.

This article is useful in that it gets people thinking about the problem. Now some clever person can come up with a proposed solution and post an article about it. That's how it works.

It's not like nobody's ever discussed these issues before. Or have they?

...DJB's "Internet Mail 2000" will never get real-world acceptance as they make it as difficult for legitimate bulk senders to broadcast as for spammers.

You should re-read the article from DJB. It makes a lot of sense, and it WILL solve many of the problems we have with spam, etc. The idea is you subscribe to lists you are interested in. Today, he might reference RSS. You check for new messages when you want. Legitimate bulk senders no longer send anything.

As for individual correspondence, a small notification is sent, telling you that a new message is waiting for you to be picked up at the sender's server. The notice is a low-bandwidth item, and it must link to a full time hosted server, which can be traced, or shutdown as needed. As per TFA, senders could be required to hash/sign the individual notes that would take up several seconds of CPU time, making it impracticle to send bulk messages as individual ones.

Want secure messages? Use SSL to retrieve them from the sender's server.

I'm not saying this will solve everything, or be impossible to hack, but it seems like a step in the right direction from a design standpoint.