Re: [Asrg] What are the IPs that sends mail for a domain?

der Mouse <mouse@Rodents-Montreal.ORG> Thu, 18 June 2009 01:05 UTC

Return-Path: <mouse@Sparkle.Rodents-Montreal.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 2E1523A69E3 for <asrg@core3.amsl.com>; Wed, 17 Jun 2009 18:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.779
X-Spam-Level:
X-Spam-Status: No, score=-9.779 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8]
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 mMsat4W9gaWG for <asrg@core3.amsl.com>; Wed, 17 Jun 2009 18:05:07 -0700 (PDT)
Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id E741E3A67D4 for <asrg@irtf.org>; Wed, 17 Jun 2009 18:05:06 -0700 (PDT)
Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id VAA21834; Wed, 17 Jun 2009 21:05:04 -0400 (EDT)
From: der Mouse <mouse@Rodents-Montreal.ORG>
Message-Id: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
Date: Wed, 17 Jun 2009 20:51:13 -0400
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org>
References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <Pine.GSO.4.64.0906161906450.27272@nber6.nber.org> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org>
Subject: Re: [Asrg] What are the IPs that sends mail for a domain?
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: Thu, 18 Jun 2009 01:05:08 -0000

> Factors that make managing an IPv6 block-listing service fairly
> impractical go beyond 96 additional address bits.

> 1) Publishing behavior based address lists require evidence
> collection in the event of disputes, and this does not scale well.
> (expensive)

I can't see why v6 versus v4 makes any difference at all to this.

> 2) IPv6 to IPv4 and IPv6 to IPv6 NATs obfuscates who might be
> involved.  (problematic)

I can't see why this is any worse than the v4-to-v4 NATs the net is
already full of.

> 3) Reverse DNS scanning does not scale well. (slow)

True.  DNSBLs that depend on rDNS scanning may die.  There are plenty
of DNSBLs, including some of the most useful, that do not.

> 4) Diverse and rapidly expanding address space allows bad-actor's
> activity to stay ahead of the massive amounts of IP address related
> information publishing.  (futile)

I see no real difference here between a v4 list that lists at the /32
level and a v6 list that lists at the /48 (or maybe even /64) level.

> 5) An extremely low cost for IP addresses allows bad actors to
> persist at sporadic use for many years.  (futile)

And this differs from v4...how?

> The collection of evidence is often constrained by the related
> identifier, such as the IP address.  Unfortunately, IPv6 allows a new
> IP address to be used for each message sent.

So, collect evidence at the /64, or even /48, level, rather than at the
individual address level.

Even to the extent that these problems are real, they are theoretical.
It certainly behooves us to think about them ahead of time, but absent
experience demonstrating that they are more than potential, I don't see
them as a reason to give up on v6 DNSBLs without even trying.

> Pushing responsibility to the edge does not work, and email provides
> ample evidence.

It's not that doing that has been tried and found wanting; rather, it
has not been tried.  (Actually, it has been tried in a limited way;
there are pieces of the net that _do_ push responsibility to the end
user.  Oddly enough, they are basically nonexistent as far as abuse
emitters go; what evidence I see indicates that it _does_ work.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B