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

Douglas Otis <> Mon, 22 June 2009 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BED5B3A680C for <>; Mon, 22 Jun 2009 12:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.397
X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1VJAOY+xqlU2 for <>; Mon, 22 Jun 2009 12:04:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E03C23A6801 for <>; Mon, 22 Jun 2009 12:04:47 -0700 (PDT)
Received: from [IPv6:::1] ( []) by (Postfix) with ESMTP id 5B3C9A94439 for <>; Mon, 22 Jun 2009 19:05:01 +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, 22 Jun 2009 12:05:00 -0700
References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <> <> <> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <> <> <> <>
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, 22 Jun 2009 19:04:48 -0000

On Jun 22, 2009, at 7:12 AM, Ian Eiloart wrote:

> --On 21 June 2009 23:34:16 -0700 Douglas Otis <>  
> wrote:
>> SPF does not work well at resolving a domain that should be held  
>> accountable for a few reasons-
>>  a) risks high and impractical transaction overheads at attempts to  
>> indirectly reference the customers of a provider.
> Er, we already have ridiculous transaction overheads for email.  
> Anything that stopped spam would reduce the transaction overheads  
> for legitimate email by up to ten fold.

Only the application of reputation and address range policies reduces  
spam levels.  Not using SPF and instead using CSV will reduce the  
transaction overhead needed to validate an associated domain.  SPF  
often requires several transactions, that may exceed several hundred  
transactions where 111 could be generated by PRAs and then another 111  
for the Mail-From.   The high overhead problem of SPF can be made  
worse when the SPF records contain macros.  Using SPF macros, bad  
actors can cause recipients to generate a long series of different DNS  
transactions based upon portions of an email-address local-part, for  
example.  This enables a free DDoS attack while spamming, since SPF  
macros can make DNS caching ineffective.

>>  b) may not qualify any specific IP address for a positive result.
> I'm not sure what that phrase means. If it means that some lookups  
> result in softfail or neutral results, then that actually doesn't  
> matter much. The passes and the fails still get us useful  
> information. Anything else just puts us back where we were before.

An SPF pass result may never be based upon the IP address of the MTA.   
The way SPF is defined, there might not be a means to know whether an  
IP address check is bogus when resolving exists functions, for example.

>>  c) Mail From or PRA references do not resolve which domain  
>> administered the MTA or actually sent the message.
> It doesn't matter. If the domain owner devolves responsibility to  
> the IP address owner, then the mail is effectively from the domain  
> owner, and they can be held responsible for their email. Reputation  
> services, and the law can be applied as appropriate.

You have this the wrong way around.  SPF devolves responsibility to  
that of the email-address domain owner from that of the provider.  Any  
conclusions about email origination based upon authorization is purely  
speculative.  It would be wrong,  perhaps even risky, to conclude a  
message originated from a domain offering MTA authorization.

>>  d) holds customers of a provider accountable for the provider's  
>> stewardship without any solid evidence of their involvement.
> Please expand, I don't understand this either.

Providers are not required to assure any particular email-address  
domain within the Mail-From or that of some PRA is used exclusively by  
users of the email-address domain.  There may not be a relationship  
between the account used to gain access to an email providers'  
outbound MTA and the domain of SPF record authorizing the MTA.

>> There should be greater concern accountability is correctly applied.
> If the domain owners are feckless, then apply sanctions.  
> Accountability HAS to lie with domain owners if you want to  
> establish reputation services based on domain names, and most people  
> do want to do that. If the domain owner is found to be feckless,  
> then reputation sanctions should be applied.

CSV better ensures the domain providing access is held accountable.   
Accountability is normally applied against the IP address of the MTA.   
SPF's attempt at holding Mail From or the PRA domains accountable  
subverts the often intended use of SPF as a means to mitigate  
backscatter.  It would be foolish to assume SPF assigns who is  
accountable for having originated a message.