Have you tried greylisting? It is working pretty well for me because apparently speaking proper SMTP is still too expensive for most spammers. Let's see how long it stays that way.

...and I want to read and edit it locally...

And file it.

It's interesting that among the potential replacements for email that you mention, none can replace FTP for file transfer. I think I saw some file transfer options on an IM client menu, but I've never used them. More importantly for this discussion of the next generation, my thirteen-year old daughter doesn't them. While she uses IM to communicate with her friends (which I don't mind, because I've heard that traditionally teenage girls tie up the phone instead) guess what she uses for file transfer: e-mail! When finishing some homework, she e-mails it to herself so that she can get it at school and print it there. I never suggested this; I of course showed her some point-and-click FTP, which she does know how to use, but she prefers e-mail. So while email's use for communication of messages may be diminishing, it's still used, just for new purposes.

Remember when trend-watchers started noting young people who had cell phones and didn't even own a land line? When they start noting young people who don't even have an e-mail address, then you can start worrying about the death of e-mail. I wouldn't lose any sleep just yet.

I've also had the idea of using Atom, and the Atom Publishing Protocol. APP is basically a good semantic way to do message transfer over HTTP. Exactly what we would need for an email replacement. Just set up a APP endpoint that is write-only for the public, and that you can read. Make sure it requires authentication of some sort, of course :) I think there's a lot to be done to make it really feasible, but it could be the future of mail. It inverts a lot of principles of email though... it will take some good thinking and adjustment to do it well.

In the same vein I recently came across Internet Mail 2000. When you boil it down you've got Atom Publishing Protocol and some kind of trackback analogue.

There's a Google Video presentation by the guy who did pobox.com, talking about that: Turning Email Upside Down: RSS/Email and IM2000.

IM2000 (Internet Mail 2000) is a concept by D. J. Bernstein of qmail fame: "Mail storage is the sender's responsibility."

So how exactly would using a different protocol (Atom) than the established one (SMTP) solve the spam problem?

I do not see how that would solve things at all. Spam is a big problem on blogs nowadays, too, and changing the mail protocols (which technically work just fine and are well supported everywhere!) does not seem a solution at all. (I’d like to see the problem solved though :).)

In Japan, they use email for text messages on mobile phones (note: it’s extremely popular among ‘the next generation’, just like SMS is in most other countries, I wonder if the ‘wide reports’ considered that). This is all very nice, but you have to be extremely careful to avoid that your mobile mail address is picked up by spammers. Every message that you receive costs money, and although the providers offer anti-spam tools, it still sucks. And once you get on the spam-lists, there is no real way out of it except for changing your email-address.

~Grauw

p.s. on my blog I have a similar CAPTCHA system as you have (using the ‘what colour is an orange’ question that Eric Meyer suggested :)), but the nice thing is: it’s invisible to most users, because I let JavaScript fill it in (and hide it). Now this may be only a temporary solution, but I hope it’ll keep away the spammers for quite a while. Before, I didn’t get any spam at all; the spammers were probably mainly scanning for signatures of well-known systems like Wordpress, but now they seem to have become more sophisticated as they also managed to post comments on my custom-made blog system.

Is the problem about the used (used and used ;) ) Protocols? Or is it about handling *not identified* communications. The good thing with emails is that you do not need a preliminary authentication between the two parties and this is also the weakness.

In Weblogs, even based on Atom, it is the same, you can have no spam, if you accept only comments from people you know, or try to trigger CAPTCHA system like here. But if you leave a possibility for non identified commenters, you end up with SPAM.

So I'm not sure it is about the technical problem, but more about the modalities of the communication. You *can* now have a spam free email, it has a social cost on unexpected emails, people you do not know a priori.

Since APP uses HTTP, you have a direct client-server connection, but SMTP allows for mail relays. With the direct connection over HTTP, you can enforce authentication better (by knowing the originating host, using a form of HTTP Authentication, and/or other methods that may be easier to implement in HTTP given its widespread usage and the fast evolution of the web compared to SMTP). I think authentication is key to stopping spam. If you have identity and authenticity, you can apply a trust framework, such as Konfidi.

Hi Norm,

I agree with all of this. Please see http://www.oreillynet.com/xml/blog/2006/10/norm_walshlifenotemail_it_was.html for more information.

Just use blog comments..?

@Danny,

Interesting you should suggest this... Almost finished with a post to the LLUP dev list. I wonder if we're thinking along the same lines?

Have a few things ahead of it on my "must deliver first" ToDo list, but expect the post sometime later today.

Another alternative to email this time based on XMPP is thought about as well. I think XMPP as a messaging protocol may be better suited to this task of replacing email than Atom. Atom-based email solution seems to me like yet another non-nail which is poorly understood from the perspective of thinking about hammer only.

Why not both? Atom over XMPP. Or the "email" itself is atom, and you get notifications by xmpp. Or something.