[Asrg] 6.I Spam elimination by mailbox lock and key

This is a proposal to enhance email with the objective of eliminating 
spam. I was unaware of the ASRG until 6/11/03. I have tried to educate 
myself as to what has been presented so far in this discussion group, 
but there is so much and I can only read so fast. So with my apologies 
if these ideas have already been presented, I will simply post them and 
let things fall where they will.

I am fed up with spam and I spent some time thinking of a solution. On 
May 23, 2003, I began to organized these ideas and write them up. I know 
there are many others also trying to solve this wretched issue and I am 
not so presumptuous as to assume that this is the only solution or the 
best solution, just a solution. If there are any good ideas contained 
herein, please make use of them.

This was to be a proposal to eliminate spam in 6 months or less. Perhaps 
6 months is too ambitious. I thought that it was possible until I 
started reading the postings at the ASRG yesterday. I was naive.

This is a general description of how the email extensions would be used 
from a users perspective. These extensions would be relatively straight 
forward to implement and could be used across all platforms and by all 
ISPs. A non-proprietary solution is important for competition.

This solution requires no legislation or government intervention. 
Existing anti-spam legislation could become irrelevant except where it 
deals with fraud.

This solution does not address or care what spam is. It is up to the 
individual email recipient to decide what is and isn't spam. One man's 
drug is another man's poison. The incoming email server is only an agent 
of the recipient. No group or individual is censoring or filtering spam 
for another.

These email extensions create an email system that is totally opt-in. 
When this solution is implemented, people can close and lock their 
mailboxes to email from everyone except those from whom they want to 
receive email. It will be like the lock on your front door. It will be 
like call blocking on your telephone. No more solicitors. Email can 
continue to be sent and received without using the proposed email 
extensions. If one wishes, they may continue to use email as they do 
now. But if they do so, they will not eliminate spam. It is my belief 
that people want spam free mailboxes and that they will use the extensions.

CHANGES   General Description:

The email client extensions will work like this:
1. You can lock your mailbox with your email client.
2. Only senders that have a key to your mailbox can send an email into 
your mailbox.
3. You will create one or more keys for your mailbox and enter them into 
the email address book entries for the persons you are giving the keys 
to. A key can be any word, phrase or set of characters that you choose. 
You only have to create keys one time. You can change them any time you 
like.
4. You will give (send) the keys to those people, who you want to send 
email to you. You may give some people the same key and give others 
different keys. Senders are not only people, but lists and other entities.
5. You will be given (receive) keys from those people, who want to 
receive email from you. When you receive these keys, you will enter them 
into the email address book entries for the persons who are giving you 
the keys.
6. To send email to someone who has given (sent) you a key to their 
mailbox, you will include that key along with their email address in the 
composition dialog when you send the email. This key should be in your 
address book so that it can automatically be supplied by the email 
client when you enter the email address of the recipient either by 
typing it or by retrieving it from your address book.
7. When an email addressed to you is received by your email server, the 
server will compare the key that was sent in the message, with the 
key(s) for your mailbox. If there is a match, the email is placed into 
your mailbox. If not, the email will be bounced back to the sender.
8. If a key becomes exposed and compromised, you can change the key. The 
email client will send the new key to everyone who you specify or who 
was using the compromised key. If someone is giving out your key, you 
can find out who that is by giving everyone a different key.
9. If you don't want to receive any more email from a sender, delete the 
key that they are using. If it is shared by other senders, give them a 
new key.
10. If you want to send email to someone and you don't have a key for 
their mailbox, you can request a key.

Selby Hatch
selby_hatch@azza.com

Fingerprint
BD0A 9B79 1661 03DF D035  4578 07FF E619 E4C7 A610

Detailed information:

The following describes what is required to extend the email system and 
what is required to send and receive email with the proposed changes.

1. The IETF will create a standard that everyone can, and must adhere to 
so that all email servers and clients can communicate with each other 
regardless of who the supplier is.

2. Suppliers of email clients will have to extend their email clients. 
This could take 2 weeks to two months depending on how well their 
software is constructed and how good their programmers are. Open source 
suppliers can probably do it in a month. Other suppliers will take longer.

3. Suppliers of email servers will have to extend their email servers. 
This could also take 2 weeks to two months depending on . . .. Open 
source suppliers can probably do it in a month. Others will suppliers 
will take longer. Server changes can coincide with client changes.

4. When the new extended email client is made available, you will 
download it and install it on your PC.

