Subject: [Asrg] 4d. Consent Framework - Protocols and Formats (was Re: [Asrg] SMTP level unsubscribe)

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 13 Aug 2003 11:14:42 -0400

At 10:01 AM 8/13/2003, Andrew Akehurst wrote:
> > On Fri, 2003-08-08 at 07:57, Andrew Akehurst wrote:
> > ...........
> > This
> > is similar to a suggestion made on a talk-radio show last week,
> > the show was on spam, Missouri might be rolling out a law against
> > return address forging.  A caller suggested adding a "bounce" button
> > to their MUA in addition to the "delete" button.
> >
> > The pay2send MTA, which I am and havebeen working on, will use rules
> > to allow wanted messages in, and block all else.
>
>In order for the MTA to be able to do this, the end user must
>be able to communicate policy decisions to it, so that the MTA
>knows which messages are "unwanted".
>
>If there were a standard for expressing and communicating such
>policies, it would allow any MUA to communicate policy with any
>compliant MTA. Then far more people would have the benefit of
>using such a system.
>
>I'm willing to volunteer to help draft such a standard, in line
>with Section 2.6 of the Consent Framework. Who wants to help?

Can you be more specific as to what you wish to work on? Below is the 
relevant section from the consent framework document. Keep in mind that 
Eric Dean's CRI protocol for connecting C/R systems together is relevant to 
2.5, item #2 (protocols for sharing consent tokens).

Before defining a protocol to exchange consent information, we need to 
define how consent is expressed in machine-readable form. This requires 
taking care of all the the items in 2.6 before moving on to the protocols.

--------------snip--------------
2.5. Protocols.

A MAIL TRANSFER PROTOCOL is used to transfer email messages between the 
SENDER and the RECEIVER. This transfer process may involve one or more 
software AGENTS.

[Ed. more protocols needed:

1. Protocols for sharing CONSENT RULES, SCOPE RULES and CONSENT POLICIES
2. Protocols for sharing CONSENT TOKENS. ]

2.6. Formats.

[Ed. We need to define:
1. Language and format for CONSENT AND SCOPE RULES
2. Format for CONSENT POLICIES.
3. Format for CONSENT TOKENS.
]
--------------snip--------------  

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

---

From: Andrew Akehurst <[email-masked]>
Date: Wed, 13 Aug 2003 17:37:14 +0100 (BST)

> Eric Dean's CRI protocol for connecting C/R systems together is relevant
> to 2.5, item #2 (protocols for sharing consent tokens).
> 

I'm interested in creating a machine-readable format for 
expressing consent policy. Clearly this is a pre-requisite to
defining protocols, because a protocol needs to have some data
to exchange. 

> 3. Format for CONSENT TOKENS.

A few definitions to remind ourselves...

> CONSENT POLICY – a set of CONSENT RULES and SCOPE rules for
>   a specific RECEIVER

> CONSENT TOKEN – a piece of data that is used by the POLICY 
>   ENFORCEMENT COMPONENT to grant or revoke CONSENT based on
>   the CONSENT POLICY

> SCOPE RULES – rules defining how CONSENT POLICIES are shared

I see the requirements for such a format as being:

- it should be capable of being efficiently parsed by a machine.
  The grammar should not be ambiguous if possible

- it should be relatively easy for a human being to read.
  This will aid debugging of protocol design and also allow
  advanced users to write their own policy by hand

- it should be extensible, because new ways of detecting
  spam will arise in future, possible involving new types of
  rule or new consent token formats. This will allow some
  adaptation when spammers change their tactics

If anyone wishes to suggest additional requirements, please do.

Once we get the requirements agreed, I have a list of other
things I'd like to iron out, starting with some definitions
of scopes and policy enforcement decisions.

Comments? Suggestions?

Andrew

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 13 Aug 2003 19:54:57 -0400

At 12:37 PM 8/13/2003, Andrew Akehurst wrote:

