Re: [Asrg] Consent Proposal

Barry Shein <bzs@world.std.com> Thu, 26 June 2003 23:54 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 TAA27853 for <asrg-archive@odin.ietf.org>; Thu, 26 Jun 2003 19:54:39 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QNsBP30117 for asrg-archive@odin.ietf.org; Thu, 26 Jun 2003 19:54:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgZ9-0007pg-Gz for asrg-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 19:54:11 -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 TAA27848; Thu, 26 Jun 2003 19:54:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgZ7-0007G8-00; Thu, 26 Jun 2003 19:54:09 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VgZ1-0007G5-00; Thu, 26 Jun 2003 19:54:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgYy-0007eG-Uo; Thu, 26 Jun 2003 19:54:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgYj-0007dw-JE for asrg@optimus.ietf.org; Thu, 26 Jun 2003 19:53:45 -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 TAA27842 for <asrg@ietf.org>; Thu, 26 Jun 2003 19:53:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgYh-0007Fu-00 for asrg@ietf.org; Thu, 26 Jun 2003 19:53:43 -0400
Received: from pcls1.std.com ([199.172.62.103] helo=TheWorld.com) by ietf-mx with esmtp (Exim 4.12) id 19VgYX-0007Fo-00 for asrg@ietf.org; Thu, 26 Jun 2003 19:53:33 -0400
Received: from world.std.com (world-f.std.com [199.172.62.5]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h5QNnBtD007972; Thu, 26 Jun 2003 19:49:12 -0400
Received: (from bzs@localhost) by world.std.com (8.9.3/8.9.3) id TAA29412; Thu, 26 Jun 2003 19:49:11 -0400 (EDT)
From: Barry Shein <bzs@world.std.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <16123.34423.451831.720851@world.std.com>
To: Yakov Shafranovich <research@solidmatrix.com>
Cc: asrg@ietf.org
Subject: Re: [Asrg] Consent Proposal
In-Reply-To: <5.2.0.9.2.20030626171332.00bd13e0@pop.pocketmail.com>
References: <5.2.0.9.2.20030626171332.00bd13e0@pop.pocketmail.com>
X-Mailer: VM 7.07 under Emacs 21.2.2
Content-Transfer-Encoding: 7bit
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: Thu, 26 Jun 2003 19:49:11 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

A. There's nothing new here.

B. It remains to be shown that the approach is useful.

C. Repeating once again how these "rules and filters" are somehow
going to magically appear won't make it happen.

D. "For each email user the MUA or the ISP maintains a whitelist..."

MUAs don't maintain whitelists, people do. And that's the crux of the
problem as has been shown repeatedly, people generally don't know the
exact details of where the confirmation of their FTC/AT&T no-call list
is going to come from to put them on their whitelist. Etc.

So when they don't get the email and realize it's because they can't
possibly maintain a whitelist correctly they give up on whitelists.

The ISPs maintaining the whitelist has privacy issues (and don't just
jump back to ok then keep it in the MUA, that's a shell game, if half
your proposal lacks merit that's a problem.)

Not too many senators want to tell AOL that they think the email they
get from hotties@big-butts.com is ok and should be allowed through.

E. What are these digital certificates etc? What scheme are you basing
all this on? Or are you proposing that a new state of the art be
generated on demand (of the proposal's requirements)?

Anyhow, it's the same old dead-end "let's hypothesize a magical
program which only lets through what we want to see", declare victory,
and go home.

Since no one has been able to write this program thus far, and many
years and many people have tried, and there appears to be millions of
dollars to be had for the first person to show up with this program,
why would you want to carve its existence in stone?

I don't see "research" as equivalent to "wishful thinking".


On June 26, 2003 at 17:23 research@solidmatrix.com (Yakov Shafranovich) 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.
 > 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

-- 
        -Barry Shein

Software Tool & Die    | bzs@TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

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