5. You will create 1 or more keys to your mail box. They can be a word 
or a phrase such as "sunset", "Wall Street", "pickles and quilts 
forever", "03/15/-0044", "Zzyzx", or "I love you". The keys don't have 
to be particularly secret, only secure enough to make it difficult for 
spammers to guess or get them. There will be no defaults supplied by the 
email client. These keys will be entered into the address book of your 
email client for the persons you have given them to. This is so that the 
email client can send the keys to your email server and so that you will 
know who has which keys in case  you need to replace a key. Every 
address book entry can have two keys: (1) the key to your mailbox that 
you have sent to the addressee, and (2) the key to the mailbox of the 
addressee that they have sent to you.

6. Send a key to someone you want to receive email from. When you send a 
key, enter it into your email address book for the person you are 
sending it to. You will receive keys from those who want to receive 
email from you. When you receive a key, enter it into your email address 
book for the person who sent it to you. If your email client is user 
friendly, it will enter the key into your address book for you after 
asking for and receiving your permission. The email client may do this 
without permission if you have set that option. Each key is associated 
with an address book entry so that if you decide to change a key for 
that sender, your email client can send the new key to that person.

7. When your keys have been sent and your ISP notifies you that they 
have implemented the server changes that support locking your mailbox, 
you can have your email client lock your mailbox . . . . no more spam. 
Your email client will be able to query the server for a list of current 
keys. Your email client will be able to instruct the server to 
re-synchronize it's key list with the key list in your email client.

8. To send an email, you will do as you do now. If you have the 
recipient's mailbox key entered into your address book, your email 
client will supply the key when you enter the address. Your email client 
will embed the key in a message header when the message is sent. If not, 
you will enter the key into a field following the email address when you 
compose a message.

9. To receive email, you will make sure that those who send you email 
have a key to your mailbox. This includes bulk emailers like eBay, 
Yahoo, or Fox News as well as list servers, discussion groups, news 
groups, and message boards. You may want to use different keys for these 
types of senders. Keys to mailboxes are only one way. Senders who have a 
key can put mail in, but only you can read it or take it out.

10. If you want to send an email to someone for whose mail box you don't 
have a key, you will request a key by clicking on the "request key" 
entry on a drop down list in your email client. You will enter the email 
address and your email client will send a key request type of email to 
the email address you provided. You will also send a key to your 
mailbox. If one wants someone else's key, they must be willing to give 
one of their own keys. When the request is received, the recipient may 
send you a key. They may also reject your request or ignore it. If they 
do send a key, they can enter your email address and key into their 
address book, so that a new key can automatically be sent to you if they 
ever change the key. Any request for a key that has a subject, a message 
body, or other unnecessary header that could contain a solicitation, 
will be bounced by the receiving email server and will not placed into 
the mailbox.

11. It would be nice to allow the subject header in a request key email 
to be used for identification. But if this is allowed, it will be abused 
by spammers. It could contain a solicitation message or a web address, a 
phone number or some other such lure. The only information that will be 
available in a request key email is the requestor's email address and 
mailbox key. The recipient's mailbox key will only be sent to the 
requestor's email address. The only way to receive a mailbox key is for 
the requestor to provide a valid email address and mailbox key. Even the 
name portion of the sender's email address could prove to be a problem. 
It doesn't have to be a valid name and it could contain a lure or a 
solicitation message. Since it is not necessary for message 
transmission, perhaps it should be stripped off in the request for key 
process. The complete email address including the name could be obtained 
after the initial negotiation.

12. If you send an email to someone and you want a reply, you can 
include a key to your mailbox. When the recipient replies to your email, 
their email client will use the key that you sent, to reply to your message.

13. If a sender includes a key to their mailbox, your email client will 
insert the key into an address book entry if you direct it to.

14. Some sites require you to provide an email address if you register. 
If you do not want further correspondence beyond 1 day or 1 week, you 
can create a unique short lived key just for this purpose and use it in 
the registration. When you no longer wish any correspondence from this 
site, delete this mailbox key. The email client can make this easy to 
do. You may create an expiring key and specify how long to keep the key. 
When the expiration interval or expiration date is reached, the email 
client and the incoming email server will delete the key at the server.

15. If a sender requests a key to your mailbox and you can't identify 
the sender, you may want to create a short lived or expiring key. You 
can then send the key to the requestor and open a dialog. If you want to 
continue correspondence after the initial negotiation, then retain the 
key. Otherwise, delete it or let it expire.

16. Spam is dead. In the final analysis, if a sender has a key to your 
mailbox, they can send you an email. If they don't, the most they can do 
is request a key. You choose whether or not to give them a key and you 
choose to delete it if, and when, you want to end a correspondence.