> >>..........
>..........
> > CONSENT POLICY ¡ a set of CONSENT RULES and SCOPE rules for
> >   a specific RECEIVER
>
> > CONSENT TOKEN ¡ a piece of data that is used by the POLICY
> > SCOPE RULES ¡ rules defining how CONSENT POLICIES are shared
>

Take a look at the mailing list archive (gmane.org), there were a few 
articles with links to a bunch of XML formats that can be used as a basis 
or as an example for us. Also, I think basis this on XML should be a 
requirement as well.

Yakov

---

From: Pete McNeil <[email-masked]>
Date: Wed, 13 Aug 2003 21:37:48 -0400

>At 12:37 PM 8/13/2003, Andrew Akehurst wrote:

<snip>

>or as an example for us. Also, I think basis this on XML should be a 

I think I suggested a number of XML structures for this, and I have a 
pretty good feel for where I was headed with that effort, and I still think 
XML is likely to be the best route. If the group feels this is a good 
direction I would be willing to try and flesh out some examples and 
specifications.

I recommend that we create an example that shows a hypothetical 
implementation and then solicit comments. We will use the comments to 
refine the example (replete with comments explaining what we've done and 
why). When the example stabilizes we can write a complete specification 
from that.

This is sort of like watching where the grass wears out around a campus and 
then pouring the  sidewalks over the worn out paths.

_M

---

From: Andrew Akehurst <[email-masked]>
Date: Thu, 14 Aug 2003 11:30:18 +0100 (BST)

>> articles with links to a bunch of XML formats that can be used as a
>> basis or as an example for us. Also, I think basis this on XML should 
>> be a requirement as well.

> pretty good feel for where I was headed with that effort, and I still
> think XML is likely to be the best route. If the group feels this is 
> a good direction I would be willing to try and flesh out some examples
> and specifications.

I quite like XML, although I know some people like Gordon really 
don't like it. However the nice thing about XML is that it's widely
known, easily readable by both humans and machines and there are 
existing XML parser libraries for just about every programming
language available which leaves plenty of choice for implementation.

> This is sort of like watching where the grass wears out around a campus
> and then pouring the  sidewalks over the worn out paths.

That seems like a good way to proceed. I found some of your previous
posts on the topic. I might be tempted to haggle about the syntax of
some of the examples, but the general thing that seems to come out 
of it is that we need (as a minimum):

 - definitions of tests against which to match messages

 - definitions of different policy enforcement actions which 
   can be taken for incoming messages

 - a set of policy statements which map a combination of tests
   onto a policy enforcement action

Obviously there will be some scope issues with each of these areas,
although I'm not yet convinced that "scopes" are first-class 
objects in their own right.

Some tests and policy decisions might be considered so fundamental 
that all compliant implementations are required to support them.
Others might include definitions which point to external programs
to allow extensibility.

For example, a test to see if an e-mail contains HTML Javascript
constructs might be required by the standard, whereas a test to
see if the sender's IP address is listed in a particular commercial
DNSBL might be provided by an external program.

Just an example of course, but this goes back to what you (Pete)
said back in this posting:

http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg06588.html

  "Some of the tests should be on the _MUST IMPLEMENT_ list for a
   compliant system. Specifically those that are "well known" and 
   defined by this group (and the group(s) that eventually manage
   and contribute to a [consent definition language])."

If we can create a few good examples then those will suggest some
of these "well known" tests and policy actions.

I'll have a think about some possible examples of my own, and we
can compare examples/syntax ideas.

Thanks

Andrew

---

From: "Eric Dean" <[email-masked]>
Date: Thu, 14 Aug 2003 13:16:59 -0400

Guys,

Consent based systems don't exist.  Challenge response systems do
exist...though often broken.  Rather than create something new, let's try to
fix what we have..then understand how to design it better.

In other words, I have yet to receive a single comment on the CRI draft.
There's a lot of smart people in the group..let's hear it.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 14 Aug 2003 13:24:20 -0400

The CRI protocol is an example of a token exchange protocol used to 
exchange consent tokens. It is a perfect example of what a consent token 
and consent systems would look like. Also, there is an incentive to have 
this protocol operational today since they are a few C/R systems that 
already exist and the vendors expressed interest in them. The most recent 
draft of the CRI protocol can be found in this message:

