Subject: [Asrg] Consent Proposal

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 26 Jun 2003 17:23:25 -0400

I would like to provide a generic proposal for consent-based system as per 
charter:

1. Users and/or ISP define rules and filters to filter incoming email. 
Rules/filters are decided by end users and ISPs, and are not mandated. 
Every user/ISP can define its own policies ranging from banning all email 
not digitally signed to blocking HTML.
2. For each email user, the MUA or the ISP maintains a whitelist of trusted 
senders, blacklist of blocked senders and a graylist of unknown senders. 
Whitelisted senders go the inbox, graylisted senders go to the bulk folder, 
and blacklisted senders are either in the spam folder or erased.
3. Whitelists are not only a list of email addresses of trusted senders, 
but to avoid sender spoofing also have additional features such as digital 
signatures, certificates, passwords, tokens, etc.
4. Additional automatic whitelist rules are defined as such email from 
trusted senders (e.g. Habeas) is automatically goes to the inbox unless 
blacklisted, etc. C/R systems are also integrated and upon receiving a 
positive response automatically whitelist the sender.
5. Additional automatic blacklist rules are defined such as email coming 
from known open relays is blocked.
6. Whitelists, graylists and blacklists are stored hashed or encrypted to 
protect privacy.

Any thoughts?

Yakov

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 27 Jun 2003 00:43:40 +0100

> I would like to provide a generic proposal for consent-based system as

Point 1 is kindof axiomatic.
Point 6 is probably a "good thing".
2-5 are interesting if you believe that consent is limited to
cases where a receiver consents to any message from a listed (possibly
authenticated) sender. .

I don't believe that this adds up to what you claim.

There was some more fundamental (but probably premature)
discussion of "consent" early in the life this group.

--

---

From: Barry Shein <[email-masked]>
Date: Thu, 26 Jun 2003 19:49:11 -0400

A. There's nothing new here.

B. It remains to be shown that the approach is useful.

C. Repeating once again how these "rules and filters" are somehow
going to magically appear won't make it happen.

D. "For each email user the MUA or the ISP maintains a whitelist..."

MUAs don't maintain whitelists, people do. And that's the crux of the
problem as has been shown repeatedly, people generally don't know the
exact details of where the confirmation of their FTC/AT&T no-call list
is going to come from to put them on their whitelist. Etc.

So when they don't get the email and realize it's because they can't
possibly maintain a whitelist correctly they give up on whitelists.

