Slashdot Mirror

V8 was invented by one of the denizens of Bell labs and the guy who funded ihnp4, and actually works. Because he refuses to let ISOC copyright his stuff and has been burned by the various I* groups he is somewhat of a pariah. However v8 actually works today and interoperates with v4 and has for years and is already in the Microsoft, Linux and BSD stacks.

If you look at the "6 over 4" spec and the v8 spec you'll realize it's the same thing and was adopted several years back, they simlpy adopted v8 and changed the name, the addresssing is exactly the same - just look at the bits.

Whenever somebody says IPV8 isn't real or is a joke ask them to explain it to you - they can't. THe derision is for political, not technical reasons.

And bseides, haveing Randy Bush call you a sociopath means you're on the right track

Parenthetically, the MTA you may be using when running Pine just might be a Microsoft mail server... so beware.

Links: Pine, Elm, Postfix, qmail. Might as well throw Lynx (web) and BitchX (irc) out there for you oldschool turbo C shell users. Home this gets me some karma :)

Glad there are some people out there not using GUIs for simple purposes like these. I hate the mouse.

why not just send the email header only - and require the originating server to hold the email content?

You're half-way to re-inventing Internet Mail 2000, then.

I think the only thing that will resolve the spam issue is abandonment of SMTP as we know it, and an adoption of a new protocol

You may be right on this part.

that enforces traceability.

But I don't know whether you're right on that part.

Have you looked at DJB's Internet Mail 2000 yet? I don't know whether that will "solve spam", or whether it's even viable. But anyone who's interested in these issues should definitely look at it.

A similar system will need to exist for mail, that will require some sort of a registration and compliance to join the "mail provider" network, whatever that will be.

A centrally managed e-mail network? *shudder* No thanks!

Sure. I was commenting on the tangent regarding the number of worldwide mail domains.

Howver, 100k is also a low estimate for hosts.

In 2001, Dan Bernstein did this survey which yields an internet-wide estimate of 4 million reachable IP addresses running an SMTP server. I doubt the figure has decreased.

Scalability over many orders of magnitude is a fairly key requirement for internet protocol design.

Wow! You just invented IM2000!

See also The IPv6 Mess by Dan J. Bernstein of Qmail/DJBDNS fame.

Ah, but ftp is horrible, and only remotely secure if you use it in passive mode anyway.

Of course there are a large number of P2P-like protocols that NAT totally destroys, but no more than any kind of firewall. (since you can explicitly pass ports through NAT as well)

Speaking of encyrption and the ridiculous fight with the government over it, this is a good time to introduce someone to all the young bucks around here who may have never heard of him - D. J. Bernstein at cr.yp.to

I keep clicking that link to the encryption section, but the case is never resolved. He's doing a lot of important stuff in the arena of encryption and the government's reaction to it, and I encourage everyone to follow along with it.

Speaking of encyrption and the ridiculous fight with the government over it, this is a good time to introduce someone to all the young bucks around here who may have never heard of him - D. J. Bernstein at cr.yp.to

I keep clicking that link to the encryption section, but the case is never resolved. He's doing a lot of important stuff in the arena of encryption and the government's reaction to it, and I encourage everyone to follow along with it.

It means that any system administrator can configure their mail transfer agent to bin any spam pretending to come from aol.com with a 100% success rate. And this goes for anyone else publishing an SPF record for your domain.

SPF is a proposed standard for a domain owner to tell mailers where mail From: that domain may originate. The domain owner publishes a DNS TXT record for their domain with (at the simplest) list of IP addresses. Participating mail transfer agents can then look this record up and make a policy decision on whether the mail is likely to be legitimate. The presence of an SPF record on a domain at present means that while you still can't be sure when you're handling spam, you can be sure when you have a piece of non-spam because the SPF record tells you so.

SPF is not a wholly original idea (e.g. up "designated mailer protocol"), and certainly not the simplest implementation but the important factor is that its proponent, Meng Wong, is an excellent lobbyer and spokesperson, as well as someone who as the nous to put forward a useful protocol (he founded pobox.com). It's currently at the point where lots of implementation are being written, with the canonical version being Meng's Perl modules. Currently I'm helping to finish the C implementation which will shortly be integrated into qmail and exim.

