Re: [Asrg] VPNs vs consent

Claudio Telmon <claudio@telmon.org> Mon, 29 June 2009 16:04 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 DC5353A6DE7 for <asrg@core3.amsl.com>; Mon, 29 Jun 2009 09:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Level:
X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 TR503XeAsLUm for <asrg@core3.amsl.com>; Mon, 29 Jun 2009 09:04:26 -0700 (PDT)
Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id 9B8933A6DDB for <asrg@irtf.org>; Mon, 29 Jun 2009 09:04:25 -0700 (PDT)
Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+uKqYI0quQ0; Mon, 29 Jun 2009 18:04:22 +0200
Message-ID: <4A48E605.5080507@telmon.org>
Date: Mon, 29 Jun 2009 18:04:21 +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: <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> <4A48DFCF.9080305@mines-paristech.fr>
In-Reply-To: <4A48DFCF.9080305@mines-paristech.fr>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] VPNs vs consent
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: Mon, 29 Jun 2009 16:04:27 -0000

Jose-Marcio Martins da Cruz wrote:
> 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 !
> 

I'm just saying that RFC 2142 are not meant to be consent-enabled.
Anybody should be able to contact these addresses, but:
- other (antispam) protections may well be enabled;
- other shared addresses may be meant to be "for closed groups" or
consent-enabled

>> 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.

This is a very interesting case. I'll have to think at the implications
of it.


-- 

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