Re: [Asrg] VPNs

Bill Cole <asrg3@billmail.scconsult.com> Thu, 02 July 2009 17:37 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 3DA2028C1ED for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 10:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Level:
X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 oWYMNj-SkYqA for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 10:37:05 -0700 (PDT)
Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 59C2928C162 for <asrg@irtf.org>; Thu, 2 Jul 2009 10:37:05 -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 561428E3D22 for <asrg@irtf.org>; Thu, 2 Jul 2009 13:37:17 -0400 (EDT)
Message-ID: <4A4CF04A.6010401@billmail.scconsult.com>
Date: Thu, 02 Jul 2009 13:37:14 -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> <20090629120826.GA6823@gsp.org> <4A49CFCC.7040802@tana.it>
In-Reply-To: <4A49CFCC.7040802@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: Thu, 02 Jul 2009 17:37:06 -0000

Alessandro Vesely wrote, On 6/30/09 4:41 AM:
[...]
> Thanks for confirming that. My feeling is that we are overloading IP
> numbers with an accountability functionality that doesn't belong there.

There's a strong reason for this: the immediate client IP is the one fact 
about *every* MX-driven attempt at message transport that the receiving MTA 
can know with very high certainty, even when the message is originated by 
someone who intentionally and maliciously tries to hide his identity.

Whether accountability *should* be tied to that one knowable fact is a 
philosophical question. As a practical matter, there has proven to be little 
choice. For some years early in the growth of spam, filtering techniques 
were applied and over time largely discarded or relegated to scoring systems 
which assumed that spammers would not falsify other elements of mail and its 
transport that should lead back to the ultimate originator or to someone who 
can identify and police the originator. Having run out of headers and 
transport features to check, we've developed new things like SPF and DKIM 
that are  harder to spoof but suffer from inadequate adoption to really fix 
a large part of the problem, much as the previous transport and content 
encryption and signing mechanisms have.