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

Rich Kulawiec <rsk@gsp.org> Mon, 29 June 2009 12:08 UTC

Return-Path: <rsk@gsp.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 34F2F3A6917 for <asrg@core3.amsl.com>; Mon, 29 Jun 2009 05:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.502
X-Spam-Level:
X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ljNDkVFSLoDw for <asrg@core3.amsl.com>; Mon, 29 Jun 2009 05:08:13 -0700 (PDT)
Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 59F6428C235 for <asrg@irtf.org>; Mon, 29 Jun 2009 05:08:13 -0700 (PDT)
Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5TC8WI1032433 for <asrg@irtf.org>; Mon, 29 Jun 2009 08:08:33 -0400 (EDT)
Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5TC3eua002269 for <asrg@irtf.org>; Mon, 29 Jun 2009 08:03:40 -0400 (EDT)
Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5TC8QIN006873 for <asrg@irtf.org>; Mon, 29 Jun 2009 08:08:26 -0400
Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5TC8QTZ006872 for asrg@irtf.org; Mon, 29 Jun 2009 08:08:26 -0400
Date: Mon, 29 Jun 2009 08:08:26 -0400
From: Rich Kulawiec <rsk@gsp.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <20090629120826.GA6823@gsp.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4A43618A.6000205@tana.it>
User-Agent: Mutt/1.5.18 (2008-05-17)
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: 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 12:08:14 -0000

On Thu, Jun 25, 2009 at 01:37:46PM +0200, Alessandro Vesely wrote:
> 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?

Yes, MTAs can be configured so that a given sending location -- that is,
IP address -- is whitelisted.  I do it all the time.  But it's not a
very good solution, and it doesn't scale.  Moreover, it's brittle: if the
sender's outbound mail server changes its address, then it stops working.
Conversely, if someone else acquires that server's previous address,
then it starts working for someone I didn't intend it to work for.

Level of work?  I think, roughly speaking, it's one or two lines of
configuration with most MTAs.  But (as I think you're pointing out) the
actual configuration itself isn't the issue: it's the time and effort
that it takes to figure out what should be in the configuration, and
then to maintain it.

---Rsk