Safe Signup for Email (0.1)

The Problem

Once upon a time, e-mail newsletters were a great part of the net. They still are, if you know where to look. However, the problem of spam has made finding which ones are good a lottery. Putting your name in the signup box may just be agreeing to a load of junk, rather than interesting content. Similarly, websites often have useful features available on registration. But do you trust the site?

The Current Solution

Currently, it is possible to fight off the possibility of abuse by generating unique addresses for each signup. This can be done in two ways - using catchall addresses with a personal domain name, or the + notation (e.g. bob+news@example.com, bob+list1@example.com ,etc.). This is combined with the creation of filters to control the addresses, and shut off the abused ones.

What's Wrong With This?

Not everyone has a domain name to use catchall with, and catchall risks a dictionary attack. Not every server provides support for +, but it's easier to give everyone + support rather than a domain. So, using the + notation is the preferable method. It's not easy to track which addresses have been generated, and where they are being used. Some lists require signup by sending from the address to subscribe to. Others require a reply from this address. This isn't simple - many clients would require the setting up of a new account to do this. Filtering the resulting messages is also more complex than it should be. And spammers can simply remove the +, and spam without letting on who snitched the address.

The Solution - Integrated Signup Feature

The first part is creating an account purely for signups. This will allow any messages without a + to be discarded as obvious spam. The rest is simply clever UI. When the user wishes to sign up for a site, they launch a feature which will generate a randomised address. Something like lists+JR8D6SVS@example.com. This would be pretty much impossible to guess. It would also not be a good target for dictionary attacks, because all mails would be almost certain to be one person (which isn't true for *@example.com). This would more likely fill an inbox allocation before any valid account was hit. It would also likely be covered by computer crime laws, and illegal to try.

Once the address has been generated, the user names it for easy future recognition. It is also made available as one of the selectable sending addresses when composing or replying to a message. Signup using these accounts is now made much easier. Replying to these messages should automatically use the right account.

Keeping The Bad Guys Out

A genuine mailing list will probably have one address all the messages come from. So it should be possible to set up sender limits for each account. This would help, for example, with discussion lists, where the messages come from foolist-digest@example.com, but have sender's identities revealed in the list and online archives. Although this removes the possibility of a private reply, this could be returned with a machine-unreadable second address as a signature or similar.

Messages for the various accounts should be labelled on arrival, so the compromise of any one of them is clear. A function to "Stop Messages To This Account" should be available, to automagically bin any more messages.

More benefits

Once the messages to various accounts are being tracked, it's possible to add message management features to make use of them. For example, some comic-a-day emails expire after a while, as the comic disappears into the wild blue premium archives after a month or so. So the system should offer to clean away old messages. There would need to be a way to "lock" important messages (such as the signup-related ones).