The technologies outlined in this proposal are very straight forward, and may even have been suggested in the past (although I am not personally aware of any such precedence). My intention is not to dictate what must be done, or even what should be done. The purpose of this proposal is to present an idea, to elicit feedback, and to perhaps contribute towards a real solution either directly or indirectly.

However, the level of abuse, whether it be unsolicited email (a.k.a spam) or its usage as a massive transmission vehicle for worms and viruses, threaten its validity and feasibility as a critical communication medium. Predictions have shown that the amount of spam may exceed the number of legitimate email in the near future, which places unnecessary burden on our infrastructure, not to mention increased maintenance costs due to increase in network and system resource usage.

Email has been proven to be both extensible and malleable over the last two decades. It is therefore not unreasonable to expect it to yet again evolve to face and curtail such crippling abuse.

This level of openness is also what permits spammers today to send email using fake or even "borrowed" identities to fool recipients. In addition to fooling recipients, falsified sender identities make it difficult, if not outright impossible, to identify the original sender. The freedom to arbitrarily set the sender address also makes it easier for rogue SMTP servers (e.g. a worm running on a vulnerable PC) to send messages, and conversely difficult for recipients to effectively filter out such messages.

Specifically, given an account allice@someisp.tld:

• There's nothing stopping a spammer from sending messages as allice@someisp.tld
• There's no sure way for the recipient (human or computer) to know whether or not the message really comes from Allice's account.
• There's no way for SomeISP (or Allice, for that matter) to stop the spammer from further abusing that address.
• Clients must send through account provider's SMTP server using authenticated SMTP (RFC2554)

The key difference between existing message signing schemes and VSMTP is that VSMTP integrates message signing and verification at the SMTP level[2]. It does not depend on client capabilities (apart from support for authenticated SMTP, which is fairly common anyway), and does not require any additional technical knowledge on the part of users. From the user's perspective, email will continue working as it always has, except hopefully with less spam, and improved security.

Requirements:

1. Every email account must have an unique private key and public key (a.k.a "key pair") associated with it
2. Keys are stored by an email service provider in a central key server.
3. The key server must have a public interface, which when given a valid email address, returns the associated public key for the account[3]. The public key server must run on the incoming mail server[4].
4. The key server also must have a secured interface to the SMTP server. The internal interface is used to supply the private key.

When sending:

1. Email client sends message through authenticated SMTP (SMTP server must be provided by account's issuing service provider)
2. SMTP server sends authentication credentials to key server (through secured private interface) to retrieve user's private key.
3. SMTP server calculates[5] message signature using the private key, and inserts it in message header.
4. Message is sent to destination.

When receiving:

1. SMTP server retrieves email address from Sender or From fields
2. SMTP server contacts sender's key server. Key server is found by performing an MX lookup on the host. (if no key server, ERROR)
3. SMTP server retrieves sender's public key (if no pub key, ERROR)
4. SMTP server verifies signature using retrieved public key (if invalid sig, ERROR)
5. If error encountered at any of above steps, perform appropriate action (e.g. bounce, delete or flag message). Otherwise continue delivery.

1. What if a spammer sets up his/her own email server, complete with key server and signing?
   The important point is that spammers still won't be able to send signed messages using others' email addresses. For example, if a spammer were to send a message posing as a Hotmail user, he would not be able to validly sign the message unless he knows the private key (a possibility discussed below). If he were to sign using a bogus private key, the message would bounce on the receiving end when the recipient server attempts to verify the signature using a public key retrieved directly from HotMail.
   
   In other words, the only alternatives left to them are to somehow obtain private keys, or send using their own hosts. If they use their own hosts, it will be possible to directly or indirectly track them down, which may prove to be enough of a deterrent. Also, recall that email service providers have to setup public key servers, and a query to the key server is made for every email sent. So if a spammer sends out 2 million messages, his/her key server would need to be able to handle 2 million requests, which may prove to be expensive enough to make spamming less cost-effective.
   
   
2. What if a virus takes over a vulnerable email client?
   An exploited and commandeered email client may be able to send signed messages. However, in this case, since messages are actually being sent through that account, the email service provider can suspend or block that account, possibly notify the user, and assign a new key-pair. Assigning a new key-pair would make previously sent (yet undelivered) messages bounce (since the signatures would be signed using the old key, which would not decrypt with the new public key).
   
   
3. What if a key server is compromised?
   Since all key-pairs are stored in a central key-server, the key-server also poses a single point of failure. Fortunately, even the worst case scenario of a compromised key server would not be crippling, as long as the compromise is discovered early enough and remedied rapidly. Again, simply re-assigning new key-pairs would be enough to invalidate old key-pairs. Since, as in the last case, spam sent using such stolen key-pairs would point directly and reliably back to the email service provider, they can be notified (at which point they would hopefully become aware of the compromise if they hadn't already).
   
   
4. What if there are so many compromised and unpatched email servers that spammers still manage to send from one account or another?
   Then this solution may not work effectively. This solution relies on the assumption that email service providers can, at the very least, quickly update their systems when their key-servers are compromised.
   
   To say the least, however, even if compromised and unpatched servers give spammers enough addresses to send from, it would make untraceable spamming much more difficult than it is now. Since spammers operate for profit and not for altruistic or idealistic reasons, the ultimate goal isn't to make spamming technically impossible, but merely difficult enough for it to be cost prohibitive.
   
   
5. What if some service providers adopt this scheme but others don't?
   Again, this solution won't work nearly as reliably. For this solution to work, it must become as widely accepted as email itself. Ideally, once adoption levels reach a certain level, incoming mail servers should simply bounce unsigned messages, partially to prompt remaining service providers to upgrade.
   
   
6. What if spammers just use free email services to send spam (as many do now)?
   This is an entirely separate issue that the various email services are tackling. One approach is to make it difficult for spammers to sign up for accounts using automated scripts, another (perhaps more effective) approach is to limit the number of recipients users can send to in a given time frame to reasonable limits (a capability IlohaMail has had for over a year now).
   
   
7. Wouldn't it be possible to stage a DDoS attack on a key server simply by sending falsely signed messages?
   Probably. For every recipient that receives a message from an address, a key query would have to be made. So send 2 million messages with xyz@someisp.tld in the from header, and someisp.tld will potentially receive 2 million key requests. But why bother if the messages are going to bounce anyway? Script kiddies might try it, but spammers probably won't (after all, they're in it for the money, so they probably won't bother doing anything that doesn't generate revenue).

Privacy
Some people may see this scheme as an invasion of privacy. That is not so. Every account is linked to a key-pair, but not necessarily to the sender's real-world identity. Granted, this scheme does make it more difficult to send email anonymously, but all that's required is a service that provides signed email accounts without requiring personal information. On the other hand, this scheme would better protect email users against identity theft. Furthermore, it may simply remove the false sense of anonymity that is common among less-knowledgeable Internet users.

Backward Compatibility
Ideally, for VSMTP to become fully effective, it needs to be adopted widely. In fact, SMTP needs to go away for VSMTP to actually work. But even if VSMTP were adopted, it would take months or years for SMTP to be purged, and during the transition period, VSMTP and SMTP would need to interoperate.

The bottom line is: they're fully compatible. A message sent from a VSMTP gateway would pass through SMTP without any problems. VSMTP gateways can also be configured to allow unsigned messages through (at least for a while), allowing messages sent through SMTP to be delivered normally.