Technical Description

Email Extensions for client and servers

The email extensions for "received message control" are implemented 
using 4 new headers. The new headers are only effective if the email 
server supports the extension and the mailbox is user-locked. 
Non-extended email servers will ignore them. This provides backward 
compatibility. Encryption should not be employed in any extension. It 
will not be effective as a security measure and it will only create a 
false sense of security. The headers are described as follows:

The To-Mailbox-Key header contains the key to the recipient's mailbox. 
When the message arrives, the To-Mailbox-key is compared to the list of 
keys kept by the incoming server for the addressed mailbox. The result 
of the comparison determines whether the message is stored into the 
mailbox or whether it is bounced.

The From-Mailbox-Key header contains a current key to the sender's 
mailbox. It would be sent in response to a key request or if the sender 
wanted to include it for a reply.

The New-Mailbox-Key header contains a new key to the sender's mailbox. 
It would be sent when the sender wants to give someone a new key to 
their mailbox. The From-Mailbox-Key could be used for verification by 
having the recipient email client match it to the sender's current key 
in the address book. An exception could be accepted or overridden by the 
user.

The Request-Mailbox-Key header requests a key to the recipients mailbox. 
It would be accompanied by a From-Mailbox-Key header that provides the 
recipient with the requestor's key. Then when the New-Mailbox-Key header 
is returned, it will be accepted by the requestor's mail server. All 
messages with a Request-Mailbox-Key are stored into the recipient's 
mailbox. It is the only type that does not require a To-Mailbox-Key 
header. No message body may be present; the subject header must not be 
present or must be blank; the name portion of the to and from email 
addresses must not be present; no other headers that may contain 
embedded messages may be present. If so, the request is bounced.

The email client and sending server need to take the case of multiple 
recipients into consideration. The email client will send email 
address/mailbox key pairs for each recipient. The outgoing email server 
must ensure that all To-Mailbox- Key headers, except the one for the 
current outgoing email, are stripped from the message and that only one 
To-Mailbox-Key header exists in the outgoing message. Forwarded messages 
should also be stripped of all mailbox keys by the email client, except 
for the mailbox key of the recipient.

The headers must be handled by the email client and the incoming server 
in such a way that the use of keys is easy for the user. No header 
should be removed from an email, by an incoming email server, before the 
recipient receives it.

The keys in the headers should be enclosed within a delimiter that is 
not part of the key so that spaces or other special characters are 
allowed within a key. The email client would edit keys for validity when 
they were created. The key length should be limited to some useable 
length. Perhaps 32, 50, 64 or 120 characters.

The key list on the server for a particular mailbox should be a variable 
length list or file. It should be ordered such that a quick search could 
be applied to the key list during the comparison process. If the keys 
are stored as ordered fixed length records, a binary search could be 
applied. One may want to implement the list as a tree. The 
implementation is up the server supplier. The number of entries in the 
list should not be limited from a functional standpoint. From a service 
standpoint, an ISP may want to allow for a specified number of free keys 
at no charge and then charge for keys above that number. But with spam 
gone and no more filtering, they should be able to afford the extra 
space for key storage.

A protocol needs to be defined so that an email client and the incoming 
email server, where the inbox resides, can communicate the mailbox state 
and the mailbox key list.

Sender Authentication

Sender authentication should be applied. A header called Sender-Auth or 
Sender-Verification will be inserted into the message by the sending 
server. It would consist of a delimited string containing the IP 
address, server identification, and a timestamp. The string would be 
preceded by the result of a function that was applied to that string as 
it was sent by the originating server. A delimiter would separate the 
function result from the string. The function would be implemented by 
the server administrator and would be unique for that server or set of 
servers.

A protocol would be created such that a receiving server could request 
that the originating server verify that the Sender-Auth header is 
consistent. The originating server would be required to apply it's 
function to the string as sent by the requesting server and then return 
the result. The receiving server would compare the returned function 
result with the result in the Sender-Auth header and if they match, the 
sending server is authentic.

Another authentication method would be for the originating server to 
send a short public encryption key in the result field. When the 
receiving server received the message, it would encrypt a short message 
and request the sending server to authenticate by decrypting the message 
with it's private key and sending the message back. If the returned 
message matched the encrypted message, the sending server is authentic.

