HowToSaveEmail

ThoughtStorms Wiki

Context : EMail

OK, so there's talk of email being so overwhelmed by spam that we should all move to a Micorsoft standard where everyone pays a small amount for every email .. therefore it'll be too expensive to spam the world (well, that's one exaggerated strawman version of the 'talk' on the email problem).

There's also talk of the TheEndOfOpen. I think email is a long way from being a dead protocol and the discussion should be moved from 'is email dead' to 'how can we improve the email protocol'.

Indeed, I don't mind having spam sent to my email address. I mind that it gets into the inbox that I check on a regular basis. I mind that it takes up my time. The 'problem' is with the email clients not the underlying email protocol.

Also, I wouldn't be any more interested in 'advertising email' sent to me only by the biggest corporations that could afford to pay for each email sent to a 'target' list. So, in terms of my inbox, I don't care that sending spam is free.

Furthermore, I believe that it ought to be possible to track down and then close down major spam generators. So, I'm not really concerned about the bandwidth of the internet being consumed by spam. Text emails should not be a major burden if the broadband enthusiasts are serious about things like 'video on demand'.

So, the real issue is how to ensure that our inboxes remain as clean and tidy as possible. We want an inbox where all email that arrives there deserves our attention.

One way of looking at the problem is that we all want an 'open' address that anyone in the world can contact us with, but we also want a 'closed' address for our network of contacts. Ideally these addresses are the same, but we have a filtering system that ensures that we don't get our attention hyjacked by anyone who happens to know our address.

So we need email clients that manage multiple inboxes. Indeed, ideally we would like to know not just who is contacting us, but also the context of their message (e.g you may get work related or personal email from the same person .. and wish to read them at different times).

To make this an open standard, all this could probably be solved by simply adding extra standard headers onto the emails being sent. (Clients without the ability to interpret these headers would simply ignore them).

Then the client programs can sheild us from all the spam for most of the time. Occasionally you'd have to sift through the junk to see if some of it is genuine. So, this extra 'context' heading (plus local lists of contacts' email addresses) would enable you to automatically have a series of inboxes for different contexts. I can only imagine email clients already do this kind of thing (probably even MS Outlook).

The header that I'd most like to add would be an 'introduction' token. This would be a token that you would pass to all contacts which they in turn could pass onto people they know want to get in touch with you. Any email containing this token in the appropriate header would be routed to the 'inner' most inbox.

The crucial detail for this token would be the ability to update it via a p2p update mechanism. If the token gets compromised it could be used by spammers to get straight through to the most sacred inbox. So, immediately that this happens you would have to issue a new token to your contacts.

Finally, rather than only trusting the router to sift out the spam, why not download the latest 'this domain sends spam' lists directly onto your client. Indeed, I can imagine that all of the anti-virus people probably do this already.

In fact, the more I type the more I have a sense of 'this would be so easy to do' that it must already be done or be underway somewhere. It also suggests to me that email will be OK, it's just going through a rough patch.

– OliSharpe

