ietf-asrg
[Top] [All Lists]

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

2003-06-13 23:43:38
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(_at_)azza(_dot_)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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>