Re: [Asrg] VPNs

Alessandro Vesely <vesely@tana.it> Mon, 06 July 2009 10:34 UTC

Return-Path: <vesely@tana.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 370E328C275 for <asrg@core3.amsl.com>; Mon, 6 Jul 2009 03:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.681
X-Spam-Level:
X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=2.038, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 05VxgqFxoYrl for <asrg@core3.amsl.com>; Mon, 6 Jul 2009 03:34:47 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 30E0028C1E6 for <asrg@irtf.org>; Mon, 6 Jul 2009 03:34:47 -0700 (PDT)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 06 Jul 2009 12:35:10 +0200 id 00000000005DC031.000000004A51D35E.00005A09
Message-ID: <4A51D35E.70306@tana.it>
Date: Mon, 06 Jul 2009 12:35:10 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: 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> <4A4F7DD0.4040404@billmail.scconsult.com>
In-Reply-To: <4A4F7DD0.4040404@billmail.scconsult.com>
Content-Type: text/plain; charset=us-ascii; 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: 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, 06 Jul 2009 10:34:48 -0000

Bill Cole wrote:
>> 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...

Upthread, you also wrote that they "have shunned the entire notion of 
accountability". What do you see?

Of course, one cannot compare one of those freemail providers with a 
private mail domain, operated by skilled staff, where new accounts are 
added wittingly, used by an elite of cautious people who rarely catch 
viruses, if ever. In the latter case, you don't have to resort to 
statistics to measure the quality of messages.

The big four, much like connection providers' default mailers, have to 
operate some kind of surveillance on what their users send. I wonder 
if they have specific conventions or settings to relay mail from one 
to another, since that probably accounts for a large chunk of their 
traffic.

>> skip content filtering for mail coming from there. What work is required
>> to accomplish (and maintain) that task, on typical MTA software?
> 
> 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

That kinds of setting cleverly enable whitelisting by domain. However, 
compared to the VPN paradigm, that setting is unilateral. At Gmail, 
they don't now they're whitelisted.

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

Browsing docs[1], it seems that

   whitelist_from_dkim *@yahoo.com

should work similarly. Domain Keys (whitelist_from_dk) is the 3rd one 
of the three types of whitelist from authentication (whitelist_auth) 
that SA does. So, if a sender knows that you filter with SA, they may 
try all of them in turn, blindly.

[1 
http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Plugin_DKIM.html]