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

Bill Cole <> Mon, 29 June 2009 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07C1F28C251 for <>; Mon, 29 Jun 2009 11:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S4RnGl5U0laR for <>; Mon, 29 Jun 2009 11:49:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5EAEA3A6AF1 for <>; Mon, 29 Jun 2009 11:49:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 80F688E0A25 for <>; Mon, 29 Jun 2009 14:49:41 -0400 (EDT)
Message-ID: <>
Date: Mon, 29 Jun 2009 14:49:41 -0400
From: Bill Cole <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
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=UTF-8; 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
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Jun 2009 18:49:29 -0000

David Nicol wrote, On 6/20/09 7:06 PM:
> On Sat, Jun 20, 2009 at 2:20 PM, Alessandro Vesely<>  wrote:
>> However, in practice one needs an email address to do any legitimate use of
>> SMTP, and hence a domain is required.
> There isn't any technical reason why MUA software can't do its own
> delivery with today's technology.  The whole concept of "outbound MTA"
> seems like a throwback. With the exception of delivery delays, but
> having a MUA attempt its own delivery and then switch to the smarthost
> on connection or other temporary failure wouldn't require any
> inspiration.

Injecting a concrete fact into the scholastic debate...

The original Eudora (before it became an alpha-quality extension for a beta 
version of Thunderbird) had such functionality going back at least to the 
early 90's. That was not an expression of any sort of advanced modern 
technology, but rather a necessity for the early days of putting a MUA on a 
personal system instead of on a shared system with its own local submission 
and queuing system.

The reasons that younger MUA's do not offer that are social, not technical. 
It has never been particularly difficult technically for a MUA to work 
without a smarthost/MSA, but for the past decade it has been increasingly 
difficult because receiving systems have become less trusting of random 
strangers as clients. It is empirically useful for a receiving system to 
assume that mail offered via SMTP from an IP that is being used by a 
personal computer without useful sender authentication (which might be "this 
IP is on my network") is some variety of spam.

The "outbound MTA" (or more properly: MSA) is not a throwback, but a 
relative novelty. Hypothesizing its elimination without a model for 
eliminating the preconditions that led to it being a standard part of how 
people use mail is pointless. Those preconditions are:

1. There is no working global mechanism for identifying an accountable party 
(i.e. one who explicitly *accepts* accountability) from an IP address, due 
largely to the political and historical variations in how IP addresses have 
been allocated.

2. A large fraction of users who have theoretical control over the traffic 
coming from a public IP address do not have the requisite understanding of 
their own systems and how they use those systems to be accountable for the 
traffic generated by them.

Funneling email through MSA systems run by providers that in principle have 
some means of holding their users accountable and are capable of at least 
understanding bad behavior in mail if not always keeping it controlled is 
the best partial workaround we have, and it implies the need for 
domain-level accountability or its equivalent. The fact that other models 
could work technically is not relevant unless they come with strong 
mechanisms to work around those social gaps.