Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)

Alessandro Vesely <vesely@tana.it> Fri, 26 June 2009 16:02 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2951A3A6BBF for <asrg@core3.amsl.com>; Fri, 26 Jun 2009 09:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.147
X-Spam-Level:
X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZesedgzdbsQ5 for <asrg@core3.amsl.com>; Fri, 26 Jun 2009 09:02:05 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id EB2933A697E for <asrg@irtf.org>; Fri, 26 Jun 2009 09:02:04 -0700 (PDT)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 26 Jun 2009 18:02:11 +0200 id 00000000005DC030.000000004A44F103.00003065
Message-ID: <4A44F103.7010608@tana.it>
Date: Fri, 26 Jun 2009 18:02:11 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <4A44A90A.9090503@tana.it> <20090626140320.B0C8C24300@panix5.panix.com>
In-Reply-To: <20090626140320.B0C8C24300@panix5.panix.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 16:02:06 -0000

Seth wrote:
>> UBE is still better than "the class of Messages which the Recipient 
>> wishes to prevent from ever being presented with." In particular, it 
>> allows to determine a message's spaminess *on sending*.
>
> Definitionally, yes.  Effectively, no.  There's no way for anyone 
> other than the sender (e.g. the sender's ISP) to determine that I 
> asked someone I met at a party last week to send me some information 
> by email.  (Sure, they could ask me; but I _didn't_ solicit that.)

Likewise, a recipient's ESP has no way to determine what the recipient 
_wishes_. Even asking may result in ambiguous answers, possibly 
affected by unexpected unconscious evocations. In addition, to surmise 
that a recipient's wishes can be partitioned into classes according to 
some standard is beyond any residual trace of objectivity. When 
interpreted operatively, it calls for inconsistent behavior -which 
indeed is what we currently have.

Even if we may be skeptical about the effectiveness of meatspace laws 
for limiting spam, we should give them credit for defining and 
describing a number of useful terms. Privacy laws are aimed at 
protecting people against undiscriminated usage of collected 
personally identifiable information, a.k.a. personal data. For 
example, European privacy directives' definitions[1] don't use the 
term "spam", but pin unauthorized usage of email addresses. 
Technically, UBE is covered in section 6.2 of rfc5321, loosening up on 
delivering or bouncing. According to privacy criteria, it should be 
covered in section 3.9, which is where the lists of addresses come 
into play. Is that the difference between coping and fixing?

[1] http://www.cdt.org/privacy/eudirective/EU_Directive_.html#HD_NM_28