Re: [Asrg] VPNs vs consent

Jose-Marcio Martins da Cruz <Jose-Marcio.Martins@mines-paristech.fr> Thu, 25 June 2009 15:23 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 CC2E63A6A0C for <asrg@core3.amsl.com>; Thu, 25 Jun 2009 08:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6]
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 nBIhrHny84PL for <asrg@core3.amsl.com>; Thu, 25 Jun 2009 08:23:09 -0700 (PDT)
Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 361563A68C8 for <asrg@irtf.org>; Thu, 25 Jun 2009 08:23:08 -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 n5PFKQgJ025715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 17:20:26 +0200 (MEST)
Message-ID: <4A439639.9090106@mines-paristech.fr>
Date: Thu, 25 Jun 2009 17:22:33 +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 SeaMonkey/1.1.16
MIME-Version: 1.0
To: claudio@telmon.org, 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> <212.234.174.167.1726486840.1245941890@webmail.inet.it>
In-Reply-To: <212.234.174.167.1726486840.1245941890@webmail.inet.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Miltered: at boipeva with ID 4A4395BA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 4A4395BA.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: Thu, 25 Jun 2009 15:23:09 -0000

Claudio Telmon wrote:

> 
> If you mean by shared consent that all receivers must agree on consent, I think it can' t be done in a usable way. However, shared addresses usually mean that the consent of one of the receivers suffices. Then, from a technical perspective, it can be partially done. Anybody can distribute tokens for the address, and upload them to the MTA database. Since it is the MTA database that matters for filtering, messages will be properly accepted/rejected. Should a token need to be invalidated, any of the receivers should be able to do it, even if the token is not in his7her address book, again because its the token on the MTA that matters. However, they will need to cooperate in order to understand e.g. whose system has been compromised, since only one will probably have associated the token to an address. 
> The main problem is, probably only one of the receivers will have a proper token for answers, unless some shared repository is implemented. I didn't consider this issue.
> 

This is something which appear in other situations too : like users preferences management 
(enable filtering, filtering threshold, ... to name some of them).

You can't do any inference about what to do : unanimity, majority, one win, ...

Eventually, the border SMTP gateway just know that an address rcpt@domain.com shall be 
routed to rcpt@dept.domain.com, but rcpt@dept.domain.com will be expanded into a dozen 
address, when reaching the mailserver of dept.domain.com (which aren't known from the 
border gateway).

The other problem I mentioned is multiple addresses (jose-marcio.martins_da_cruz, 
jose-marcio.martins, martins, ...). I can't imagine managing preferences for each 
identity, nor a system telling that each address is equivalent to some other one, in a 
domain with, say, 10000 or more users.

Unless you're able to build an "usine à gaz" (as we say in France), with preferences for 
each valid address, there isn't a clean solution.