Re: [Asrg] 4. Survey of Solutions - Consent Model

Yakov Shafranovich <research@solidmatrix.com> Mon, 14 July 2003 00:39 UTC

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 UAA09869 for <asrg-archive@odin.ietf.org>; Sun, 13 Jul 2003 20:39:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19brMh-0001iq-EF for asrg-archive@odin.ietf.org; Sun, 13 Jul 2003 20:38:51 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E0cpNO006619 for asrg-archive@odin.ietf.org; Sun, 13 Jul 2003 20:38:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19brMh-0001ig-8b for asrg-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 20:38:51 -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 UAA09864; Sun, 13 Jul 2003 20:38:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19brMe-0000FC-00; Sun, 13 Jul 2003 20:38:49 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19brMe-0000F9-00; Sun, 13 Jul 2003 20:38:48 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19brLs-0001fU-Hh; Sun, 13 Jul 2003 20:38:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19brKx-0001RU-Nn for asrg@optimus.ietf.org; Sun, 13 Jul 2003 20:37:03 -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 UAA09849 for <asrg@ietf.org>; Sun, 13 Jul 2003 20:37:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19brKv-0000Er-00 for asrg@ietf.org; Sun, 13 Jul 2003 20:37:01 -0400
Received: from 000-234-318.area5.spcsdns.net ([68.27.154.131] helo=68.27.154.131) by ietf-mx with esmtp (Exim 4.12) id 19brKs-0000Eo-00 for asrg@ietf.org; Sun, 13 Jul 2003 20:36:59 -0400
Message-Id: <5.2.0.9.2.20030713203631.00b394b0@solidmatrix.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: Andrew Akehurst <A.D.Akehurst-99@student.lboro.ac.uk>
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Re: [Asrg] 4. Survey of Solutions - Consent Model
Cc: asrg@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
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: Sun, 13 Jul 2003 20:36:35 -0400

At 02:15 PM 7/9/2003 +0100, Andrew Akehurst wrote:

> >> ........
> >> In the ultimate scenario where everyone uses some implementation of
> >> this consent framework it would be fine to make no distinction. However
> >> for the purposes of interoperability with non-compliant systems during
> >> roll-out of the new consent framework
> >> ........
>
> > The "new" consent framework is not replacing the current structure of
> > the Net. It is an ABSTRACT model that allows us to evaluate all anti-spam
> > proposals.
>
>I understand, all that I meant was that implementations will have to consider
>interoperability issues. I take it you feel that interoperability is not
>relevant to the model itself, only to specific proposals?
>
>That would make some sense, but we are still proposing a change to current
>behaviour in that we have new reasons why messages may not be delivered to
>their intended recipient (i.e. lack of consent). Therefore some messages 
>which
>would have been delivered under the existing system will not be delivered 
>under
>implementations of the consent framework.
>
>Since you say the purpose of the framework is to evaluate anti-spam 
>proposals,
>one of the criteria should be the likely impact on existing usage and
>interaction between existing users and those who have migrated to 
>consent-based
>software. Some of that detail will depend on implementation, but some 
>abstract
>ideas are so fundamentally different from the current system that *any*
>implementation of them would affect interoperability.
>
>Of course I know there are already many reasons why e-mail may not arrive 
>under
>the current open system, such as an invalid recipient e-mail address or a 
>lack
>of disk space at the receiver's incoming mail server. So maybe this issue is
>less important (to the abstract model) than I first thought.
>
>Anyway, I'd be interested to hear your comments about the issue.

There is a separate requirements document 
(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05084.html) 
outlining specific point-by-point requirements and a "Technical 
Considerations" document 
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt) 
which outlines more overall requirements. These are meanth to be used in 
conjunction with the model document.  


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