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

Alessandro Vesely <> Sat, 20 June 2009 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AE923A6B60 for <>; Sat, 20 Jun 2009 12:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.636
X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xYGeB4-W1WNF for <>; Sat, 20 Jun 2009 12:20:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 761673A6A41 for <>; Sat, 20 Jun 2009 12:20:08 -0700 (PDT)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by with esmtp; Sat, 20 Jun 2009 21:20:15 +0200 id 00000000005DC031.000000004A3D366F.00001F44
Message-ID: <>
Date: Sat, 20 Jun 2009 21:20:14 +0200
From: Alessandro Vesely <>
User-Agent: Thunderbird (Windows/20090302)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
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> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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: Sat, 20 Jun 2009 19:20:09 -0000

Douglas Otis wrote:
> SMTP is heavily abused, and soon IPv6 is about to become a necessity.   
> To remain practical, connectivity must be based upon _immediate_ and 
> _stable_ evidence of legitimate email operation, and not upon any number 
> of authorization transactions.  Each additional transaction to support 
> an authorization scheme will be multiplied by the typical number of 
> attempts made by abusive senders.   This means providers need to exclude 
> problematic users, and not become a task pushed toward recipients.  Such 
> pushing is not practical and often leads to unfortunate mistakes.

What do you mean by "problematic users"? Providers of residential 
cables, WiMAX, and similar connections could block or redirect port 
25, just like most universities and companies do. They used to do it, 
as long as they provided mailboxes as a bonus and ISP and ESP were 
synonyms. Submission port 587 is not yet universally employed, and 
some customer may not accept to be unable to reach their favorite 
server's ports 25 or 465. "Blocking port 25 except for a set of 
servers used for submission" is not something that can be easily 
defined and maintained by ISPs, IMHO.

OTOH, sender identification by domain could also be a way to attribute 
responsibility. Strictly speaking, it is not necessary to use a domain 
in order to send as an SMTP client. However, in practice one needs an 
email address to do any legitimate use of SMTP, and hence a domain is 

>>> Schemes that pass accountability onto what might be feckless domain 
>>> owners are inherently evil.
>> I disagree, _provided_ accountability is actually passed on.


> The fact that a trusting and naive user had their domain authorize a 
> provider just to have their email accepted, does not mean other messages 
> emitted might not be mistaken as also belonging to that user's domain.  
> Should providers check for SPF or Sender-ID compliance?  How many SLA 
> include this requirement?  When the "passing-on" is based upon 
> receptions at spam traps, acceptance reliance based on "authorization" 
> is likely to downgrade acceptance of the domain, especially when A-R 
> headers exclude the IP address of the provider.  Will providers really 
> care the wrong entity had been blamed?

You can never know whether that domain's owners are really so foolish 
to trust a criminal provider, rather than participating accessories. 
Assuming their bad faith, one should downgrade acceptance of their domain.

>> What you appear to be thinking of is not accountability but mere 
>> identification (albeit moderately strong identification).
> Moderately strong?  Without knowing the IP address of the provider, it 
> would be extremely foolish to conclude any level of identification 
> assurance, especially "moderately strong".

IMHO, the domain registrants (resulting from whois records) provide an 
identification that is comparable in strength, but finer in granularity.