The tipping point (I hope) will be when a domain not publishing an SPF record or publishing a globaly permissive one will be considered "obviously" untrustworthy. Combining SPF authorisation with a more traditional "From: domain blacklist" will give spammers a very very hard time indeed forging mail. But AOL publishing a record (we hope) shows the way the wind is blowing: the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.

So go on, it's dead easy, publish a record for your domain now. Tell people where your mail comes from. Look, there's even a wizard to help you.

I wonder if djbdns can use SPF records.

From what I can see of SPF, it's just a matter of setting up the TXT record in DNS.
rbldns does it in djbdns.

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

there you go!

• rrset-order is still broken.
• GSS-TSIG support is still missing.
• Strange multi-threading bugs still exist
• Awful security history isn't behind it yet.

Does this sound like bullshit to you ? If so, see the following:

• Read the bottom parts of this and the links at the bottom of this
• Nominum/ISC relationship described here

AAARRGGHH.

• rrset-order is still broken.
• GSS-TSIG support is still missing.
• Strange multi-threading bugs still exist
• Awful security history isn't behind it yet.

Does this sound like bullshit to you ? If so, see the following:

• Read the bottom parts of this and the links at the bottom of this
• Nominum/ISC relationship described here

AAARRGGHH.

• rrset-order is still broken.
• GSS-TSIG support is still missing.
• Strange multi-threading bugs still exist
• Awful security history isn't behind it yet.

Does this sound like bullshit to you ? If so, see the following:

• Read the bottom parts of this and the links at the bottom of this
• Nominum/ISC relationship described here

AAARRGGHH.

• rrset-order is still broken.
• GSS-TSIG support is still missing.
• Strange multi-threading bugs still exist
• Awful security history isn't behind it yet.

Does this sound like bullshit to you ? If so, see the following:

• Read the bottom parts of this and the links at the bottom of this
• Nominum/ISC relationship described here

AAARRGGHH.

It won't be "ready to carry arbitrary identifiers" until BIND stops rejecting unknown types. Or until everyone switches to something that works. :-)

djbdns!

One of these talking points is to license software developers and make them accountable for security breaches.

It seems to really prevent all possible security breaches, you need to prove that the program is correct first - I don't know of many entities that even try to prove their programs. I have heard of a few telecom infrastructure programs, but remember the big SS7 outage caused by one tech some years ago? The SS7 code is probably better "audited" than most code but would that outage have been construed as a "security breach"? - Yes, after the lawyers were done with it.

What about how quickly the world changes after a program is released? You use the best encryption technology of the day, you prove your programs correct, not just audit the code or use "good" software engineering/management methodologies. But you used DES (back in the day) or MD5 more recently, then MD5crack comes along or quantum computing and suddenly you are responsible for a "security breach" because of some exploit that didn't exist when you created the program.

That is nuts, who would want to sign up for that?

Besides DJB does anyone even have the balls to reward people for finding security problems? Or even advertise security as a feature? OpenBSD (yeah, I know its dead, blah, blah, blah), pureftpd, NSA Linux
I expect not many others, because people expect code to have security issues.

Since security is such a big concern now (and in the past), I would think that people who wanted to show off their programming prowess would be bragging about how secure their code is. But no one does, that I know of - why? because its just damn hard to be sure that the code is perfect - which is what is required to prevent all possible security problems. So where are all these people with the big security cahones going to come from?

Can a program be proven correct for all inputs?
If it isn't stateless then can each permutation of state and input be proven?
Are all the protocols used by the program verified?

The impossibility of preventing security breaches seem to make this kind of government action more likely. Burn the witches!! They hexed our computers, and were seen in the woods cavorting with unaudited code fragments!

There is a different proposal, to change the economics of spam at

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

The basic idea is to make the sender responsible for mail storage shifting
costs onto the sender in a way that makes large mailing lists simpler.

