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

Douglas Otis <> Thu, 18 June 2009 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB7BE3A6ECF for <>; Wed, 17 Jun 2009 17:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.342
X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5cMNJz-XCr-p for <>; Wed, 17 Jun 2009 17:18:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 14D573A6EAD for <>; Wed, 17 Jun 2009 17:18:28 -0700 (PDT)
Received: from [IPv6:::1] ( []) by (Postfix) with ESMTP id ED0FDA94439 for <>; Thu, 18 Jun 2009 00:18:32 +0000 (UTC)
Message-Id: <>
From: Douglas Otis <>
To: Anti-Spam Research Group - IRTF <>
In-Reply-To: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 17 Jun 2009 17:18:32 -0700
References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <> <>
X-Mailer: Apple Mail (2.935.3)
Subject: Re: [Asrg] What are the IPs that sends mail for a domain?
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jun 2009 00:18:30 -0000

On Jun 17, 2009, at 7:59 AM, Steve Atkins wrote:
> On Jun 16, 2009, at 4:17 PM, Daniel Feenberg wrote:
>> Because it would be impossible to maintain a DNSBL for IPV6,
> I keep hearing people say this, but I've not seen any clear  
> justification for it. It seems to me to be no more difficult to run  
> a blacklist for IPv6 addresses than IPv4 addresses (neither is easy,  
> but the details of the address representation don't seem to make  
> more than minor differences).
> Can you expand on why you think it's the case, or point me at some  
> discussion of it?

Factors that make managing an IPv6 block-listing service fairly  
impractical go beyond 96 additional address bits.  The term  
impractical is used because, with enough money, anything is possible.

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

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

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

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)

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

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.  Some countries already  
place thousands of MTAs behind carrier grade NATs.  Any scheme that  
concludes the use or abuse of an IP address indicates which individual  
originated a message makes it ill-equipped to deal with today's  
evolving network environment.  Block-listing must soon be replaced by  
acceptance-listing.  Things like CSV would permit a means to  
consolidate the sources managed by acceptance-lists, where reputation  
could be based upon MTA domains, rather than a vast array of IP  
address or the domains controlled by their customers.

With email so heavily abused, attempting to acquire and process the  
ten to two hundred SPF transactions per message is not possible at  
today's magnitude of abuse per legitimate message.  SPFs use of macros  
and exists functions requires a process done in conjunction with  
message acceptance, while at the same time placing DNS itself in  
peril.  Any strategy that attempts to place the customers of an email  
provider responsible simply does not scale as an abuse deterrent.   
Management efforts can be reduced a million fold when directly holding  
the immediate outbound public MTA accountable, rather than attempting  
to shift accountability toward one of a provider's many users, which  
is the real (and admitted) motivation behind SPF/Sender-ID/A-R.  This  
Nast cartoon depicts the situation fairly well by changing the  
question to asking who is responsible for email's dire situation and  
having the men in the circle represent that of the providers.,_Nast.jpg

Pushing responsibility to the edge does not work, and email provides  
ample evidence.  This nonsense is putting the Internet itself in peril.