Slashdot Mirror
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)."
Looking at other progressive moves to improve Internet technology is probably the best bet.
... sorry, not happening. Hell, we can't even push out v6, let alone start from scratch. Sure, these organic growths (i'm talking bout the internet) may seem inefficient and disorderly, but anyone in theorectical math knows that such systems have an awkard effecientcy. Similar to the buses in Mexico (they don't have a single entity controling them, like the US does), the internet grows from several competing interests, and often seems chaotic and ineffective. Yet, studies show that the buses in mexico are several fold more effecient than the regulated from the start ones here in the states. Just some food for thought.
(someday, i will make FP)
YOU SUCK BALLS!
A subjective summary of the column:
- Scrapping the Internet is a good idea because spammers have used email to annoy everyone.
- Under this new, hypothetical email system, Verisign would require everyone to buy a secure ID to ensure they are who their messages say they are.
- The columnist is willing to spend more money and lose his privacy in exchange for these conveniences, so we should be, too.
Please. The problem with spammers isn't because SMTP is so weak. The primary cause of the modern deluge of spam is unsecured email servers around the world, allowing senders to spoof their identity and auto-email anyone they happen to have an address for. And no new system, no matter how rigidly secured, will make up for admins who don't do their job; if it did, it would be prohibitively expensive or complicated and thus be impossible to implement as widely as email is now.
The writer, Larry Seltzer, complains about spammers abusing his account, and yet his online publisher sticks a link to his email address right at the bottom of everything he writes. I would suggest that if he wants to reduce the flow of junk to his inbox, he start with his own managers.
MS would buy control of the process and then pollute any standards that result. At least now there is a level playing field.
I don't want MSInternet.
BC
Who's to say that a redesign would take away? When people banned together to "redesign" the way the OS worked and was controlled, we got Linux. Now is that such a bad thing?
I can understand the author's frusteration with the current infrastructure, and it might be nice if we could chuck all of the bad at once.
BUT, this is completely impractical and would never happen. The current installed base and backwards compatibility always have and always will act as insurmountable intertia to sudden and drastic changes. The innovators will keep on innovating while the rest of user base slowly upgrades their most woefully inadequate equipment/software to the new standards.
Let's face it: once the internet moved out of the realm of hobbyists and academia and into the commercial sphere it lost the willingness to accept drastic changes. While it continually evolves (the emergence of ipv6, internet2, etc), I don't think we will be seeing a real, identifiable revolution anytime soon.
-bcollier06
Try SMTP AUTH. Any respectable MTA implements it.
This would take a centralized authority -- without one, enforcement is left to the commons, and we all know what happens then.
I'm sure we'd have no trouble finding a decent, well-respected, centralized authority to control all of the world's email. After all, no one has any cause to complain about the Internet's existing centralized authorities!
Seriously, we could talk about what if's all day long, whether about the internet, global politics, the SARS virus, or even the DH rule (I'm against it) but it won't change a damn thing.
Last time I checked, actions speak louder than words.
I'd love to see some action to seriously combat spam because, frankly, I think it's going to do some serious damage over the next few years if the current situation is allowed to continue unchecked.
When people stop checking their inboxes because finding genuine messages is like finding a needle in a haystack, and when 25 or even 50 percent of all internet traffic becomes spam, thus slowing down the entire system for everyone and (more importantly) costing infrastructure providers, ISPs and ultimately the end-user serious money, it'll be a bit late to address the problem.
Better that it's done today - I'd rather deal with the disease now rather than treat the symptoms later.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Agree. Ain't gonna happen. The major isp's do a tremendous job keeping most of the spam out of our mailbox. For the few that slip through, there are various filtering programs like SpamAssassin that can help.
e 921.zip
For those interested in higher accuracy and more speed, you can write your own filtering program that analyzes the headers and responds to your unique name and email address.
I just uploaded my version written in Borland Pascal running in DOS.
My spam program filters valid messages at up to 3,000 msg/sec, detects spam messages and decodes base64 at 200 to 300 msg/sec, and has no false positives or false negatives.
The nice thing is it is easy to update when spammers change their tactics. If you are interested in seeing how I do it, download the source file at
http://www3.sympatico.ca/add.automation/misc/spa2
Best Regards,
Mike Monett
(Who tried to re-register but cannot get SlashDot to remember my name and password:)
I'm a little confused about this article. It talks about rebuilding the net, but it focuses on a protocol that's really only a software change. You don't need a whole new internet to do that. Just create your messaging service and entice people to use it.
Frankly, I'm surprised more people haven't ditched email for Instant Messaging. Spam just doesn't work on it anymore because permission has to be granted before anybody can contact you. Etc etc.
"Derp de derp."
I've been arguing for years that the only way to fix the spam problem is with some kind of certified-user infrastructure. And I doubt that I'm the first person to see this. Filtering simply does not work, as the current volume of spam (60% of all mail traffic, I'm told) indicates. The only question is, how do you make everybody switch over?
Seltzer's idea of SMTP gateways is ridiculous. Its just another filtering solution. Nor does it make sense to wait for Internet2 to roll out -- that technology will probably exist side-by-side with the current Internet for decades.
Not that I have any better ideas. Perhaps users who go to the new protocol could bounce SMTP email with the appropriate "please change" message. Whatever.
In any case, I don't think the answer will come from the standards wonks. More likely the major ISPs will get together and invent something.
here's my list:
.com, .org, maybe even .edu and .net. use the ccTLD with other localizations below that.
1) let's clean up ftp. real security options, performance options, etc.
2) smtp. as in the article, smtp needs work, at the protocol level and implementation of mail programs and their handing of information. i really believe that a little key management at the isp level (if enough isp participated) could really make a difference.
3) dns. i would drop
4) more ip addresses. ip6 would be nice, but if i'm starting over from scratch, just increasing the ip address from 32 to 48 or to 64 would help.
5) the ability to do a number of things in a slow, throttled-back fashion to run nicely in the background.
6) better printing protocols. lpd is a mess and the other printing protocols seem to problematic.
7) snmp. this seems to be getting better via v3. the real problem seems to be the software, not the protocol.
just my $0.02
eric
The author isn't very knowledgable. Quota's for email can be implemented without breaking existng email clients. SMTP allows Authentication via certificates to be layered on top or, most email clients allow SMTP send with authentication.
asked a few people involved in solving the problems of e-mail what would be involved in fixing it. This put them in an awkward position of conflict; after all, spam-filtering vendors and other security companies make their living because these problems exist
Bollocks - the mail guru's who maintain this stuff are mostly volunteers and are not interested in making money off spam/protection. Thats an insult to them.
SPAM can only be slowed via eduacation. People must learn that SPAM is not the way to buy things.
Unfortunately, you're wrong about this. SPAM works because the vanishingly small amount of money it generates per message is still greater than the cost of the message. The people who get taken by spam are the same people that get taken by psychics that advertise on cardboard signs. These people will always exist - no matter how much effort is made to educate them.
Two quotes come to mind:
"There's a sucker born every minute" - P.T. Barnum
and
"Knowledge is realizing that the street is one-way, wisdom is looking both directions anyway" - unknown
(Score: -1, Stupid)
Right -- and guess who's going to make money off of charging 'email taxes' for everybody who wants to send a message? This is like the big kerflufle over the (false) claims that Canada was going to charge a $.05/email tax to help cover the losses to Canada Post.
So now we're going to pay more money to NSI/Verisign for an email cert when they're refusing to deny DNS to prolific spammers? We'd still need a grey-market method of keeping track of which of those certs were sold to spammers.
Before we get too deep into the idea of using PKI to 'secure' email, I'd suggest that people look at the rather interesting article pointed to by the GnuPrivacyGuard site about The Ten Risks of PKI.
A more interesting question is whether this could be done in an open-source manner, with peer-to-peer authentication servers, webs of trust etc.
The protocol wouldn't be so much a drop-in replacement for sendmail as it would be a parallel delivery mechanism. As (and if) it became proven and trusted, I expect that such a system would slowly overtake SMTP as the preferred method of accepting email (with the 'old' method being less and less trusted). Once 'enough' people started using such a system, the critical mass would result in a flip-over in emphasis by the bigger players.
OS Software is like love: The best way to make it grow is to give it away.
Nice timing. I am just retrieving the 5345th message from my ISP inbox, which contains a password recovery code. I couldn't care less for the other 5344 messages in there (one year spam collection). Yay! 20min overhead.
It does not classify as little overhead. I could get the message in 2s using IMAP, but nooooo! That'd qualify as Good Service(tm).
If at first you don't succeed, skydiving is not for you
automate purchasing domains such as ...
the same why they automate buying yahoo addresses.
Buying domains is not free. Setting up yahoo addresses is. That puts a price on SPAM, which would instantly reduce it.
the RBL's would become far LESS useful. because domains have so much value, spammers are going to do everything they can to send email through domains that are not blocked... and in doing that block everyones domain.
Domains should not relay - that's the whole point. That's what RBLs are for, and why they work.
verifying headers is damn near impossible unless you have each server log every transaction and accept challenge requests. this overhead is almost impossible.
If it were an enfored requirement that you only claim to be a domain that your IP address says you are - a requirement that is not currently enforced on most mail servers, that would be easy to implement (and turn on). This would not be expensive, and when used in conjunction with RBLs would be very effective. It's worth noting that I violate this notion myself - because my reverse IP lookup says I'm pacbell, but my sendmail does not admit to that. There are some folks I can not send email to because they DO enforce this requirement.
the protocol is correct in simply taking its output and displaying it. it isn't verified because it can't effective be done.
The protocol is routinely ignored. Actually I don't know that the reverse lookup is a requirement or just advice. In any case, it would be easy to make a requirement.
I believe it can be done. What's more, it would not be difficult.
spammers will find ways around anything you put up.
If you make spam cost money, it will MOSTLY go away.
THE ONLY WAY TO STOP SPAM: (bells and horns play)
you maintain a list of people you accept email from. you set up a method for people to request admittence to that list (through existing protocol).
wow. so easy.
I used and contributed to a-s-k.sf.net for some time. It had the unfortunate side effects of filtering out some automated non-spam email that I wanted. Now I do content base filtering using tess.sf.net, which is between 80 and 90% effective for me (and has never given me a false positive).
The author of the article suggests that companies like verisign should sell certificates to users. I think that'd be wrong and no doubt quite expensive, destroying the foundation of email itself. Also, dropping the current protocols is not necessary.
But verification is a nice idea that must not to be abandoned.
I propose that ISPs themselves do the verification (they should do this anyway to be sure their bills get paid).
Usually when you sign up with an ISP you get an email address. Now, you just get a verification signature, too.
The smtp server of your ISP would check your signature and ensure that all headers are correct.
The sender verification at the target would be a simple request to the verification server of the ISP that's hosting the sender. (These servers should have some sort of signature like SSL)
Checks could include the message id or a checksum of the headers generated and stored by the smtp server. (Thus, still keeping privacy.)
I think this approach is both logical and simple (and cheap). And it could be implemented on top of the current system.
In the beginning it won't stop spam being sent through open/exploited relays. But mail from untrusted sources could be easily filtered out. Later it could be blocked altogether if verified emailing would be widely adopted.
-- I love the smell of Blue Screens in the morning.
I agree 100%. If we tried to rebuild the internet from scratch the government would get its grubby little paws on the project. The following then would likely happen...
1) Microsoft would offer its "solutions" to the government. As a result, MS would own all of the major protocols of the new net.
2) The DOJ/Dept. of Homeland Security/Schutzstaffeln... err Secret Service/etc. will make sure all these protocols are snoop friendly.
3) The RIAA and MPAA would get in on the mess and lobby for SSSCA/CBDTPA-like crap placed into the protocols as well... and perhaps free reign on people's hard drives.
We'd probably still get spam, but we'd have zero freedoms online.
"You spoony bard!" -Tellah
I recall a feature of DNS when Iwas researching SIP (session initiation protocol). It seems DNS has a way to list the default host names for particular protocols by using SRV records. For example, I could query DNS for the "sip.tcp" SRV record for my ISP and find the host to be "sip-server.myisp.com".
So why use DHCP to do something new when DNS can already handle it? Even if itsn ot fully realized in all DNS servers, it's still closer than DHCPs are, sin't it?
Or does DHCP have this inate ability too? Still, I would think DNS is more pervasive than DHCP.
OK, we've got DNSBLs, we've got filters, we've got DCC, we've got Razor. Why don't they stop spam?
Let's take DNSBLs. They stop much spam but they don't end the spam problem. Why not?
Possible answers:
(1) Not enough mailboxes are protected by DNSBL
(2) too many spam-source IPs escape listing for too long
For (1) the answer would seem to be: get more mailboxes protected. Get enough protected so that the amount of spam that gets through is too little for the spammer to earn the cost of sending the spam.
For (2) the answer would seem to be: recognize spam faster, get IPs listed faster. Automated recognition might be ideal. Razor, perhaps, feeding back to a good DNSBL?
If it's filters then the problems include:
(1) Not enough mailboxes protected by filters
(2) Too much spam slip sthrough the filters
For DCC and Razor:
(1) Not enough mailboxes are protected.
See a pattern here? I'd say there are solutions, they just aren't used widely enough. With the recent inititive at AOL to block spam there's been a big change: that's one whale of a lot of mailboxes at least partially protected by something that works. Those AOL lawsuits may do a lot as well.
I favor relay spam honeypots and open proxy honeypots - throw them into the mix, too. To some extent these would help compensate for the "not enough mailboxes" problems - the honeypots might end up trapping spam for those unprotected mailboxes anyway (trapping spam that would be DNSBL blocked only helps in that it reduces some bandwidth costs - the spam is doomed form the start if the mailbox has good DNSBL protection.) But if we had universal (which might really mean 85 - 90%) usage of a good DNSBL then spam might die just from that. No change in protocol, just a bigger effort to use what already exists.
Same for any really effective filter - get it used widely enough and the delivered spam falls below the self-sustaining level.
Why not?
The issue with IPv6 isn't so much adoption as that the thing is still partially being specified; it's the second-system effect on a large scale, but with no time constraints, so it will take a really long time to get done, but it will never fail. IPv6 has actually gotten widely adopted at the network infrastructure level. Most of your packets today probably go over IPv4 tunnels over IPv6 routers at some point getting across the internet. User adoption takes longer, but this is also due to there being IPv6 features which aren't yet worked out, and nobody's going to switch the users to something incomplete.
Personally, I think POPn and IMAP are far more in need of replacement, and probably first; if there was a good replacement, people would actually send all of their outgoing mail through their incoming mail host, reducing the number of programs that actually had any reason to use SMTP, and making the problems that SMTP or a replacement faces much easier.
But replacing SMTP with a better alternative would go quickly; if the next sendmail, outlook, and exchange supported it and a couple of other MTAs supported it, people would pick it up with their next set of security fixes (or non-sendmail/outlook/exchange users would pick it up on its merits or for the novelty), and most other programs actually pass the info off to a local MTA or can be set to do so.
There would probably be a year to get critical mass such that you can turn off SMTP and get anyone who wants to email you to upgrade.
On the other hand, the replacement specification is a bit tricky. PKI isn't really an option, since the "trusted" authorities aren't necessarily usefully picky, even when they aren't downright fraudulent. Charging money runs into collection issues, even if there were actually a suitable micropayment infrastructure, and charging processing is hard to make effective against the sorts of budgets spammers get. I think that a mixture of DNSSEC, IPSEC, and actually getting mail only from a host that receives mail to the sender's address would be effective against spam (at least spam that tries to hide its origin), without any change to SMTP and only slight changes to server behavior.
Whatever the benefits, this would be highly disruptive.
Highly disruptive, expensive and undesired.
Having a central authority for tying identity to e-mail not only concentrates power and points of failure, but also adds unneeded hasle and real dollar cost.
What you really want is to charge hash cash. The hash cash means the reciever uses just a few cycles to generate a challange and the sender must expend many cycles to create the response. You could set this up so the first time someone sends you a message it will take about one second, or one minute, on a modern computer to actually get permission to send you a message, and then later on you put them on a whitelist that lets them send you a message without as high a cost. Devices like cell-phones couldn't send messages directly unless you wanted to spend a LONG time for it to go out, but the cell phone providers could provide a gateway that charged say a penny per message.
The best part is you can add this to SMTP through an extension. For backward compatibility you could at first accept regular e-mail. Then 6 months later implement a challenge-response to the e-mail sender, you send them a message with a GIF attachment, and a message about what to tell their sysAdmin to install. Then you ask them to resend the message with the numbers printed in the GIF attachment (you can randomly perturb the vertices so that it is difficult to OCR.) Then finally another 6 months later you cut them off, you just send a message telling them where to download Mozilla or another SMTP-new-improved e-mail client.
If I had the time I'd write the RFC myself. There's already an RFC for crypto connections between SMTP servers and clients, I expect the implementation would be simple on most if not all servers. The only thing you need to consider is how a user sets the amounts she wants her e-mailers to pay for sending her a message, there has to be some way for her to authenticate herself to the server that recieves her e-mail, there are many ways to do this... But this doesn't need to be standardised, different mechanisms might be appropriate in different situations. Once you can authenticate you could just configure the server through a specially crafted e-mail, which maybe should be standardised so your e-mail program can configure this for you. This should be a different RFC, you can set up the system with just the people setting up e-mail servers setting the thresholds.
Dealing with identity on the internet should be handled with PK-crypto automation. If your e-mail dealt with your keys like ssh does you would know that the wierdly annoying e-mail you got from that guy you've been e-mailing for the last 6 months is really from him, or at least someone who broke into his computer. Having a public key signer like Verisign doesn't mean much to me, since 90% of the people I e-mail I've never seen and only know through their e-mail. What do I care if they payed someone $399 last year to vouch that they are really John X. Smith of 14 Pentigonia Road, Yujoguha, Uganda 21AV-4GTC3? I never visited the guy, he just e-mailed me about the widget and then started sending good patches. Not that I think this is completely useless, but if I were working on the problem I'd first write the RFC and patch some common e-mailers for ssh style PK handling. Only then would I write the RFC for certificate chains, since I doubt everyone would implement this since it's harder and doesn't provide the immediate benefit to users that the first improvement does.
OK, let's talk some REAL reform... Let's take a step backwards to the days when things actually WORKED:
c .h tml
:)
Think HTML 2.0
http://www.w3.org/MarkUp/html-spec/html-spec_to
WHAT IF we incorporated a new concept into the WWW: An "Information-Focused" web that was incorported into existing HTTPD server software, that REQUIRED all pages it served to be fully HTML 2.0 compliant - (or they wouldn't be served), without any of the bandwidth-wasteing junk like Flash/Shockwave/Java/Script/Etc...
OK, now you're probably laughing. But think about it... It would be GREAT for web sites that should be information-oriented (news & tech support-type sites, as opposed to entertainment-oriented MTV.com stuff). Simple HTML code, simple formatting, simple (preferably small) images only where necessary. All in a format that not only displays perfectly on "any browser" - but also on a tiny cell phone/PDA screen.
If the IETF/W3 would just agree, this could work ALONGSIDE existing web sites. Maybe agree that all such sites on a server should be prefaced with "h2" or something quick and simple like that - as in h2.domain.com (Kind of an alternative to providing a "text-only" version of a site.) So that way, if you want the regular, bandwidth and hardware-hungry site with all the bells & whistles, just go to www.domainname.com - but if you wanted to access "Just the Facts" without all the junk, you'd go to h2.domainname.com
Yeah, I know this is more a pipe dream than anything else. But the difference is it would be totally simple to implement. All it would take is the user community's desire to do it, and a little cooperation from Apache coders...
Any cooperative Apache coders out there?
I'm the author of the column under discussion.
So how do you see the idea of a parallel system? Without even touching current email systems, someone could implement an "e-squared-mail" system with postage costs, certificates, etc. Getting too much spam in your email inbox? Simply direct your friends and family to use e2mail to contact you. No gateways or entry-points needed; if you want to contact someone without an e2mail address, you can just load your email program and use that. While you're there, take a moment to read all the unsecured email that people have sent using the old system.
If innovation should happen at the edges of the network, it makes sense that a new application would work better than trying to change legacy systems, no matter how simple that change may be. Give a few big companies their e2mail accounts, and see how they do with no spam to distract them.
On a sidenote, I think that anonymous email is probably more important now than ever, and shouldn't need to be a victim of anti-spam efforts. True anonymous email is typically a few emails per month, and there are plenty of people willing to fund the costs of it, although not in a personally-identifiable way.
The main problem as I see it is that we cannot identify the senders of most spam. Some do not hide their origin and could be identified but these are a small proportion and they are generally of a nature that is not offensive.
If we don't know who they are, we cannot chase them with legal action. If they can be found, then laws stand a chance and the threat of legal action will reduce the numbers. Those who remain can be made an example of.
You can argue that legal options are limited as spam is sent from outside of the country, and that filtering is the only real option. However, even filtering becomes more effective if you can identify where the spam is really coming from. To avoid being blacklisted the multi-million message spammer would have to keep moving domain name and that would prove expensive.
Here is my solution to "Who sent the spam?".
I originally thought that we should ditch SMTP. But now I don't think that is really the case. Besides that would be such a major change that it would probably stop the change happening. SMTP works, it gets the mail there, the only problem is you only have the sender's word for who sent it. We just need to extend the idea a little bit to check who sent the mail, and then wait until the whole world has adopted the extension.
I suggest a new header which indicates that the sender's mail server supports verification. A receiver's mail server that also supports verification then has the option of sending a checksum of the mail (or some token sent with the header) back to the sending server, to ask "did you really send this mail?". Upon no reply or a denial the user settings can elect not to have the mail delivered.
At first only some of your mail will be verified, but you will be certain who sent the verified ones. Later as most of the world begins to use the system, people will elect not to receive unverified mail.
I like this idea because it does not break the existing infrastructure, it does not demand big new central servers, nor does it demand everyone gets a new mail reader. It's just the mail servers that need extending, and they can be done one at a time (or may be not at all) without anything breaking. Also there is nothing about it that will stop people receiving the unsolicited porn spam if they want it, they only have elect to receive unverified mail.
I suggested something similar to this to some friends a while back.
:-
How hard could it be to setup a few servers (just like the current DNS Root Servers, which seem to run just fine) to handle keys/certs to validate emails.
It wouldn't be rocket science to get something like this running
- User sends email
- Client looks up keyservers, requests a new message ID, keyserver logs user key with new message id
- mail gets sent, with key and id info
And upon receiving, the client does the same in return. This is a very basic way of detailing it, but i'm sure you all know where i'm coming from. I'm suprised nothing like this already exists in the open sauce community (it probably does, i've just not checked).
Hoorah.
nb: if it's flawed, i don't care.
"Never let the truth get in the way of a good story..."
You say you disagree, but seem to be making some of the same points I was aiming for.
1) I don't view loss of anonymity on the internet/over SMTP as a "Bad Thing (tm)." If absolutely everyone that connected to the internet were uniquely, traceably identified I think people would use the internet/e-mail a lot more responsibly.
2) SPAMmers will still find ways to subvert individual's legitimate accounts. This does and will partially negate any benefits of distinctly identifying sender(s).
3) SPAM-filter *corporations* in the meantime benefit by adding more spam to the mix (themselves!) I find myself unable to trust any company that says it has an e-mail solution. I tend to theorize that they are at least subsidizing third party SPAMmers (indirectly or directly.)
4) Certificate vendors are also suspect whenever a proposal arises that implies that all individuals need certificates. The article wasn't talking about using ssh-keygen or PGP. It was suggesting a paid CA issuing individuals certificates (or did I read too much into that?)
"God is dead." - Frederik Nietzsche