Re: RE: [Asrg] Consent Proposal

Yakov Shafranovich <research@solidmatrix.com> Fri, 27 June 2003 19:25 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 PAA16514 for <asrg-archive@odin.ietf.org>; Fri, 27 Jun 2003 15:25:54 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RJPPc10545 for asrg-archive@odin.ietf.org; Fri, 27 Jun 2003 15:25:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vyqb-0002k0-HJ for asrg-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 15:25:25 -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 PAA16448; Fri, 27 Jun 2003 15:25:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vyq0-0002Tq-1C; Fri, 27 Jun 2003 15:24:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vynm-0002LS-Hr for asrg@optimus.ietf.org; Fri, 27 Jun 2003 15:22:30 -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 PAA16252 for <asrg@ietf.org>; Fri, 27 Jun 2003 15:22:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vynl-0005ZD-00 for asrg@ietf.org; Fri, 27 Jun 2003 15:22:29 -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 19VynZ-0005Z0-00 for asrg@ietf.org; Fri, 27 Jun 2003 15:22:18 -0400
Message-Id: <5.2.0.9.2.20030627151536.00b92090@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: Jon Kyme <jrk@merseymail.com>, bob@wyman.us, Barry Shein <bzs@world.std.com>
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Re: RE: [Asrg] Consent Proposal
Cc: ASRG <asrg@ietf.org>
In-Reply-To: <E19VvAH-0003N0-00@argon.connect.org.uk>
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 15:21:46 -0400

At 04:29 PM 6/27/2003 +0100, Jon Kyme 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.
> >       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




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