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 NAA08750 for <asrg-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:42 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIMw821380 for asrg-archive@odin.ietf.org; Fri, 27 Jun 2003 14:22:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxs9-0005Tm-LF for asrg-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:22:57 -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 OAA09283; Fri, 27 Jun 2003 14:22:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxrG-0004ev-IY; Fri, 27 Jun 2003 14:22:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vw9u-00006d-Nn for asrg@optimus.ietf.org; Fri, 27 Jun 2003 12:33:25 -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 MAA06768 for <asrg@ietf.org>; Fri, 27 Jun 2003 12:33:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vw9t-0004WB-00 for asrg@ietf.org; Fri, 27 Jun 2003 12:33:09 -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 19Vw9g-0004Vu-00 for asrg@ietf.org; Fri, 27 Jun 2003 12:32:57 -0400
Message-Id: <5.2.0.9.2.20030627123011.030f0978@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: Peter Kay <peter@titankey.com>, asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: RE: [Asrg] Consent Proposal
In-Reply-To: <DD198B5D07F04347B7266A3F35C42B0B0FD07E@io.cybercom.local>
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:32:32 -0400

At 05:53 PM 6/26/2003 -1000, Peter Kay wrote:

>I think you've got the beginning of a consent-based framework. I like
>it. What I'm getting out of this is:
>
>A. there exists a plug-in infrastructure that can run on MUA or MTA
>(ISP).

Plug-in is not the correct word here, we are seeking to create a general 
framework with details left for specific implementations.

>B. each plug-in provides for some type of policy definition, related to
>the plugins purpose. This can range from filtering to CR to all the
>other methods mentioned below.

Each implementation/

>C. each plug-in can be configured by a hierarchy. Starting w/ the ISP
>(for instance), then perhaps a domain-level admin (for corporate
>applications0 and then the end-user.  We can decide on varying levels of
>defaults or override capability so that for example if an ISP whitelists
>a source, the end-user may have the option to blacklist it.

Are you suggesting that the various implementations should be able to 
interoperate? This can be done by defining interoperability protocols like 
the CRI protocol for C/R systems.



>To me, this reinforces what I've seen over the past few months on this
>group:
>
>1. no one can agree what spam is. So at the end of the day, the user has
>to have the power to decide. This is in line w/ the charter.

Agreed

>2. no one technological approach "religion" (i.e. filtering, C/R, etc)
>is adequate to deal with the general problem of "unwanted email".

Agreed.

>3. spammers will change their methods as time goes on, so the
>architecture must allow for that.

Agreed


>In addition, a consent-based framework allows for multiple vendors to
>participate. If we can create some sort of "email bus" I think it has a
>lot of potential.

An email bus? Can you explain this?



> > -----Original Message-----
> > From: Yakov Shafranovich [mailto:research@solidmatrix.com]
> > Sent: Thursday, June 26, 2003 11:23 AM
> > To: asrg@ietf.org
> > Subject: [Asrg] Consent Proposal
> >
> >
> > I would like to provide a generic proposal for consent-based
> > system as per
> > charter:
> >
> > 1. Users and/or ISP define rules and filters to filter
> > incoming email.
> > Rules/filters are decided by end users and ISPs, and are not
> > mandated.
> > Every user/ISP can define its own policies ranging from
> > banning all email
> > not digitally signed to blocking HTML.
> > 2. For each email user, the MUA or the ISP maintains a
> > whitelist of trusted
> > senders, blacklist of blocked senders and a graylist of
> > unknown senders.
> > Whitelisted senders go the inbox, graylisted senders go to
> > the bulk folder,
> > and blacklisted senders are either in the spam folder or
> > erased. 3. Whitelists are not only a list of email addresses
> > of trusted senders,
> > but to avoid sender spoofing also have additional features
> > such as digital
> > signatures, certificates, passwords, tokens, etc.
> > 4. Additional automatic whitelist rules are defined as such
> > email from
> > trusted senders (e.g. Habeas) is automatically goes to the
> > inbox unless
> > blacklisted, etc. C/R systems are also integrated and upon
> > receiving a
> > positive response automatically whitelist the sender.
> > 5. Additional automatic blacklist rules are defined such as
> > email coming
> > from known open relays is blocked.
> > 6. Whitelists, graylists and blacklists are stored hashed or
> > encrypted to
> > protect privacy.
> >
> > Any thoughts?
> >
> > Yakov
> >
> >
> > _______________________________________________
> > Asrg mailing list
> > Asrg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/asrg
> >
> >
> >
>
>
>
>_______________________________________________
>Asrg mailing list
>Asrg@ietf.org
>https://www1.ietf.org/mailman/listinfo/asrg


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