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

Douglas Otis <> Thu, 18 June 2009 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 607963A6911 for <>; Thu, 18 Jun 2009 16:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.372
X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eUzFV+-RYo-j for <>; Thu, 18 Jun 2009 16:01:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 936913A68FB for <>; Thu, 18 Jun 2009 16:01:24 -0700 (PDT)
Received: from [IPv6:::1] ( []) by (Postfix) with ESMTP id 416C6A94439 for <>; Thu, 18 Jun 2009 23:01:37 +0000 (UTC)
Message-Id: <>
From: Douglas Otis <>
To: Anti-Spam Research Group - IRTF <>
In-Reply-To: <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG>
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: Thu, 18 Jun 2009 16:01:36 -0700
References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <> <> <> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <> <200906182044.QAA05200@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: Thu, 18 Jun 2009 23:01:25 -0000

On Jun 18, 2009, at 12:19 PM, der Mouse wrote:

>> Have you heard of SPF?
> Yes.  It flopped, no?  If it had been widely adopted, I might have  
> to decide whether I think it constitutes "pushing responsibility to  
> the edge".  But I don't.

The answer to this question depends upon who is asked.  MTA vendors  
are further enabling use of this practice, often only offering an  
impression of security.  Avoiding accountability remains the siren  
song luring large providers.

>>> (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.)
>> Can you provide some specifics?
> I worked for McGill (a university in Montreal) for most of my  
> career, some 15 years, about 10 of those as postmaster for one of  
> the labs there.  Certainly we, and to the extent that I saw it the  
> rest of the University, imposed responsibility on end users.

This control is "out-of-band" from the abused protocol, and not the  
result of all recipients of the protocol resolving possible identities  
of each of university users.

> I am currently working for Openface Internet, an ISP in Montreal.  
> While it's done very differently (the provider/user relationships  
> are vastly different in the two contexts), we too push  
> responsibility for the user of the address space we grant our  
> customers to those customers.

The point attempted was to ensure providers are held accountable for  
their stewardship at handling abuse.

Schemes that pass accountability onto what might be feckless domain  
owners are inherently evil.  With SPF/Sender-ID, providers take the  
persona of their purported customer's domain.  Those describing SPF  
often erroneously suggest MTA authorization provides evidence a  
message originated from those providing the authorization.  Providers  
regulating their users is not what is being advocated by those  
promoting SPF/Sender-ID and advocating moving accountability to the  
edge.  Their desire is to have end recipients conducting many  
transactions to reveal an authorization, but not the one transaction  
that could have revealed the identity of the provider.  As such,  
providers can remain lax in their stewardship, and the end-point  
victim is expected to preform an ever growing number of transactions  
as the quantity of junk emails rise.

Providers MUST be held _directly_ accountable.  The financial debacle  
occurred when lenders avoided accountability by securitizing their  
service.  Avoidance of accountability provides evidence of regulation  
failure.  While service providers may advocate various schemes to  
avoid accountability, such schemes are doomed.  When they create  
innocent victims, they are evil.