Re: [Asrg] VPNs

Bill Cole <asrg3@billmail.scconsult.com> Sat, 04 July 2009 16:05 UTC

Return-Path: <asrg3@billmail.scconsult.com>
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 2CB053A69B7 for <asrg@core3.amsl.com>; Sat, 4 Jul 2009 09:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Level:
X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599]
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 k+GERh4EmLjo for <asrg@core3.amsl.com>; Sat, 4 Jul 2009 09:05:34 -0700 (PDT)
Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 114883A6959 for <asrg@irtf.org>; Sat, 4 Jul 2009 09:05:33 -0700 (PDT)
Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id CCA758E5A1F for <asrg@irtf.org>; Sat, 4 Jul 2009 12:05:35 -0400 (EDT)
Message-ID: <4A4F7DD0.4040404@billmail.scconsult.com>
Date: Sat, 04 Jul 2009 12:05:36 -0400
From: Bill Cole <asrg3@billmail.scconsult.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
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>
In-Reply-To: <4A43618A.6000205@tana.it>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] VPNs
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: 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: Sat, 04 Jul 2009 16:05:35 -0000

Alessandro Vesely wrote, On 6/25/09 7:37 AM:
> For example, assume someone trusts Gmail's egress filtering

I'll play along. It is certainly possible that for some recipients, the 
stream of mail from Google's sewer is cleaner than what I see...

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

I'm going to assume you don't mind an answer based on a common add-on to 
common MTA software: SpamAssassin hooked into Sendmail or Postfix via one of 
the multiple 'milter' packages that will do that. SA can be hooked into 
other MTA's as well and is a component in some commercially packaged 
spam-filtering appliances, so I think it is reasonable to consider it 
"typical" even it is technically is not an integral part of any MTA.

This is a situation where SPF is a useful tool. If I want to make sure that 
SpamAssassin never deems mail from a *@gmail.com address to be spam as long 
as it gets an affirmative SPF match (i.e. is coming from what Google says 
are its normal gmail.com outbounds) I would just add this to my local 
SpamAssassin config:

whitelist_from_spf *@gmail.com

SPF can handle well the problem of whitelisting the normal outbound paths 
for a complex mail system that isn't persistently congruent with a set of 
hosts whose FQDN's share a domain tail or a small number of networks with 
clean octet boundaries (e.g. a small number of /24 ranges). Most major MTA's 
can directly define trusted networks based on octet or CIDR notation and 
trusted domains based on verified client hostnames patterns, so in many 
cases of simpler sending systems whitelisting does not require SpamAssassin 
or other SPF-based mechanisms. For complex senders who have complex and 
dynamic outbound environments, refuse to publish SPF records, but do use 
DKIM (e.g. Yahoo) there is probably some way to use DKIM as the 
authentication that a message is coming from a system that you trust. I 
can't say how easy or hard that would be, since I've never seen enough 
marginal value in DKIM to bother with it.