>Some ramifications of this concept
>
>Each message is stored under the sender's disk quota at the sender's
>ISP. ISPs accept messages only from authorized local users.
>
>The sender's ISP, rather than the receiver's ISP, is the
>always-online post office from which the receiver picks up the
>message.
>
>The message isn't copied to a separate outgoing mail queue. The
>sender's archive is the outgoing mail queue.
>
>The message isn't copied to the receiver's ISP. All the receiver
>needs is a brief notification that a message is available.
>
>After downloading a message from the sender's ISP, the receiver can
>efficiently confirm success. The sender's ISP can periodically
>retransmit notifications until it sees confirmation. The sender can
>check for confirmation. There's no need for bounces.
>
>Recipients can check on occasion for new messages in archives that
>interest them. There's no need for mailing-list subscriptions.
>
>Some advantages
>
>In the old Internet mail infrastructure, keeping track of
>undelivered messages takes a lot of work. The mail client (e.g.,
>ezmlm) and mail transfer agent (e.g., qmail) have to support
>variable envelope return paths; bounce messages then have to be
>parsed by an automated bounce handler that matches bounces with
>original messages. In IM2000, each message in the sender's archive
>carries its own delivery status.
>
>In the old Internet mail infrastructure, bounce messages are often
>misdirected by low-quality software. Users end up receiving bounce
>messages that should have been sent to an automated bounce handler.
>In IM2000, there are no bounce messages.
>
>In the old Internet mail infrastructure, mailing-list managers have
>to keep track of mailing-list subscriptions. Typical subscription
>protocols are slow, complicated, unreliable, difficult to automate,
>and trivially subject to forgery. In IM2000, mailing lists are a
>purely local matter for the receiver's software.
>
>In the old Internet mail infrastructure, the receiver's ISP has to
>carefully write every message to disk, so that messages will not be
>lost if the computer crashes. This limits the amount of mail that
>can be received. In IM2000, the receiver's ISP can keep
>notifications in memory.
>
>In the old Internet mail infrastructure, a message to a large
>mailing list is written to disk on a huge number of computers. In
>IM2000, a message to a large mailing list is written to disk only by
>a few receivers who want to save local copies of the message.

There are already reference libraries available that work with 64 bit time values, such as TAI (Temps Atomique International). See libtai for more info. I like the following quote: "Under many cosmological theories, the integers under 2^63 are adequate to cover the entire expected lifetime of the universe; in this case no extensions will be necessary."

The main problem is crossing the before/after boundary of converting from 32- to 64-bit times. All of a sudden you need two sets of programs to deal with data, depending on whether it was written before or after the switch. Think backups. Think binary database dumps. Panic.

You should check out libtai. It is a time format by the author of qmail (and other infamous adventures), DJB.

I've built my own libraries to deal with the format and after heavy thought on the subject, I do feel that it serves pretty much any practical purpose for timekeeping. 64 bits for the second with 0x4000000000000000 corresponding to the Unix epoch minus leap seconds since 1/1/1950 (commonly used as a reference epoch for astronomy), plus two 32 bit ints for the nano and atto fractional parts of a second for the TAINA flavor.

It won't get us to Plancktime scales, but that's still quite a bit of resolution. And the library he provides is built to take into account TAI-appointed leapseconds! Very useful!

Two points:

* Who cares if SMTP was an excellent protocol in the environment it was designed in. What matters is that it is completely inadequate today - I'm not blaming the designers, it's the fault of people who still think SMTP is good and we should bolt more shit onto it instead of using a protocol that works in todays environment.

* It's not just about trying to add security to make up for the "lost appropriateness of trust", the problems with SMTP are more fundamental than that. SMTP places the burden of delivery upon the receipient and there will be no significant answers to the spam problem while this remains the case. Internet Mail 2000 is one example of an attempt at that problem - the sender (rather than the recipient) provides a server for the recipient to retrieve their email from, the sender can't fake the IP because then their message can't be retrieved, the sender must also keep the server online for the message to be retrieved. Not a spam solution in of itself, however it is an infrastructure than a working spam solution (either legal or technical) could actually be built on.

Personally I think email is a dead duck, the adoption problem will prevent people from switching away from SMTP, and SMTP will prevent the elimination of spam. Centrally controlled Instant Messaging, or some other spam free technology will slowly replace email. A shame really.

