To read all comments associated with this story, please click here.
Internet mail 2000:
http://en.wikipedia.org/wiki/Internet_Mail_2000
Good link, but it kind of makes me think this architecture will never get adopted. Nine years after it's namesake and I sure as heck never heard of it (although it does exactly what I was looking for). But there lies the problem, how do you enable it's adoption on a widespread basis, without breaking compatibility, and without locking into a vendor's service? Google Wave, innocent as it is - it's still a provided service delivered by a company. I'm looking for an architectural change (like I.M.2000) that could be adopted transparently, perhaps we'll have to wait till email's completely unusable for it to really change...?
1) confirmation of delivery
--- you know if it was accessed and when - The occasional 'send message receipt' confirmation some current email clients provide you with is flaky and can easily be circumvented - this could not be.
And that's a wanted feature?
You must be one of those marketing guys!




Member since:
2006-03-17
I think Email as it exists also carries some painful legacy decisions - although I don't know which is harder to ditch: http or smtp?
HTTP: it would be nice to have a new protocol like SPDY, but stop and think about how many services and applications were designed with only HTTP in mind.. it hurts. Browsers change every few months, not enterprise-level applications. If anything, SPDY could be at least be used as an auxiliary or complementary browser data pipeline. But calls to replace HTTP mostly come from performance issues, not catastrophic design flaws (enter SMTP)..
SMTP: the fact that you're expected to have an inbox of gargantuan capacity so every idiot in the world can send you pill offers to make your d!@k bigger is as stupid as taking pills to make your d!@k bigger. As it exists today, any trained beagle can spam millions of people and disappear with no recourse. Terabytes of "Viva Viagra!" is due to the simple fact that the sender is not liable for the storage of the message - you are, you sucker. If the message is of any actual importance, the sending server should be available for the recipient to retrieve when they decide to. This provides many improvements over SMTP such as:
1) confirmation of delivery
--- you know if it was accessed and when - The occasional 'send message receipt' confirmation some current email clients provide you with is flaky and can easily be circumvented - this could not be.
2) authenticity
--- you have to be able to find them to get the message, they can't just disappear. geographic info could also be used to identify real people (do you personally know anyone in Nigeria? probably not...)
3) actual security
--- you send them a key, they retrieve and decode the message from your server.
4) no attachment limits
--- meaning, no more maximum attachment size because you're retrieving the files directly from the sender's 'outbox'. "please email me that 2.2GB file" OK! now you can! Once they've retrieved it, the sender can clear it from their outbox - OR, send many people the same file from ONE copy instead of creating a duplicate for each recipient. This saves time, resources, and energy (aka $$$)!
5) the protocols and standards already exist
--- sftp and pgp would be just fine, a simple notification protocol (perhaps SMTP itself) would send you a validated header (sender, recipient, key, download location, etc) which you could choose to view or not.
You'll still get emails, but spammers will be easily identified because their location (and perhaps an authenticity stamp) will point to the server - if not, you can't get the message even if you wanted to. And again - if it's so damned important I know senders will be happy to hold the message till recipients pick it up...? right?
But we're talking about HTTP here, which I can say isn't quite as broken. Although they should keep working on SPDY, because give it a few years and the world will find a way to break it...
Edited 2009-11-12 22:21 UTC