sender identification rollout

The major email service providers have been working on "sender identification" systems to stop spammers from hiding behind other email addresses. This document attempts to outline how these sender identification systems should be rolled out so they can be effectively used by non-technical consumers and small email service providers.

1. The Problem of Email Identity Theft

Spammers do not send email "From" their actual email addresses, since they would then be mail-bombed by angry recipients. Spammers instead send junk email "from" other email addresses, often the email address of some poor victim whose email identity is thus "stolen".

Because there is no reliable way to identify the sender is who they claim in their "From" address, email filters are unable to accurately delete all such falsely identified messages. Prosecution of spammers is a useless "whack-a-mole" approach, given that anyone can cheaply purchases lists of millions of email addresses, then sending their spam "From" any address they choose.

The keys to ending spam are (1) to eliminate the ability for spammers to falsely identify themselves and (2) to then determine which Email Service Providers (ESPs) actually prevent their correctly identified users from sending spam.

2. Some Good News: The Emergence of SIPs

There are several email "sender identification protocols" (SIPs) in various stages of development and deployment. These systems hold the promise to end incorrect "From" addresses. The most popular SIPs are Sender Policy Framework, Domain Keys DKIM, and Sender ID. However, to date the largest ESPs have only developed proprietary SIPs which are protected by patents and/or marketing goals, and not adopted by the other major ESPs. (I'm not going to discuss the pros and cons of each SIP system here, as that is not the primary issue.)

We need a few of the largest ESPs to agree on one SIP system. Let's define a couple new terms:

• Primary SIP. This is the open email sender identification protocol that first becomes deployed by a few of the largest ESPs.
• Trusted ESP. This is any email service provider (large or small) who deploys the Primary SIP and prevents their users from sending spam.

The Primary SIP deployment will allow junk email claiming to be from any Trusted ESP to be immediately deleted. For example, if you know that AOL.com were to use the Primary SIP, you could easily delete any email claming to be from AOL.com which is not actually from AOL.com.

3. An Open Standard SIP

It is important that the "Primary SIP" be an open standard, with no licensing required. Once the initial few major ESPs deploy the Primary SIP, this will motivate and enable all other ESPs (small internet service providers, companies, non-profits, schools, etc) to also deploy the same Primary SIP. For example, once I configure my small "f7.net" server to use the Primary SIP, email clients could easily delete any email claiming to be "From" f7.net which is not actually from my server.

The fact that the Primary SIP is open means that even small ESPs can have email originating from its server to be shown as validated by the most popular ESPs and email clients. (Of course it is not enough to validate that email claiming to be from user@example.com is really from that user, as we also need to then prevent that user from sending spam. See Throttle Controls below.)

4. Open Trust Lists

It will be important for the initial Trusted ESPs to allow each user (or organization) to specify her list of Trusted ESPs vs. instead having one centrally controlled list. Users will then be able to progressively add ESPs or (more commonly) specify which other lists of ESPs they trust (see below). As the lists of Trusted ESPs grows, spammers will have fewer and fewer domain names left that they can use as their "From" addresses.

Eventually (perhaps one year after initial rollout), users would be able to configure their email client to only allow email from their Trusted ESPs, with email from all other domains being filtered into an "unauthenticated sender" folder.

If a given ESP does not deploy the Primary SIP, their users will eventually flock to a Trusted ESP, so their emails can be delivered to their friends and colleagues.

A Trusted ESP list might look like this (note that email clients will provide a user interface for editing this list):

# A public list of Trusted ESPs: http://mail.my-big-esp.com/trusted-esps.xml # Another list of Trusted ESPs from my friends: http://lists.some-small-server.org/our-trusted-esps.xml # Now add some individual ESPs and relays that I trust: some-small-esp-i-trust.com relay.another-esp.com my-little-company.com my-friends-little-company.com

6. SIP Rollout

The creation of the Primary SIP and Trusted ESPs would evolve through three phases:

1. The Primary SIP is created and deployed by three major ESPs who become the initial Trusted ESPs.
   • Any email which inaccurately claims to be "From" these Trusted ESPs can be deleted immediately by any ESP.
2. Smaller ESPs (companies, schools, non-profits, etc) will start to deploy the Primary SIP, then having their domain names added to one or more Trusted ESP lists.
   • Any email which inaccurately claims to be "From" this growing list of Trusted ESPs can be deleted immediately by any ESP.
3. Eventually, as most ESPs become Trusted ESPs, all email will be processed as follows:
   • Any email incorrectly marked "From" any Trusted ESP will be immediately deleted.
   • Any email from an "Untrusted ESP" will be moved to an "Untrusted Sender" folder, for the receiving user to peruse (or not) at their leisure.

7. Throttle Controls

Once we have a Primary SIP with Trusted ESPs, there will no longer by any email which claims to be "From" someone who is other than the actual email sender.

ESPs will then need to add "throttle controls" to make sure their users do not send spam. As a new user, you would be allowed to queue as many outbound messages as you want, but perhaps only up to ten messages will be sent in the first hour. Over time as the user develops a stronger history of not sending spam, she will be allowed to send more and more emails.

8. How You Can Help

Please send email to with comments on this document.

Thanks to feedback from jm, mark, david, keith (including the hilarious link to this) and greg.

Back to Paul's spam page.