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 NAA08457 for <asrg-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:20 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIcZ514554 for asrg-archive@odin.ietf.org; Fri, 27 Jun 2003 14:38:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy7D-0003m8-Gk for asrg-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:38:31 -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 OAA11654; Fri, 27 Jun 2003 14:38:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy6L-0003WC-98; Fri, 27 Jun 2003 14:37:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vw7f-0008Du-01 for asrg@optimus.ietf.org; Fri, 27 Jun 2003 12:31:21 -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 MAA06700 for <asrg@ietf.org>; Fri, 27 Jun 2003 12:30:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vw7d-0004Ux-00 for asrg@ietf.org; Fri, 27 Jun 2003 12:30:49 -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 19Vw7R-0004Ui-00 for asrg@ietf.org; Fri, 27 Jun 2003 12:30:38 -0400
Message-Id: <5.2.0.9.2.20030627122823.00babb10@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: gep2@terabites.com, asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Re: [Asrg] Consent Proposal
In-Reply-To: <B0000024281@nts1.terabites.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:29:46 -0400

At 12:55 AM 6/27/2003 -0500, gep2@terabites.com wrote:

> > 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.
>
>I'd like to make sure that those rules can be specified differently for any
>given sender... and, for that matter, any given destination E-mail 
>address,  so
>you can give specific rights to some senders (who need those for the kind of
>things I expect to receive from them) while denying those same rights to 
>other
>senders.  Right can be extended on a strict "need to send/trust to send" 
>basis.
>
>For example, many of us have several E-mail addresses (or even catch-all
>accounts) and I might wish a given sender to be able to send something to me
>under one of my "hats" that I might not accept from them (or indeed ANYBODY
>maybe) when I'm wearing a different hat.

How the rules are defined is left to the implementators. The point is to 
create a general framework and leave most of the details of specific 
implementations.

> > 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.
>
>Again, there needs to be different privilege levels specifiable for different
>sender/destination address pairs.

Once again this is left up to the implementation.

Yakov

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <research@solidmatrix.com>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------  


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