[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>
|
- [Asrg] 6.I Spam elimination by mailbox lock and key,
Selby Hatch <=
|
|
|