Subject: [Asrg] Consent Proposal

From: [email-masked]
Date: Fri, 27 Jun 2003 00:55:55 -0500

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

I'd like to make sure that those rules can be specified differently for any 
given sender... and, for that matter, any given destination E-mail address,  so 
you can give specific rights to some senders (who need those for the kind of 
things I expect to receive from them) while denying those same rights to other 
senders.  Right can be extended on a strict "need to send/trust to send" basis.

For example, many of us have several E-mail addresses (or even catch-all 
accounts) and I might wish a given sender to be able to send something to me 
under one of my "hats" that I might not accept from them (or indeed ANYBODY 
maybe) when I'm wearing a different hat.

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

Again, there needs to be different privilege levels specifiable for different 
sender/destination address pairs. 

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 27 Jun 2003 15:18:39 -0400

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

>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.
>[..]
>
>Spam elimination by mailbox lock and key (or token) and by
>sender authentication
>[..]

The main crux of the proposal is that the sender and receiver share a key 
which expresses agreement to exchange email - i.e. consent. The key is a 
consent token.

My problem is that this is a specific implementation or way to build 
consent systems. We should strive to define a general consent framework 
into which proposals such as this will fit.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 27 Jun 2003 15:21:46 -0400

At 04:29 PM 6/27/2003 +0100, Jon Kyme 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.
> >
>
>There is quite a common misaprehension (as I see it):
>that systems which rely on "consent tokens" must solve the larger
>problem of "consent based communication".

Correct.

>Clearly, consent token based systems do seek to enforce the
>recipients wish for consent based communication.
>However, generally, I can chose to consent (or not) to receive any message
>(or class of messages) that I can describe, and I can hope
>that there exists an agency which will enforce my expressed policy.
>
>This is not merely an academic point. The problem has been generalised
>(this is a good thing), we should be able to form a general description
>of the kind of things that might offer solutions.

There are seems to be two ways to deal with spam. One way, proposed by 
Barry Shein and Eric Brunner, is by concentrating on the senders of spam, 
and the network that carries it, and shut the senders down. These MAY 
INCLUDE legal measures, low-level network detection, coordinated detection, 
anti-DDOS tactics, etc. The second way which is defined in the charter is 
by looking at the receiver's end - and define a consent framework to be 
used by receivers.

Yakov

---

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

At 02:09 PM 6/27/2003 -0400, Bob Wyman wrote:

> > an overall consent framework
>         Yes, I'd like to see that framework... I think there are a
>number of questions that should be answered by it:
>
>         What is the "language" of consent? When you consent, what is it
>that you consent to? Or, when you withhold consent, what is it that you
>withhold consent for? In simple systems, consent is binary and focused
>only on senders. Either a sender may, or may not, send messages.

This is definitely an issue that needs to be defined. I think we need to 
define a broad overview of consent framework and then start working on 
specific issues such as this.

>However, some have proposed that consent be granted in a much more
>granular fashion. Thus, you should be able to consent based on a number
>of attributes such as:
>         0. Identity of sender
>         1. Size of message
>         2. Encoding of message (character sets, HTML, etc)
>         3. Source IP (presence on white/blacklists)
>         4. From: header matches with sending server (i.e. RMX, etc.)
>         5. Presence of signatures
>         6. Presence of attachments
>         7. Rate of message arrival (i.e. only 3 messages per day per
>sender...)
>         8. Words used in message. (i.e. no message using "bad" words)
>         9. Use of Multi-part MIME
>         10. etc...
>         The goal here should be to define the "language" of consent. To
>show what can be said and perhaps understand under what circumstances it
>is reasonable to say these things and what benefit can come from saying
>them. Also, some attention should be paid to the issues of what can and
>cannot be determined by a machine. For instance, a machine can easily
>measure the size of message. A machine can also, in some cases,
>determine what account was used to send a message. However, a machine
>will not be able to determine the actual human who caused a message to
>be sent. (not even with PKI, signatures, etc...)

Very good point.

>         We should distinguish between consent which is implied (by
>reliance on some mechanism such as RMX) or explicit -- i.e. consent that
>is expressed independent of the consent management mechanism in some
>form like a "license to send" or a consent token.
>         Explicit statements of consent have interesting properties
>especially if they are encoded in a machine readable form. For instance,
>a simple expression of consent such as "I don't except mail that
>contains the word 'Viagra'." can be used to parameterize the behaviour
>of spam filters on the recipient's desktop as well as on upstream
>processors such as the recipient's ISP's servers. One might even pass
>such a statement to a potential sender. In one possible world, a sender
>might have a pop-up in their editor that warns them that "Use of the
>word 'Viagra' will prevent delivery of this message to one or more of
>the current recipients."
>         An expression of consent might also serve as a license that can
>be used by the sender. For instance, if I consent to receive mail from
>you, you should be able to use some kind of a token or certificate to
>ensure that your messages bypass interference by any filtering
>mechanisms in the channel between us.

These all are very good points. I will be writing up something later on 
this week and putting in on the list laying out the consent framework and 
different issues that need to be defined.

Yakov