The ISPs maintaining the whitelist has privacy issues (and don't just
jump back to ok then keep it in the MUA, that's a shell game, if half
your proposal lacks merit that's a problem.)

Not too many senators want to tell AOL that they think the email they
get from [email-masked] is ok and should be allowed through.

E. What are these digital certificates etc? What scheme are you basing
all this on? Or are you proposing that a new state of the art be
generated on demand (of the proposal's requirements)?

Anyhow, it's the same old dead-end "let's hypothesize a magical
program which only lets through what we want to see", declare victory,
and go home.

Since no one has been able to write this program thus far, and many
years and many people have tried, and there appears to be millions of
dollars to be had for the first person to show up with this program,
why would you want to carve its existence in stone?

I don't see "research" as equivalent to "wishful thinking".

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 26 Jun 2003 20:58:24 -0400

>discussion of "consent" early in the life this group.

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

---

From: Selby Hatch <[email-masked]>
Date: Thu, 26 Jun 2003 21:53:19 -0600

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 - [email-masked] -
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.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 26 Jun 2003 23:57:24 -0400

At 09:53 PM 6/26/2003 -0600, Selby Hatch wrote:

>>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
>
>[..]

Sorry Selby, I definatly must have missed it before. I will look it over 
carefully. Sorry :(

Yakov

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 27 Jun 2003 10:37:19 -0400

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.
	Not true... As Selby Hatch has already pointed out, his proposal
was focused on the consent issue. So are the various proposals that I've
made for "license to send" and/or "single user addresses" (stuff like
TMDA). See my first posting on 3-March -- one of the first in this
group... Also, quite a number of the patents that I've listed at various
times have been for "consent-based" systems of one form or another.

		bob wyman

---

From: Bruce Stephens <[email-masked]>
Date: Fri, 27 Jun 2003 12:15:55 +0100

Barry Shein <[email-masked]> writes:

> MUAs don't maintain whitelists, people do. And that's the crux of
> the problem as has been shown repeatedly, people generally don't
> know the exact details of where the confirmation of their FTC/AT&T
> no-call list is going to come from to put them on their
> whitelist. Etc.

That's an important problem, and it's one that the IETF (or some other
body, such as W3C) could help to solve.  

Something that would be helpful would be (say) and XML specification
for small documents that web sites could offer for email lists that
they run.  Such documents would include information about the
originator address of email from the list (or some other kind of
authenticator), and information for subscribing and unsubscribing from
the list, together with information about the list (description,
perhaps an icon that user agents can use).

I've phrased that poorly in the sense that the same idea would work
for short-term communication agreements (such as information about a
particular order from amazon.com, say).  Some documents could specify
an expiry time for this use.

Obviously, email clients would parse such documents, and (after
presenting the information and receiving confirmation) would be able
to set up the whitelist (also perhaps arranging a filter to put email
into a special folder), and then tell the originating site about the
desire to accept communications.  (I say "email client" on the grounds
that most people use IE/OE, so their email client is also their web
browser.  Obviously it would be slightly more complex if the two are
separate, but still readily doable.)

I'm not sure how the information would be passed to ISPs that offer to
do filtering.  As you say, there are privacy issues.  However, if
these privacy issues can (to a sufficient extent) be addressed, then a
standardised way for the permission information to be passed to ISPs
would be valuable.

Even in the absence of spam, that would be handy, since it would make
it easy to manage mailing lists (my MUA could show me a list, and
could automatically filter them into folders).

It wouldn't be so valued by many commercial organisations, since
subscribing to their advertising would involve more than not
unchecking a 2x2 pixel checkbox at the end of a long web page, but
that doesn't seem a big disadvantage to me.  I think the idea's a
potential win: it would make managing mailing lists (and similar
things, like information about specific things like orders) much
easier, and much more usable.

Given that we're mostly concerned with spam, making whitelists usable
can work with other approaches: something like RMX can make the
whitelist somewhat reliable even when using the originator address as
authenticator; using hashcash (or email stamps or something) would
permit unsolicited email (much interperson email could use hashcash,
for example), provided the sender is willing to pay the cost.

In fact, I think usable whitelists together with hashcash would be a
very nice email system.

[...]

> The ISPs maintaining the whitelist has privacy issues (and don't
> just jump back to ok then keep it in the MUA, that's a shell game,
> if half your proposal lacks merit that's a problem.)
>
> Not too many senators want to tell AOL that they think the email
> they get from [email-masked] is ok and should be allowed
> through.

True.  ISPs can already see that the senator is receiving email from
[email-masked], of course, but you're right that that's a big
step away from knowing that the senator has asked for it.

This seems a general problem where user-controlled filtering can
happen at the ISP: the ISP could record which emails have passed
through, and can make inferences about what email the user wants to
receive.  The better the quality of filtering that's being used, the
better the quality of the inference.

Ideas like hashing (especially with salts and other tricks) can reduce
the privacy implications of exposing the database that the ISP needs
to keep, but the ISP itself can just watch the traffic.

[...]

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 27 Jun 2003 07:53:53 +0100

> HTML
> blocking thread, there has been no discussion of that. 

You might be interested in the threads starting with
<[email-masked]> "[Asrg] The Consent 4-Tuple"
and
<[email-masked]> "[Asrg] What would consent look
like?"

>If discussion of 
> consent is premature at the moment, 

I meant premature at the time. People were busy contributing their pet
silver bullets. I thought this would have stopped by now.
Shows how much I know... :-)

>what should we be looking at right
> now?
> In general, what directions should the group be pursuing at the moment?

I strongly believe that you are right, that an analysis of the consent
problem is important. I believe that one can get to a general framework for
anti-spam systems from first principles.

I think it tends to something like:
message classifier function
+ expression of recipient policy (consent expression)
+ policy enforcement agent

--

---

From: Walter Dnes <[email-masked]>
Date: Sat, 28 Jun 2003 03:54:17 -0400

On Thu, Jun 26, 2003 at 05:23:25PM -0400, Yakov Shafranovich wrote
> I would like to provide a generic proposal for consent-based system as per 

  I have an account at clss.net.  They run a modified Qmail that parses a
config file in the user's home directory.  The filter rules are applied
during the SMTP transaction, just after the RCPT: stage.

> Rules/filters are decided by end users and ISPs, and are not mandated.

  Yup.  There's a "user friendly" frontend menu.  I prefer to manually
edit the filter file with vim for maximum flexibility.

> 2. For each email user, the MUA or the ISP maintains a whitelist
> of trusted senders, blacklist of blocked senders and a graylist
> of unknown senders.  Whitelisted senders go the inbox, graylisted
> senders go to the bulk folder, and blacklisted senders are either
> in the spam folder or erased.

  Because the blocking takes place during the SMTP transaction, the
sending MTA gets the big 550.  Rejected emails are *NOT* "bounced" to
innocent 3rd parties whose email addresses have been forged by spammers.

  - Whitelisted email goes through with a free pass, regardless of any
    other rules it may trip.

  - Blacklisted email gets a 550 message, in most cases containing a
    pointer to one of my webpages that has a current unfiltered
    temporary alternate email address.  This is a safety net for
    legitimate senders who get caught as collateral damage by the DNSbls
    or other blocking rules I use.  Spammers don't seem to read reject
    messages, so that filter bypass hasn't been abused yet.

  - Greylist... I define to mean that portion of messages that are not
    in my whitelist, but do not trip any of my blocking rules.  Those
    messages are accepted just like regular email.

> 3. Whitelists are not only a list of email addresses of trusted
> senders, but to avoid sender spoofing also have additional features
> such as digital signatures, certificates, passwords, tokens, etc.

  Since clss.net's system makes the decision before the DATA: stage,
this additional stuff is not available.  IP address and rDNS can be
used, however.

> positive response automatically whitelist the sender.

  I do it all manually.

> from known open relays is blocked.

  That's what DNSbls are for.  They update as new open relays and
proxies are discovered.  They also automatically de-list with closure.
I do have to manually add/delete countries that I block using the
zz.countries.nerd.dk superzone.  I started off with South Korea, China,
Taiwan, and Nigeria.  As Nigerian scammers realized Nigeria was blocked
to hell and back, they moved to the Netherlands, which I also had to
block.  France and Isreal have recently popped up on my spam radar.

> 6. Whitelists, graylists and blacklists are stored hashed or encrypted
> to protect privacy.

  That may generate a misleading warm fuzzy feeling, but it's useless.
A traffic log of your emails will show what you accept/reject.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: "Jon Kyme" <[email-masked]>
Date: Sat, 28 Jun 2003 16:13:38 +0100

> A traffic log of your emails will show what you accept/reject.

Walter, I've said this before, I'll say it again (no doubt) - There is an
important difference here: Traffic logs MAY preserve this information, and
of course many organisations (and many jurisdictions) have retention
policy. These anti-spam systems MUST preserve it (for some "long" time) and
so need to build-in provisions for security / privacy.

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 29 Jun 2003 14:22:48 -0400

At 12:18 AM 6/27/2003 -0700, Howard Roth wrote:
>[..]
>
>Here's an idea about validating a message before I can ever see it.  This
>can be considered a consent-based concept, as it can be a parameter at the
>ISP end for each mail user. It adds quite a bit of overhead to the mail
>server as it requires two additional messages for each one sent.  I see it
>being part of the MTA process.  I send a message to someone.  The MTA
>replies to the message with a "proof of sender request, " basically a
>specially formatted email message that goes back to the server that sent it
>based on the return address.  The sender's MTA responds with a "confirmation
>request"  if it did send the message and the message is now available for
>download based on moving it from the pending directory to a user directory.
>If there is no response within a certain period the message is discarded.
>[..]

This has been proposed before by John Fenley as part of C/R systems (see 
this message 
http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05173.html). 
I was thinking of putting it into the CRI protocol that Eric Dean is 
working on.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 30 Jun 2003 22:33:55 -0400

>could automatically filter them into folders).

This is going hand in hand with what Bob Wyman mentioned - we need to 
define what consent is, how to express it and how to make sure that various 
mail system can communicate consent between themselves.

Yakov