[Asrg] VPNs (was: request for review for a non FUSSP proposal

Alessandro Vesely <vesely@tana.it> Thu, 25 June 2009 12:59 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id BE2143A6ECB for <asrg@core3.amsl.com>; Thu, 25 Jun 2009 05:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.575
X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id LHq1Z245+Qa3 for <asrg@core3.amsl.com>; Thu, 25 Jun 2009 05:59:21 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it []) by core3.amsl.com (Postfix) with ESMTP id E05FD3A6CDC for <asrg@irtf.org>; Thu, 25 Jun 2009 05:59:20 -0700 (PDT)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 25 Jun 2009 13:37:46 +0200 id 00000000005DC02F.000000004A43618A.00005B4F
Message-ID: <4A43618A.6000205@tana.it>
Date: Thu, 25 Jun 2009 13:37:46 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird (Windows/20090605)
MIME-Version: 1.0
To: Jose-Marcio.Martins@mines-paristech.fr, 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>
In-Reply-To: <4A426B9D.7090901@mines-paristech.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Asrg] VPNs (was: 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: Thu, 25 Jun 2009 12:59:24 -0000

Jose-Marcio Martins da Cruz wrote:
> Ther's a big difference between VPNs and consent.
> VPNs are really private - information about VPNs instances (IP address 
> of entry points, protocol, flavour, ...) aren't public and aren't 
> available to unknown users.

They are available to allowed users (nearly) transparently. Once it is 
properly setup, users can run "internet" software that uses the 
existing connection --obviously including SMTP.

> Consent users information is public : Claudio Telmon email address is 
> public and known by everybody.

However, it is not enough to set up consent at the local server. Each 
user has to take care of tokens management in order for it to work. 
That's one way that consent pushes the problem to users.

AFAIK, there is no way SMTP can be configured so that a given sending 
location can be whitelisted. One can try and detect what MTA sends the 
message and whitelist specific filters, presumably doing detection by 
the IP address of each mailout. That's much like VPN: being at a 
higher level doesn't ease the task. For example, assume someone trusts 
Gmail's egress filtering and wants to skip content filtering for mail 
coming from there. What work is required to accomplish (and maintain) 
that task, on typical MTA software?