Re: [Asrg] Consent Proposal

Yakov Shafranovich wrote:
> 
> The charter goes on and on about consent, however aside from Gordon's 
> HTML blocking thread, there has been no discussion of that. If 
> discussion of consent is premature at the moment, what should we be 
> looking at right now? In general, what directions should the group be 
> pursuing at the moment? As it appears rights now, there are mainly 
> various discussions about everything under the sun, but no concrete 
> sense of direction at all.
> 
> Yakov
> 

How can you say that? The entire proposal that I submitted
was completely and totally about consent and authentication.
I understand that it may not be painless to implement, but I
have read no proposal here that would be both effective and
painless.

I don't like whitelists, blacklists or greylists. They must
be constantly maintained by someone.

I very much like the idea of a keylist or token list being
resident on the incoming mail transfer agent. I like the idea
that the key list is maintained by the user with the help
of the user agent. I like the idea that the key list or
token list represents senders that are allowed to send
email, but they don't identify them. There is no privacy
issue. I like the idea that there is not a one to one
relationship between keys and senders. I like the idea that
the exchange of keys between receipients and senders can be
somewhat automated by the user agent.

I'm posting this again for any who may have missed it.

Yes, it's long, but that's because there is a lot of information.

Spam elimination by mailbox lock and key (or token) and by
sender authentication

Contents:
I.   Introduction
II.  General Description:
III. Detailed information:
IV.  Technical Description
      A.   Email Extensions for client and servers (user
           agents and mail transfer agents)
      B.   Sender Authentication
V.   Questions and Answers

I.   Introduction

This is a proposal to enhance email with the objective of
eliminating spam. I am fed up with spam and I spent some
time thinking of a solution. I have organized these ideas
and written them up. I know there are 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 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.

Throughout this discussion, I use the word client for user
agent and server for mail transfer agent.

The word key is used to describe a set of characters to
identify a sender. The words token and password are close
synonyms in this context.

II.  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.

III. 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.

3. Suppliers of email servers will have to extend their
email servers as well as list servers. 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 . . . . 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. 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.

IV.  Technical Description

A.   Email Extensions for client and servers (user agents
and mail transfer agents)

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.

B.   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 employed 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.

V.   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