Re: [Asrg] VPNs vs consent

Jose-Marcio Martins da Cruz <Jose-Marcio.Martins@mines-paristech.fr> Thu, 02 July 2009 10:44 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 604BC3A683A for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 03:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.206
X-Spam-Level:
X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 z-RIhB7WMDlC for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 03:44:21 -0700 (PDT)
Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 6766F3A67A4 for <asrg@irtf.org>; Thu, 2 Jul 2009 03:44:21 -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 n62AifwS016605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <asrg@irtf.org>; Thu, 2 Jul 2009 12:44:41 +0200 (MEST)
Message-ID: <4A4C901D.3010200@mines-paristech.fr>
Date: Thu, 02 Jul 2009 12:46:53 +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: 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> <4A439639.9090106@mines-paristech.fr> <4A4A879D.80008@telmon.org> <4A4B76C8.3080602@mines-paristech.fr> <4A4B8D9F.9000000@telmon.org> <4A4B8FA9.3080905@mines-paristech.fr> <4A4B9345.8060705@telmon.org>
In-Reply-To: <4A4B9345.8060705@telmon.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Miltered: at boipeva with ID 4A4C8F99.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 4A4C8F99.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, 02 Jul 2009 10:44:22 -0000

Claudio Telmon wrote:


> I know. However, this is the part of the framework that I see as least
> critical in terms of acceptance. Both the MUA and the MTA will need some
> add-on/patch/whatever in order to implement the protocol, so this part
> of the framework will come "with the patch".
> While I have a couple of ideas on how this could be accomplished, the
> MTA token database management issue is one of the two I'm still looking
> for comments, the other being whether it is true that spam in "small
> text messages" would be easier/lighter to deal with by antispam tools.

I'll take a deeper look into this (but I don't have enough time now).

I have the feeling that this is part of a larger problem which is how to inform a border 
SMTP gateway about caracteristics of final addresses in internal mail servers.

One example we were talking about is just what are the valid internal addresses which, 
with your needs for the consent framework, is a sub problem of the larger one.

For the problem of checking the validity of internal addresses (e.g.), there are many 
solutions, but none of them is perfect.

Maybe this problem could be taken out of your proposal and handled as a global one.