An example of a function would be an 8 digit check sum of the string 
that is then exclusive ored with an 8 digit number that is unique at 
that time, for that server or set of servers. This would generate an 8 
digit result. Part of the function should be time based such that the 
function would actually change in some externally unpredictable manner 
over a determined interval of an day, hour or minute. The 8 digit number 
that is the target of the exclusive or, could be the changing value. It 
could be retrieved from a list of numbers in a file or it could be 
generated based on a timestamp. The string contains the timestamp of 
when the function was originally applied to the string. This is an 
example of one type of function. The actual set of usable functions is 
extremely large. The 8 digit result length is only an example. Result 
lengths would be determined by the sending server and could be from 1 to 
some arbitrary length, perhaps 20, 25, 32 or some other common standard 
currently in use.

The user should be able to turn this authentication on or off for their 
mailbox. If authentication-required is set by the user, and the 
authentication process fails, the message would be bounced. An ISP may 
elect to turn this on for all emails.

One may argue that this would add to internet traffic. Perhaps a little, 
but the messages would be quite short and the fact that they were 
present and in use would in the long run cut down on internet traffic 
that is illegitimate. Illegitimate internet traffic is traffic that is 
meant to deceive a recipient. It would certainly reduce illegitimate 
internet traffic at a server that had authentication-required set for 
incoming messages. The message could be bounced at any time after a 
Sender-Auth header was determined not to be authentic. Another 
consideration is that many incoming email servers are currently querying 
other servers on the internet for each email to determine if it is spam. 
This traffic would no longer be necessary since filters would no longer 
be required.

Questions and Answers

Will spammers continue to use invalid server and email addresses?

No. Noone can send a message to another email address and expect it be 
received into the mailbox without including a valid mailbox key. No one 
can request a valid key without sending a valid email address and a key 
to their mailbox. No messages will be accepted by a receiving email 
server unless the originating server can be authenticated.

How does this differ from white lists?

White lists are an attempt by an email client or receiving server to 
match incoming email to a list of acceptable senders through the use of 
a filter. This allows forged headers to make the message look like an 
acceptable email on a white list. Mailbox keys put the burden of being 
an accepted email on the sender. From the recipients point of view, it 
is passive in the same sense as an email address.

Since everyone gets email from different sources, white lists are 
maintained in the email client as filters. Most users don't know how to 
use filters in their email clients, so white lists are used by very few 
people.

With mailbox keys, the headers for the keys could still be "forged", but 
the chances of generating a correct key are very, very small. If this 
happens, the user can simply change the key.

Mailbox keys move the process of validating an email from the email 
client out to the incoming server where the message is received. 
Unacceptable messages are immediately bounced.

Will filtering still be necessary?

No filtering will not be necessary because a message from a sender is 
only accepted if it matches a recipient's mailbox key. Filtering creates 
some false positives   email that is not spam, but that the filter 
detects as spam. Filtering also allows some spam through because spam 
can be made to look to a filter, like it is not spam.

How easy will it be to use?

As easy or as hard as the email client supplier makes it. Most processes 
should be automated, but a user should be able to alter the behavior of 
the client to some extent, to suit his needs. Examples are:
(1) Manually or  automatically creating address book entries for 
incoming email and storing the senders key. (2) User selectable 
detection of new email senders and the creation of new entries for them 
in the address book. (5) Provide assistance in responding to a request 
key email. (4) Manually or automatically sending an email to everyone in 
the address book for whom the user wants to give a new key to the mailbox.

Comments and Questions from: - - - - -
The forum charged with discussing spam in the vicinity of the IETF is 
the Antispam Research Group - asrg@ietf.org - it's an open mailing list.

Query:
Since your proposal requires changing all email clients in the world and 
managing a key ring for all your friends, how is it easier to implement 
than globally starting to use PGP?

I suppose that it is somewhat of a key ring, but there is no encryption 
taking place. The key is only verified by the incoming mail server. The 
key is really analogous to a key to a lock rather than a key to a cipher.

How do you handle mailing lists?

Mailing lists are handled the same as any outbound email. The key to the 
recipient's mailbox must be sent with the message in a header. When one 
signs up for a list, he would supply a key or he would send an email to 
the list server to update the key to his mailbox. The list server has to 
be able to automatically update keys for an email address when the list 
member wants to send a new key. How the keys are sent back and forth to 
be updated is in the technical information.

Does the sender have to have the key for the list, and the list the keys 
for all the recipients? That means that all the list management software 
in the world is also on the critical update path.

I understand the issue. Yes, if the incoming mailbox for the list is 
locked, the sender has to have a key to the list. Only the list server 
has the keys of all of the members. When it receives a message, it will 
have to insert the key for each member as it sends the message to each 
individual member. Yes, unfortunately, list servers are on the critical 
update path.

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg