Re: [Asrg] Consent Proposal

Yakov Shafranovich <research@solidmatrix.com> Tue, 01 July 2003 17:48 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08594 for <asrg-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:32 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIZMo10311 for asrg-archive@odin.ietf.org; Fri, 27 Jun 2003 14:35:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy3z-0002fV-7I for asrg-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:35:11 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11211; Fri, 27 Jun 2003 14:35:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy3G-00024k-ET; Fri, 27 Jun 2003 14:34:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VvuD-0007Za-2D for asrg@optimus.ietf.org; Fri, 27 Jun 2003 12:16:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05974 for <asrg@ietf.org>; Fri, 27 Jun 2003 12:16:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VvuB-0004H5-00 for asrg@ietf.org; Fri, 27 Jun 2003 12:16:55 -0400
Received: from 000-256-240.area7.spcsdns.net ([68.27.240.209] helo=68.27.240.209 ident=trilluser) by ietf-mx with smtp (Exim 4.12) id 19Vvtz-0004Gt-00 for asrg@ietf.org; Fri, 27 Jun 2003 12:16:44 -0400
Message-Id: <5.2.0.9.2.20030627121420.00b97d88@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: Jon Kyme <jrk@merseymail.com>
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Re: [Asrg] Consent Proposal
Cc: ASRG <asrg@ietf.org>
In-Reply-To: <E19Vn7J-00031y-00@argon.connect.org.uk>
References: <5.2.0.9.2.20030626205450.00b41768@std5.imagineis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
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.
---snip--- 


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg