Subject: Re: [Asrg] Consent Proposal

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 27 Jun 2003 12:27:57 -0400

At 07:53 AM 6/27/2003 +0100, Jon Kyme wrote:

> > >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.
> >
> > The charter goes on and on about consent, however aside from Gordon's
> > 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

Original message at 
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00669.html

><[email-masked]> "[Asrg] What would consent look
>like?"

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

---snip---
Consent might look something like this:
applies-to:  [email-masked]
classes:     set of message classifications
access:      allow | deny
scope:       local | organisational | global
---snip---

And  

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

---

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

At 07:53 AM 6/27/2003 +0100, Jon Kyme wrote:

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

This is consistent with the charter which proposes these components as well.

---snip---
The research group will investigate the feasibility of: (1) a single 
architecture that supports this and (2) a framework that allows different 
systems to be plugged in to provide different pieces of the solution.

Possible components of such a framework may include:

o Consent Expression Component: This involves recipients expressing a 
policy that gives consent or non-consent for certain types of communications

o Policy Enforcement Component: This involves subsystems within the 
communication system that enforce the policy. The overall framework may 
involve multiple subsystems within the policy enforcement component. This 
may involve fail-open or fail-closed approaches. With a fail-open approach, 
the system must identify messages that do not have consent. For example, 
this may include approaches that determine the nature of a message based on 
its characteristics or input from a collaborative filtering system. With a 
fail-closed approach, the system must identify messages that do have 
consent and only allow those to be delivered. For example, consent may be 
expressed by a policy, by a "consent token" within the message, or by some 
payment that essentially purchases consent or delivery rights.

o Source Tracking Component: This component provides deterrence to parties 
that consider violating the policy by facilitating identification and 
tracking of senders that violate the policy. This may require 
non-repudiation at the original sender, the sender's ISP, or some other 
entities involved in the communication system.

Note that "consent" need not necessarily be in advance. It is within scope 
for ASRG to consider frameworks in which receivers express their lack of 
consent only after having received a message.