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

"Claudio Telmon" <claudio@telmon.org> Thu, 25 June 2009 14:12 UTC

Return-Path: <64414253@ngi.it>
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 CF1CF3A6D6E for <asrg@core3.amsl.com>; Thu, 25 Jun 2009 07:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.406
X-Spam-Level:
X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.313, 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 HbORK8Z+Shdu for <asrg@core3.amsl.com>; Thu, 25 Jun 2009 07:12:25 -0700 (PDT)
Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 65DB03A682B for <asrg@irtf.org>; Thu, 25 Jun 2009 07:12:25 -0700 (PDT)
Received: from ::ffff:212.234.174.167 ([::ffff:212.234.174.167]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:212.234.174.167+Aco6R58FJ; Thu, 25 Jun 2009 16:11:34 +0200
From: "Claudio Telmon" <claudio@telmon.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
X-wmSenderIP: 212.234.174.167
Message-ID: <212.234.174.167.138736292.1245939094@webmail.inet.it>
In-Reply-To: <4A43618A.6000205@tana.it>
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>
Date: Thu, 25 Jun 2009 14:11:34 +0000
X-Mailer: NGI Webmail
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [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: claudio@telmon.org, 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 14:12:26 -0000

> Da: Alessandro Vesely <vesely@tana.it>

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

It's not clear to me if you're asking how the consent framework would deal with the problem, but I can tell you.
Suppose that Gmail implements the consent framework in their MUAs. Then, MTAs could whitelist Gmail with respect to the consent framework. Let's see what it means to example.com's incoming MTA.
1. user1@example.com is not consent-enabled. Then the framework is not used, and nothing relevant happens, mail if acceptet/rejected as it currently is.
2. user2@example.com is consent-enabled, and a message arrives with proper headers/tokens; then, the framework is deployed and the message is accepted/rejected based on tokens (and some other usual controls), whitelisting is not relevant
3 user2@example.com is consent-enabled, a message without tokens arrives from address@gmail, and gmail is whitelisted; in this case:
- user2@example.com expressed the will to enable the framework;
- address@gmail can use the framework, since gmail is whitelisted, so the sender MUA implements the framework;
- however, the message has no proper token; this means that user2 didn't provide a token to the sender, and the message can be safely rejected, with no need to other controls
This way, nobody can send messages to user2@example.com with a forged address from any gmail address (unless the attacker manages to get a token from a user2's gmail correspondent). So, implementing the framework could be of some interest e.g. to banks, since accessing their token should be hopefully hard
4 user2@example.com is consent-enabled, a message without tokens arrives from address@gmail, and gmail is not whitelisted;
In this last case, we don't know if the message is without token because the token was not provided, or because the gmail MUA doesn't implement the framework and thus the token cannot be inserted in the message. It's up to the receiver to decide if the message sould be rejected, or handled as if user2 were not consent-enambled (that is, go through the usual checks), which is what would probably happen at least until the framework were widely implemented.
In any case, no work is required to the sender MTA, the sender domain/organization is only required to implement the framework support in the MUA


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