The Case for Rebuilding The Internet From Scratch

dotnothing writes "I just caught a column on a security site advocating for a total start from scratch as far as certain internet protocols like SMTP. It's an interesting idea and there are some ideas on how to conduct the transition... if everyone would agree on something like this it would definitely reduce the spam (among other things)."

Comments

Re:Rebuild the Internet?

[caluml]

If you're not using it, it's your fault. I personally don't know if I reach a site through IPv4 or IPv6, as my system tries to resolve the v6 address first, and falls back to 4 if there aren't any 6 addresses. All my admin is done over IPv6. If you don't want to use it, well that's up to you. Look up 6 over 4 tunneling. Look up v6 tunnel brokers - https://tb.ipv6.bt.com/ is a good one.

And to test your IPv6 connectivity - http://ipv6.umtstrial.co.uk/

Not going to happen

[Neophytus]

I can see IPv6 being phased in in the next couple of years as the IP problem becomes more intense and NAT becomes even more of a royal pain in the backside. What I don't see happening is twenty years of maturity (in some form) being tossed out the window. It would be a shame to see existing protocols being dumped because they arn't secure - most of the time it is the IMPLEMENTATION that doesnt work or has flaws. Many software packages should be scrapped altogether and rewritten and designed from the top - sendmail is the example that comes straight to mind. So many flaws have come out over time it is silly. I'm not saying SMTP itself isn't flawed though, it most certainly is.

The people at PlanetJailbreak have designed, from scratch, on paper, the UT2003 version and the work has appeared to have paid off - an incredibly low number of bugs from their alpha testers have been reported. Where there have been many flaws in a package based on a fundamentally old codebase it should be rewritten totally, regardless of it being server or client software. The problem would be getting people to adopt - many people never patch a thing.

Re:This says it all...

[lseltzer]

I'm the author of the column under discussion. I hope I got my point across that whatever merit I see in this I doubt it could succeed in less than a long time.

But I don't see the spam filtering and security companies as the main obstruction. I see millions of users and companies who would have to change applications as the real problem. Whatever the benefits, this would be highly disruptive. As others have pointed out, look at how long it's taken to get almost nowhere with IPv6.

Guaranteed method of fighting SPAM

[Zone-MR]

Register your own domain or get an address like blah.ath.cx. Then host an SMTP server. You will get email addressed to anything under that domain.

If you need to give a site your email addy, leave in a reference to that site. eg slashdot@myname.ath.cx. That way if someone sells your address, an address leaks, or whatver, you know EXACTLY who is responsible, and you can block junk mail without affecting legitimate email.

Ive been using this technique for quite a while. I can check my email and be confident I have no spam whatsoever. At times when I got spam, it always turned out it was a single site that leaked my addy, and I easilly identified and blocked it.

Re:This says it all...

[stevens]

This guy has a spam filter that gets zero false pos/negs.

One of the important tests is the spammers do not know your identity, but your friends do. If I find my name in the body of the message, it is not from a spammer. But if a message Cc's several messages to the same isp, I know it is dictionary spam.

I looked at your program, and it does not work as advertised. I get spam with my name in the body. You may not be so unlucky yet.

Second, you filter on things that will trivially return false positives, like case-sensitivity on you company name. You program assumes that anyone who capitalizes it is a spammer.

Third, I have several friends on the same ISP (your ISP, actually) and we routinely have email conversations which have three, four, or more addresses from the same domain.

On any severely small sample of good mail, you can make a perfect filter, but in the general case, it will fail miserably.

Re:This says it all...

[ajs]

You're missing something that just about everyone who talks about "the limitations of SMTP" misses: SMTP isn't limited. SMTP has a standard mechanism for introducing extensions such as cryptographically certifying mail servers, and mechanisms already exist to allow for fast, distributed key recovery and verification.

Reading the RFCs is a very good start to understanding how to solve this sort of problem. Giving everyone on the Internet (or at least all of the SMTP-sources) an Identity and then actually attaching a record of trust to those identities would be a wonderful idea, and does NOT require replacing SMTP. In fact, if you do it very, very carefully, it probably doesn't even require writing any (or at least very little) new code.

All we need is better VRFY

[Animats]

All that's really needed to stop forged spam is a few modest improvements to SMTP. I'd suggest this:

• In order to send mail as "foo@bar.com" and get it delivered, there must be a mail agent for "bar.com" that knows enough about you to answer an SMTP VRFY.
• Each message sent contains some random ID or digital signature, chosen by the sender.
• Any mail agent wishing to verify the source of a message can query the senders's mail agent with SMTP and a VRFY, and obtain a reply that verifies the message, using a challenge/response or digital signature system.
• Ultimately, mail messages that cannot be verified are bounced. During a transition period, some manual authentication scheme involving replying to a message is used.

This is backwards-compatible, easy to implement, and implementable in stages. It would be implemeted primarily in ISP mail transfer agents, so deployment doesn't require end user software.

Spammers can still spam, but at least they have to have a real domain name to send from.