With syncookies.

Also, I think the messages should be stored on the relay, with just a URL sent in the mail body. It would solve two problems: * The size of the message will be limited by the size of the sender's mailbox. * It will use more resources on the relay, and the admin should be less likely to run an open relay.

This has allready been proposed by Dan Bernstein: IM2000

Internet Mail 2000

Solves the problem of blowing up your friend's mailbox with huge attachments.

BIND is safely chrooted away where it can (hopefully?) do no harm until I get around to writing a replacement

Here you go.

OK, one more comment. :)

I was somewhat wrong. Sendmail actually does the rewriting of RFC822 headers in some situations (if your sendmail.cf specifies this). I find this a deplorable practice, but whatever.

See here for more details: http://cr.yp.to/im/cname.html Basically, don't use CNAMEs with mail.

The *only* (and fatal) flaw with IPv6 is lack of backward-compatibility.

And it's never, ever going to work without it...

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

(and he really does have the best host/domain/tld combo in existence)

it wasn't until fairly recently that NAT would actually deal decently with FTP, but it requires mangling the packets.

The original RFC includes PASV, which is all you really need. The alternative, using PORT, may not be a good idea anyway.

since NAT is useless for servers, you're only going to see it on clients

This, I think, will actually become a problem. As people want to do more with the net, there's more cases where allowing connections into a machine becomes useful. You have to do really annoying hacks to do that (or something equivalent) with NAT.

your isp cached the fatal response. you have to wait for the fatal response to expire from their cache before they query the root servers again. Or run your own dns server.

Software is covered by first sale, even though you have to copy it in order to use it. This is because the United States Code contains a specific exception for software users. The exception is:

Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:

(a) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner

DJB's page on Software Rights

I am not a lawyer though...

Compare Apache's webserver market share to that of Microsoft IIS. Compare the number of exploitable vulnerabilities in those products, and the severity of the results.

Compare Sendmail's SMTP server market share to that of Microsoft Exchange. Compare the number of exploitable vulnerabilities in those products, and the severity of the results.

Compare Oracle's (or IBM's) SQL RDBMS market share to that of Microsoft SQL Server. Compare the number of exploitable vulnerabilities in those products, and the severity of the results.

Deduction: Microsoft manages to lead in introducing exploitable vulnerabilities to market segments, with severe results, even in segments where they do not enjoy market share leadership.

Now that's innovation! :)

To be blunt and honest, Microsoft designed and maintained its operating system product(s) in ways that failed to take security (and multiple users, and networking, and...) into consideration for far too long, and now finds itself in the unenviable position of being the only operating system vendor most people have even heard of that doesn't have a properly secure operating system.

-Dan (whose new "cheesegrater" G5 has fewer holes than Windows)

I've said it before, and I'll say it again. We need to dump SMTP and switch to something like Internet Mail 2000. The sooner we do it, the better. Some people here have voiced concerns, but I'm convinced that this proposal is well thought out and will work. Any inconvenience (which would be minor, and only for a small fraction of users) would be trumped by its benefits, by a wide margin.

Anyone know if anyone is actually coding up a sample server and client for IM2000? A google search for "internet mail 2000" comes up with some proposals that go beyond Bernstein's site, but I haven't seen any evidence of code yet. It really shouldn't be that complicated and, yeah, I'd be willing to help!

despite what people think how eccentric djb is this is still a major win for someone who actually stood up for what he believed in rather then people who say what they believe about the the SCO case or the RIAA or MPAA.

DJB is accepting donations here for his case and for his open source writing.

Numerous people and businesses have benefited his work and he deserves every contribution he receives.

Related reading is a little sparse on this story, but I think these two links under the "related links" section should bring you up to speed (although the reading in the second is undoubtedly dry...):

• djb's crypto case has been dismissed
• document archive

Dan has a more complete archive than the EFF's at: http://export.cr.yp.to/

They are all insecure.

qmail is secure.

I'm not trying to be smart, but that's like sarcastically saying "Next time I'll bone up on the rules of baseball before I play a baseball game" after you're thrown out for trying to run straight to 2nd base...

