Is Unspammable Email Possible?

I've recently been kept up late at night thinking about ways to stop spam. And I mean STOP spam. Not just detect it and block it, but literally make it impossible to do. I'm sure others more experienced in this area have come to the same conclusion as I have but in a nutshell, I think email as we know it must be completely re-written from the ground up. The current infrastructure of SMTP and POP/IMAP for sending and retrieving message is based completely on trust. That is, your email address is an open mailbox for anyone to send you anything. In the early days of the internet, this was fine - people could be trusted and there was little to no market for spam because so few people had email addresses. Nowadays, Spam accounts for upwards of 80% of all internet traffic. That's right - not just of all emails, but of ALL INTERNET traffic! That's not good.

So, how do we fix this? Well, I had an idea. What if we scrap the old systems of using SMTP and IMAP/POP for sending / retrieving email completely. What if we used RSS to read email and secure HTTPS to send (and also read) emails? I'm temporarily calling this "SMiRQ Mail" (short for Syndicated Messaging and Relayed Queueing). So, for the moment, let's introduce a few rules...

1) Mail must be sent using a web browser connected to a secure web address hosting SMiRQ Mail via HTTPS
2) Mail must be read using RSS - any RSS aggregator will do (or a web browser)
3) Mail is not allowed to be sent to anyone whom you have not explicitly asked to trust you and who has accepted your trust.
4) Mail is not allowed to be received from anyone whom you have not explicitly identified as someone you trust.
5) When you ask someone for your trust, you're only allowed to ask up to 3 times and you're only allowed to ask up to 10 (maybe a higher number) people for your trust every 24 hours. In total, you're allowed to have 1,000 trusts. No More.
6) A cost system needs to be in place where it will cost if you ask for someone's trust and you are denied. A request for trust that is accepted costs nothing - to either party.
7) Trust can be revoked in any direction between two parties, and it must be re-earned bi-directionally between both parties.

Ok - rule #6 is still not sitting well with me but I think some form of it is necessary. Perhaps a rule like "10 trust invitations that are denied result in your account being shut down". Something like that maybe would work better than a cost based system (which I've NEVER liked).

Ok - so with this setup, what do we gain and how does this work? Here's how I'm seeing things so far...

There will be a central SMiRQ registry of all SMiRQ addresses (or boxes - terminology is still vague at this point) to ensure that addresses to and from are not faked. Each address will have a password which MUST be used for both sending and receiving messages.

Let's say John and Greg are friends and both would like to send messages to each other using smirq. John signs up, gets his smirq account and is ready to go. Greg signs up as well and gets his account. At this point, there are 2 ways for these two to exchange messages - they can exchange addresses via in-person communications or via traditional email (or even IM), or Greg can ask for John's trust between his smirq account. I'm thinking that at this point, "trust" is not reflexive. That is, if John trusts Greg, that doesn't necessarily mean that Greg trusts John. I'll explain more later.

For the sake of argument, let's say that John and Greg receive eachother's smirq addresses via IM and add eachother to their trusted accounts. They can now immediately start sending and receiving messages to/from each other. Now, the protection here is very important. Each smirq account has a list of trusts which they are only allowed to receive email from. So, John can only send Greg a message because Greg trusts John. And likewise, Greg can only send John a message because John trusts Greg.

Smirq accounts are NOT email accounts, and as such are not open to the general public to send messages to. In a sense, this is a highly controlled 'whitelist' mechanism, where everyone is considered untrusted until explicitly indicated to be otherwise. With this setup, spam, as we know it today, doesn't work. That doesn't mean that the smirq site can't be hacked, etc, but that's true of any system. I won't consider this point yet because that's a violation of the web site, not the smirq system.

Let's go back to John and Greg and assume that they never exchanged each other's addresses through IM. How can they trust eachother. Smirq allows you to ask up to 10 people per day for their trust and each person may be asked up to 3 times. If you are not allowed the trust of an account after the 3rd time, you are forbidden to communicate with that account for the rest of your account's lifetime. So, let's say Greg asks John for his trust. Greg enters John's FULL NAME into the 'ask for trust' box and then finds John's smirq address. Greg asks for John's trust and John receives a trust invitation from Greg - indicating only his FULL NAME - no 'hello message', and nothing else that Greg can enter will be sent to John other than Greg's full name. This helps prevent spamming of trust invitations. Furthermore, each new Smirq account will be scrutinized and run through a spam filter for cases where spammers try to setup accounts with a name like "Cialis" or "Buy me now".

So, once John trusts Greg, Greg is now allowd to send messages to John, and John is allowed to receive them. BUT -- the opposite is not true yet - John can't send messages to Greg and Greg is not allowed to receive messages from John. This is purposefully done. It helps to create uni-directional relationships for things like mailing lists and broadcast messages that should not expect a reply.

Ok - now that John is receiving messages from Greg, John would now be like to reply to Greg's messages and send messages back to Greg. John needs to ask for Greg's trust. This is easy to do since John has Greg's address (Greg's been sending messages to John and his return address is on them), so John asks for Greg's trust. Greg receives John's FULL NAME in a trust invitation (and nothing else) and decides to accept the invitation and to trust John. Now, both can communicate to eachother, through their smirq accounts and the smirq web site.

This is great but you don't want to be going to a web site to check your mail if you don't have to. Enter RSS! Smirq accounts - since they are secured via HTTPS and a password can be accessed via a simple RSS URL and be read by any aggregator. The caveat here is that the aggregator must be able to accept HTTPS URL's and be able to establish secure connections to a feed. I don't see this as a major stumbling block nor hard to implement. The tools are there, they just need to be hooked up.

Now, John and Greg can get new email notifications RIGHT in their RSS reader securely. But let's say someone hacks into one of their accounts and steals their password(s). This isn't such a big deal (in terms of a potential spam catastrophe) because the worst that a hacker can do is to spam all of John's friends - and that's it! Without an additional invitation to more addresses, a spammer can only spam the trusted addresses of a stolen account. Furthermore, a function will be in place to allow an address that is sending spam to be frozen and its password reset. A "real email" will be sent to the originating address of the account and a request to reset the password will be sent -- allowing the owner of the hacked account to regain control of it.

Will this scheme work? I think so. There are a million more details to explain and work out, but I'll spare those for another post after more thoughts and refinement.

I think this is convenient, as easy to use as regular email and RSS aggregators, and is infinitely more secure than email because it's NOT email. As a side thought - it's not all that hard to add more features like allowing HTTPS POST operations to send smirq messages from a "Smirq client" - i.e. a standalone program for sending / receiving smirq messages.

This can be done. Open source can do it.

Alan Snyder
[e-mail:alan8373@gmail.com]
[HYPERLINK@www.deronyan.com]

Full Story