I love this idea! (But I haven't thought it all the way through yet ;) Distributed sender-set filter tokens that could even be made available as, say, FOAF information or something, almost like a whitelist password but that can act as a category too.

I already have something a bit like this - by having everything @ my domain name passed through to main box, I can filter out anything sent to my "main" name@address, and give out alternate_name@address to anybody else, without worrying that they'll get killfiled by accident. There are a few exceptions, like webmaster@ and info@, which seem to get hit by spammers as a blanket thing, so I just don't give them out to people.

So extra headers would be an extension of this that allows you to keep to just one e-mail address, I guess. One could probably knock together an XUL component to give you a drop-down selector when you're composing a mail in Mozilla, and which could also automatically publish/receive the possible/required values to/from/somewhere. You could also change business cards to point to include a "personal contact" webpage, rather than an e-mail, which would disclose the necessary information.

First-glance problem which may be easy to overcome:

Doesn't work when scaled up, assuming that each person's token value is different. For instance, if I wanted to mail 10 people, I'd have to choose the value for each of them - but then again, the client could do this automatically for me, assuming I'd given it the location to find the value (and that it's available).

Will think about it some more...

– GrahamLally

Oli,

Related stuff :

ZbigniewLukasiak is thinking a lot about SocialRouting of messages. He might have some comments on your token suggestion. More on his wiki. I think he's also in contact with the Matador people who are building a P2P system which also routes messages.

BillSeitz is one of many people looking for BillSeitz:UniversalInbox. He's watching Chandler, which I know nothing about but could be the big open-source projet going in this direction. (MicrocontentClients is probably the closest other page here)

I haven't read any of it, but PaulGraham (who's interesting on other topics) writes a lot about spam. and http://www.paulgraham.com/spam.html and thinks BaysianFilters are working : http://www.paulgraham.com/sofar.html

A couple of thoughts which may be wrong because I'm completely ignorant here ...

isn't the problem with extra-headers, that there's a legacy infrastructure of routers which don't understand them? Possibly there's a chicken-and-egg / lock-in problem. We can't adopt a new header convention until the routers are upgraded, and no-one will upgrade the routers if there isn't a 100% certain, new standard. (And maybe not even then.) So this extra information needs to be squeezed into existing header fields. And after that you still need to get the major players (ie. MicroSoft) to adopt it.

" So, immediately that this happens you would have to issue a new token to your contacts. "

: If this is automatic I guess spammers will try to get onto your "update" subscription list. How do you tell the difference between someone who got your "introduction" token legitimately as a friend-of-a-friend, and someone who got the introduction token illegitimately? If you have to manually keep a list of people eligible for the update yourself, you might as well go the whole way and maintain a white-list of people who can mail you at all. (Or various circles of priority.) OTOH, if you allow people who possess the token to automatically register for the update list, then spammers will do so. (Although I guess you could have a manual review of this list, and weeding out spammers weekly might be better than weeding out spam daily.)

I guess as we're talking of solutions that can be implemented in the client, I suppose we can combine the email client with a secondary mode of communication (some kind of SocialNetworkingSoftware, either centralized or using FOAF) or publishing some kind of regularly updated policy, public key, etc. as an XML-file.

But, in a sense, however fancily wrapped, it seems all these are variants on a white-list ie. the idea that you specify who is allowed to send you mail. And I think that's the real point of Shirky's TheEndOfOpen : that systems which are inherantly open for anyone will get exploited, and we must move towards controlled, gated communities for our own protection.

I'm trying to think of something that isn't basically a whitelist. Wild speculation moved to EmailImmuneSystem.

– PhilJones

I think the 'inner' inbox should definitely be protected by a manually managed 'whitelist' of people (or administered groups of people) who you have decided to accept into your 'inner' inbox. However, I think it would still be useful to have a totally open 'outer' inbox that you occasionally read through to look for any interesting emails. Then, the token would be like a electronic business card that a friend of yours can pass onto someone who they think you'd be interested to hear from (or who may need to get through to you quickly). This token allows people NOT on your whitelist to still get into your 'inner' inbox.

Then, when updating a compromised token you'd only send the new token back out to the people directly on your whitelist.

– OliSharpe

Recent proposals :

http://www.infoworld.com/infoworld/article/04/04/16/16FEfuturemail_1.html

Part 5 shows how lame thinker Dave Winer is. Use RSS for email and spam is gone. How great, you get only messages from sources that you subscribed, but how would it be different from white lists? (META Will I have to swallow my words like in the case of Clay?) – ZbigniewLukasiak

By the way at the end of [UseTheWholeSpectrum http://zby.aster.net.pl/kwiki/index.cgi?UseTheWholeSpectrum UseTheWholeSpectrum]] I started collect different 'roles/dimensions' of communication tools and I believe what we really need are tools that would unify as many as possible from those 'roles'.

Zbigniew,

just don't start dissing Kibo here, that's all :-) (META : Does this joke reveal how old-skool I am?)

I think basically several people in that article have an "email is broken, the answer is to use something else" attitude, which is OK if you only want those things that your other tool provides.

Seems to me that your "whole spectrum" thing is basically asking for the universal client to the communication network, to be able to shift easily between different modes / roles / dimensions. I suppose users of this system shouldn't care very much what the underlying protocol is, whether it's email / REST over http / SOAP / Jabber etc.

Maybe the client could even dynamically switch protocols, ping the proposed recipient's client, find out how many unread messages are building up in the inbox, assume that "a lot" signifies that the recipient is spammed-out, and reconfigures to post the message on a blog-like site, and then uses TrackBack to alert the itended reader. ... Actually no, I'm being stupid, because if the protocol is made transparent, but email is one protocol supported, then spam will show up in every modality.

– PhilJones

What I observe here is that Email is too burdened with legacy to change while the other technologies are very dynamicly changing, and particulary Instant Messaging is really extending past the traditional ways of IM (let's take Groove, mentioned in the article, - it's unifying the traditional IM communication with something more DocumentBased). So in the long run I would expect that eventually the unified communicator will evolve from todays IM.

Talking about my page - I see it's value in listing what the 'universal' client should be able to do. – ZbigniewLukasiak

I can't help but think that the "ultimately generic" network is one that just assumes that all data is a). distributed and b). encrypted, but I may be showing my sci-fi/cypherpunk inclinations here. Ignoring any technical limitations currently , imagine that all data exists within a distributed "sea", which has no real, set server source (I'm thinking along the lines of BitTorrent, MojoNation here, but less visible to the user). Any "chunk" of data gets assigned some combination of access rights, using PKI - allowing data to be made public (to be read via the sender's public key), or private (to be read by the intended recipient(s)'s private key). Anything for a group would need either "shared secret keys" (hmmm) or to be encrypted for each person who wants to receive it (but for /some/ instances, this could be handled easier by making a document public, and then letting anyone who wants to read it (aka "subscribes to it") fetch it for themselves).

Propagation/notice of "publishing" could be handled somehow, too, but instant notification (a la e-mail) vs a "pull" approach (such as checking a blog, et al) is just down to the client interface then - a source for publishing a public blog is conceptually the same as a source that "publishes" an e-mail just to you.

Mmm, |dreams... Anyway, feel free to shoot as many holes as there are through the idea :) But the key thing is that all the data is thought of as generic, and is only differentiated by who can access it. Technically speaking, it works best for purely textual data (nice and simplistic from an application-handling point of view), but I guess that keeps it (a little) on topic :) Then there is no "protocol switching", and all of the functionality is where it should be - in the client, rather than the protocol. Let the client and/or user choose what they want to see.

Meanwhile, spam becomes effectively a "public good", so those that do want to read it, can. Theoretically. Spammers might just up their activity to stealing as many public keys as possible somehow, but the spam would have to be encrypted for each person, which could act as a cost hit (look-up + encryption), in terms of CPU power. It's also easier to switch your key-pair than your contact point, so regular key revoking would keep spammers on their toes...

OK, ok, I'll stop wibbling now. Normal discussion will resume shortly.

–GrahamLally