http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg06731.html

Below is the relevant quote from the consent framework document 
(http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html):

----snip----
2.5. Protocols.
.........

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 14 Aug 2003 13:35:03 -0400

From the consent framework, section 3:

SCOPE û combination of SCOPE RULES defining how CONSENT POLICIES are shared
SCOPE RULES û rules defining how CONSENT POLICIES are shared

The question is whether SCOPE and SCOPE RULES are independent, or are they 
just specific examples of CONSENT RULES and POLICIES.

Yakov

---

From: Andrew Akehurst <[email-masked]>
Date: Fri, 15 Aug 2003 12:02:43 +0100 (BST)

> Consent based systems don't exist. 

They do exist, just not in a standardised form.

Every time I set up a MUA filter to remove certain messages from 
my mail or use something like SpamAssassin, I'm making a decision
about what e-mail I consent to receive. Just because I'm not
sharing those preferences with anyone else and because there is
no standard way to write out those rules doesn't mean they're 
not an expression of consent.

> Challenge response systems do exist...though often broken. 

I see challenge response systems as a subclass of consent based
systems. They seem to implement a policy which says "I only want
to receive e-mail from people who are prepared to follow a certain 
protocol (or who use software which supports it)."

There's nothing wrong with that in principle, although as you 
note there are problems with it.

> Rather than create something new, let's
> try to fix what we have..then understand how to design it better.

The value in creating something new is that we're creating 
something more general than challenge response systems. Consent
based systems could include several different methods for
expressing and enforcing consent.

> In other words, I have yet to receive a single comment on the CRI

Until recently I've been very busy. I'll take a look at it later
today. I'm not opposed to challenge response systems, I just think
that there's an opportunity to create something broader.

There are problems with each type of consent system, none of them
is perfect. But using a combination of such systems within a 
broader framework can help to overcome the limitations of each. I 
agree that we should work to improve CRI and indeed all such
systems as far as possible. But I doubt that relying on a single
approach will yield effective results for everyone.

There are so many groups of users who use mailing lists, roaming
network access, NAT, DHCP and many other uses and configurations.
Few solutions are suitable for all of these types of user and so
they should be free to use whatever system(s) work for them. In
which case they need some way to tie everything together.

If we can improve CRI to the point where it will work well on 
its own for 99.9% of e-mail users then I'd be happy to admit I
was wrong. Until then, other research efforts are equally
valuable and can continue in parallel.

Andrew

---

From: Andrew Akehurst <[email-masked]>
Date: Fri, 15 Aug 2003 15:18:00 +0100 (BST)

> SCOPE  combination of SCOPE RULES defining how CONSENT POLICIES are
> shared
>
> SCOPE RULES  rules defining how CONSENT POLICIES are shared

Thanks for the reminder.

> The question is whether SCOPE and SCOPE RULES are independent, or are
> they just specific examples of CONSENT RULES and POLICIES.

It's tempting to think that "scope" is merely an attribute of a rule,
rather than an entity in its own right. 

If scope were a simple value then I don't see what attributes 
it could have, other than being "local", "shareable" or whatever 
value the scope has. (I invented these labels at random, I'm not 
claiming they're good suggestions, just examples that came to mind
at the time)

It's a common design principle that anything which has only one
attribute (i.e. its value) is not considered to be a separate entity
but is instead a flat "primitive" attribute of something else. 
I'd suggest that (for the sake of simplicity) unless anyone can 
demonstrate that a scope has additional attributes of its own, then
why not make scope part of a rule or policy definition?

A nice example of this use of scope was Jon Kyme's example of a 
consent schema:

  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01022.html

His suggestion was for scope to be "local", "organisational" or
"global", with regards to how widely it is shared. Is this a 
reasonable starting point?

The discussion that followed with Keith Moore was interesting and
dealt with some of the issues to do with how to establish that a 
policy is genuine and with priority conflicts between multiple rules.
It's worth a second look.

Andrew