Re: [Asrg] [ASRG] SMTP pull anyone?

Douglas Otis <dotis@mail-abuse.org> Fri, 28 August 2009 03:34 UTC

Return-Path: <dotis@mail-abuse.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 568913A6AFF for <asrg@core3.amsl.com>; Thu, 27 Aug 2009 20:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.859, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 jsTiIUgzYI2a for <asrg@core3.amsl.com>; Thu, 27 Aug 2009 20:34:13 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 93BC93A6892 for <asrg@irtf.org>; Thu, 27 Aug 2009 20:34:13 -0700 (PDT)
Received: from SJC-Office-NAT-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 69C88A9443E for <asrg@irtf.org>; Thu, 27 Aug 2009 23:23:23 +0000 (UTC)
Message-ID: <4A97156B.4030302@mail-abuse.org>
Date: Thu, 27 Aug 2009 16:23:23 -0700
From: Douglas Otis <dotis@mail-abuse.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20090826180601.79333.qmail@simone.iecc.com> <Pine.GSO.4.64.0908261605410.13418@nber5.nber.org> <F32F76CE-829D-4C8C-A3B8-E5C344C14292@blighty.com> <4A9601FC.1090607@nortel.com>
In-Reply-To: <4A9601FC.1090607@nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] [ASRG] SMTP pull anyone?
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: Fri, 28 Aug 2009 03:34:14 -0000

On 8/26/09 8:48 PM, Chris Lewis wrote:
> Steve Atkins wrote:
>
>> I see this asserted a lot, but I don't really see much in the way of
>> plausible arguments to back it up.
>>
>> If anything, some blacklist techniques are likely to be easier and
>> more effective on IPv6 than v4 for the obvious NAT / dynamic
>> assignment reasons.
>
> Frankly, I don't think anything that earth shattering will occur, even
> if ipv6 takes over completely.
>
> Undoubtably some techniques will work better, some about the same, and
> some won't work worth squat - they'll either evolve to work better, fade
> into meaninglessness, or just outright die.
>
> It's not as if it hasn't happened before. See much use of open relay
> DNSBLs anymore? Thought not.

Treating /64 (the network of an IPv6 addresses) as having the same 
reputation is destine for support issues when exceptions are needed for 
various legitimate services.

When establishing an IPv6 block list, once exceptions are made, 
retaining evidence for each of these exceptions removes any semblance of 
there being an upper limit on the number of IP addresses logged.  After 
all, bad actors will start wearing large snowshoes in exception ranges.

For IPv6 addresses to become first-class citizens of the email 
community, listing those that should be accepted rather those blocked 
represents perhaps the only scalable solution while using similar tools. 
  Using DKIM messages to request inclusion of a new domain can also 
assist in validating the servers.

Alternative solutions such as accessing a link returned to the domain 
might be used as well.  Nevertheless, DKIM should help reduce the 
validation steps needed, and could help prioritize and expedite 
inclusions requests.  Knowing the domain rather than just an IP address 
also allows more extensive correlations with prior abuses.

-Doug