Re: [Asrg] VPNs vs consent

Jose-Marcio Martins da Cruz <Jose-Marcio.Martins@mines-paristech.fr> Mon, 29 June 2009 15:35 UTC

Return-Path: <Jose-Marcio.Martins@mines-paristech.fr>
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 9406828C13A for <asrg@core3.amsl.com>; Mon, 29 Jun 2009 08:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level:
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 sNahFPw1DrQ6 for <asrg@core3.amsl.com>; Mon, 29 Jun 2009 08:35:23 -0700 (PDT)
Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 9085B28C12C for <asrg@irtf.org>; Mon, 29 Jun 2009 08:35:23 -0700 (PDT)
Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n5TFZeuU015453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <asrg@irtf.org>; Mon, 29 Jun 2009 17:35:40 +0200 (MEST)
Message-ID: <4A48DFCF.9080305@mines-paristech.fr>
Date: Mon, 29 Jun 2009 17:37:51 +0200
From: Jose-Marcio Martins da Cruz <Jose-Marcio.Martins@mines-paristech.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 pango-text SeaMonkey/1.1.16
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <20090629113156.GA32258@gsp.org> <4A48BDAC.1060602@telmon.org>
In-Reply-To: <4A48BDAC.1060602@telmon.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Miltered: at boipeva with ID 4A48DF4C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 4A48DF4C.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/<Jose-Marcio.Martins@mines-paristech.fr>
Subject: Re: [Asrg] VPNs vs consent
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Jose-Marcio.Martins@mines-paristech.fr, 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: Mon, 29 Jun 2009 15:35:24 -0000

Claudio Telmon wrote:
> Rich Kulawiec wrote:
> 
>> A brief check of my own procmail config indicates that I'm on over 500 of
>> these -- the overwhelming majority of which are role addresses such as
>> those specified in RFC 2142.  A secondary check indicates that about 3/4
>> of those are shared with one or more other people, which means I'd have
>> to work out some kind of "shared consent" for several hundred addresses.
>> That's not feasible in a reasonable period of time, especially since
>> neither the addresses nor the pool of people they're shared with are static.
> 
> Well, I suppose that most of those mailboxes shouldn't be
> consent-enabled anyway. Addresses like "abuse" or "postmaster" are meant
> to be contacted by anybody that needs it, right? The same for the

No !

> official contact addresses of companies.

In fact, at our domain, few of these kind of adresses aren't protected. Most of them are 
adresses of the kind "everybody in the engineering department" (addresses which are of 
internal use only) "butterfly research workgroup" (a closed group working on some 
particular subject) and so. These are adresses which *are* protected and the concept of 
consent-enable is materialized by checking if the SMTP client sending messages to is in 
some known network or if the connection was authenticated. But nothing prevents that this 
kind of consent should be expanded. Either way, in an organisation like the ours, users 
couldn't understand that the same consent system used for individual addresses couldn't be 
used for collective addresses.