This case has been around for years and Bernstein is a well known figure in the field of crypto research. If it was something that interested you enough to enter the story, you should have either already known about it or gone and looked up the history of the case. Google's for research, Slashdot's for current news.

I just checked there still just stub pages :( http://cr.yp.to/crypto.html

The case archive is now http://export.cr.yp.to. That archive has about 200 of the case documents; the old EFF archive has only about 100.

Who the hell is Bernstein?
I'm as confused as you, but I did find this, which is apparantly his website.

The right thing to do is to run two services one for DNS cache, the other as your authoritative nameserver.

Where I presaume you are just believing whatever DJB's seperation page says? And his (only three) arguments are... Compromise of your cache is a compromise of your authoratitive data, DOS attacks on your authoratitive server can also DOS your caches, and doing seperation allows you to change software easily.

The first doesn't affect anyone small enough to do this, IMO. The second is laughable (it's much easier to just DOS the network). And the third is crack ... fixing your damn software would allow people to easily replace both their auth. and cache DNS software. And you'd only need to do it once.

Even BIND idiots recommend to run BIND this way.

Yes, it can be useful. But it shouldn't be required. In the same way that I'd recommend to any and all real ISPs that they should have seperate machines (possibly with seperate software) for smarthosts, MX servers and MX relays ... but I sure as hell don't need that for my email server which can do all three (even if I do get an above average amount).

DJBDNS, anyone?

The Bind authors are known idiots. Much like users of their software. It's buggier, more resource intensive and slower, but at least it costs more!

It's nowhere near as difficult to set up as BIND, it's more secure than BIND, and there's a patch available to block Verisign's wildcard lookups. I've been running the patched version at home and at work since shortly after Verisign added the wildcard records and haven't had issues with any DNS queries.

>Damn you tricksy Canadians and your exchange rates!

Heheheh... time for a worldwide currency!

>Throw in a bit of back bacon, and you've got a deal...

We could manage it, I'm sure. The weird thing is, a lot of shops call it "peameal bacon" here... :-)

>You're right, I was being tremendously presumptuous that a Linux user would be trolling the Apple channel.

No, you weren't really, I was a bit miffed at the whole "big corporation" thing, sorry. I was even one who boosted linux for every purpose. Having run a business for a while, I can see that I was wrong. It works tremendously well for some tasks (our Point Of Sale machine runs Quasar flawlessly, and there's no debate that linux runs our servers better than we could possibly need [BIG THANKS DJB!]) but is useless for others (Video Eiditing is just so much easier on windows. Don't know about on a Mac. I've heard it's easy on one of them too, but I can't bring myself to afford one.)

Linux, windows, MacOS, they all have their place.

Looks like Dan Bernstein was on to something when he said BIND's design was fundamentally flawed and would result in vulnerability after vulnerability. Just goes to show you that sometimes the most paranoid among us can still be on to something.

You are referring to these pages:

http://cr.yp.to/djbdns/blurb/unbind.html

http://cr.yp.to/djbdns/blurb/security.html

Looks like Dan Bernstein was on to something when he said BIND's design was fundamentally flawed and would result in vulnerability after vulnerability. Just goes to show you that sometimes the most paranoid among us can still be on to something.

You are referring to these pages:

http://cr.yp.to/djbdns/blurb/unbind.html

http://cr.yp.to/djbdns/blurb/security.html

Basically, RMX has [two] critical flaws. First, it requires a new DNS resource record type, which is going to require everyone to upgrade their name servers if they want to use it.

Sysadmins who use real DNS software have no such burden. The tinydns data file format provides an easy way to include data of arbitrary types, which is equivalent to creating new RR types on the fly. See this page (search for "Generic record").

Basically, RMX has [two] critical flaws. First, it requires a new DNS resource record type, which is going to require everyone to upgrade their name servers if they want to use it.

Sysadmins who use real DNS software have no such burden. The tinydns data file format provides an easy way to include data of arbitrary types, which is equivalent to creating new RR types on the fly. See this page (search for "Generic record").