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

Douglas Otis <> Mon, 06 July 2009 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56C6E28C417 for <>; Mon, 6 Jul 2009 12:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.394
X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P4imNsQsZZdA for <>; Mon, 6 Jul 2009 12:08:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5896A28C429 for <>; Mon, 6 Jul 2009 12:08:00 -0700 (PDT)
Received: from [IPv6:::1] ( []) by (Postfix) with ESMTP id 89A88A944A8 for <>; Mon, 6 Jul 2009 19:00:24 +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: Mon, 6 Jul 2009 12:00:24 -0700
References: <> <> <> <> <> <20090630200150.GL57980@verdi> <> <> <> <> <>
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: Mon, 06 Jul 2009 19:08:24 -0000

On Jul 5, 2009, at 6:56 AM, Peter Koch wrote:

> Doug,
> On Thu, Jul 02, 2009 at 12:43:53PM -0700, Douglas Otis wrote:
>> When the EHLO host name references IP addresses that match the   
>> Outbound MTA, this verifies there is a common administration  
>> between the FQDN and DNS.
> the DNS namespace is of very little help when it comes to  
> conclusions about "common administration".  See, for example, RFC  
> 5507, section 4:
>  DNS hierarchy neither follows nor implies administrative  
> hierarchy.   Because of that, it cannot be assumed that data  
> attached to a node in   the DNS tree is valid for the whole subtree.  
> [...]
> Since I'm sure you were already aware of this, I'm wondering in what  
> way I might have misread your statement.

It would appear so.

Confirming a host name matches its published IP addresses does not  
extend either up or down the administrative name tree hierarchy.

Address records would be at a specific host name where a relationship  
with the host name and published address records is being confirmed.

The CVS/CSA records authorize _specific_ outbound SMTP servers by its  
EHLO host name and IP address .  (As a transition scheme, a parent  
domains might assert child domain use of CSA records.   Even so, CSA  
records are required for each specific host name.)

This is not whether the host name of "" is within  
the same administrative control as that of "" email  
address.   Accountability is assigned to a specific outbound MTA host  
regardless of the MAIL and PRA domains issued.  Just as it would be  
wrong, based upon name alone, to extend administrative domain  
hierarchy, Outbound MTA authorization referenced from email-address  
domains will not confirm the originating domain.   As such, it would  
be wrong to assert origination or administrative accountably against  
higher level domains _or_ authorizing domains for abuse that might not  
have be within their administrative control.  Fairness and equity for  
administrative stewardship needs to be retained.  CSV/CSA retrains  
fairness when assessing administrative stewardship.

Assigning accountability based upon Outbound MTA domain SPF  
authorization referenced from either the MAIL command or the Purported  
Responsible Address (PRA) assumes the Outbound MTA has administrative  
control or that there are mechanisms in place protecting those  
offering the authorization.  There are no current standards nor common  
SLAs that protect those offering the authorization to their email  
service providers.

Basing acceptance upon Outbound MTA SPF authorization (referenced from  
MAIL commands or PRA domains) will force domains to accept  
accountability for actions likely beyond their administrative  
control.  Holding these domains accountable by way of SPF reputation  
assessments in many cases will be unfair and provide inequitable  
treatment.  Fairness requires those within administrative control are  
held accountable.