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

Claudio Telmon <claudio@telmon.org> Wed, 01 July 2009 10:32 UTC

Return-Path: <claudio@telmon.org>
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 E81213A68A1 for <asrg@core3.amsl.com>; Wed, 1 Jul 2009 03:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.12
X-Spam-Level:
X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 RkqLj4pHBvyz for <asrg@core3.amsl.com>; Wed, 1 Jul 2009 03:32:28 -0700 (PDT)
Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id 67B953A67F3 for <asrg@irtf.org>; Wed, 1 Jul 2009 03:32:28 -0700 (PDT)
Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+l998Q87rci1; Wed, 01 Jul 2009 12:32:48 +0200
Message-ID: <4A4B3B50.4030705@telmon.org>
Date: Wed, 01 Jul 2009 12:32:48 +0200
From: Claudio Telmon <claudio@telmon.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666
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> <4A44F103.7010608@tana.it> <11FD07CCCE54CCC7FB8A2513@lewes.staff.uscs.susx.ac.uk> <4A48958D.7020701@tana.it> <4A489A75.7060005@telmon.org> <4A48C3BC.90501@tana.it>
In-Reply-To: <4A48C3BC.90501@tana.it>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
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: Wed, 01 Jul 2009 10:32:36 -0000

Alessandro Vesely wrote:

> Well, having to collect agreements for data processing from each subject
> is one of the most annoying applications of EU privacy directives. It is
> as when one says: "May I ask you XYZ?" And the other one replies: "Yes,
> you already did!" For email, it is possible to avoid that _that kind_ of
> consent requests become entries in the recipient's INBOX. One way to do
> so, considering multi-destination delivery a kind of forwarding (see
> sec. 3.9 of rfc5321), is being tentatively described at
> http://fixforwarding.org/.
> 

Maybe I don't understand. If you manage to setup and agreement, then you
have an existing relationship with the sender/forwarder, and this solves
most of the problems, it's just a matter on how to "authenticate". If
you don't, then everything will start with the sender/forwarder
contacting you for permission, and you acting as a consequence. While
this may be annoying for the sender, it is a way the receiver can have
some control on incoming messages. Also, this forces the sender in being
"convincing" in its request, instead of just being aggressive with
advertising. The fact is, these procedures are usually discussed from
the perspective of companies that must ask for permission (to contact
unknown people with their commercial proposals), and not from the
perspective of citizens that can deny this permission. But the goal of
the directive is to protect the citizens from aggressive commercial
practices; while providing a mean to contact people anyway is also a
goal, it is a much less critical one.

>> But the problem is, spammers won't be that polite, not even in Europe
>> with our EU Directive :) So you will need to find a way to enforce
>> compliance with this requirement for your address, that is, a way for
>> the MTA to know who you authorized...
> 
> It may be enough to provide a convenient way to do it, without enforcing
> it with blocking policies.
> 

The main problem I see with this framework, is that it seems to require
the cooperation of every step between sender and receiver, and the
intermediate steps taking some responsibility for what they are
forwarding. Is it because of this that there was some discussion about
smtp still being store and forward? However, I still prefer a more
end-to-end approach.


> While it seems self-evident that spammers are exempted from complying
> with anti-abuse message sender common practices, many careful senders
> may be classified as spammers according to the MRDW acceptation of the
> term spam. "Spammers" of the latter kind are sensible to reputation
> concepts and make a good faith effort to comply with common practices,
> because they reason that going along with prospects' desires is more
> remunerative than loosing their own reputation on questionable deeds.

Well, my feeling is that good faith spammers are mostly unaware of good
practices, the same way they are unaware of laws. Also, while some
technical people may be willing to deal with good practices, marketing
people may just count the complaints/sales ratio. And they usually rule ;)

-- 

Claudio Telmon
claudio@telmon.org
http://www.telmon.org