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

Douglas Otis <> Fri, 03 July 2009 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A2303A6C6A for <>; Fri, 3 Jul 2009 09:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.938
X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Z4anBkC8YQb for <>; Fri, 3 Jul 2009 09:51:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B53F528C16D for <>; Fri, 3 Jul 2009 09:51:46 -0700 (PDT)
Received: from [IPv6:::1] ( []) by (Postfix) with ESMTP id B2F15A945FA for <>; Fri, 3 Jul 2009 16:52:09 +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: Fri, 3 Jul 2009 09:52:09 -0700
References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <> <> <> <> <> <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: Fri, 03 Jul 2009 16:51:48 -0000

On Jul 3, 2009, at 4:48 AM, Alessandro Vesely wrote:

> Douglas Otis wrote:
>>> In general an MTA provides a FQDN like, and we are  
>>> unable to say whether it "is a member of" In  
>>> addition, the MTA's administrator may be unrelated to  
>>>'s registrant.
>> 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.  CSV ensures this relationship can be  
>> established [...]
> That is not the case. The hostmasters at can  
> unilaterally delegate the way they wish, with no  
> obligation whatsoever to run a whois service or otherwise publish  
> data about their delegate's admins, if any, let alone taking  
> accountability for what such admins would do.

The goal is to establish stable and fair identifiers.  Once a direct  
DNS relationship with that of a host can be verified, this serves as a  
identifier controlled by _some_ administrator.  Verification of a DNS  
relationship allows negative host stewardship assessments to be fairly  
made based upon the identifier.  A fair and stable identifier is being  
sought.  Not one that represents some person.  Anonymous tokens help  
avoid claims of individual censorship.  The application of host  
stewardship assessments can allow spam to be effectively and  
efficaciously managed, and is how accountability can be established.

>> Outbound MTAs can be unrelated to where their mail is received.   
>> Even so, port 25 of the NAT can be nailed to a host within the  
>> NAT's private address space.  Outbound MTAs behind a NAT is fairly  
>> common in office environments.
> Yeah, I used to suggest that setting myself, since most of (legit)  
> mail traffic is intra-office. They may collect external mail running  
> cron-scheduled POP clients. However, with today's connections and  
> legit mail being a tiny fraction of mail traffic, I see no reason  
> for keeping those servers. I regard them as historical settings, and  
> recommend using SUBMIT+IMAP on secured channels.

Those with a DS3 serving their office network may expect they have an  
ability to publicly send email to other domains.

>> With EHLO and a history of that host name [...]
>> From a reputation perspective, the name and IP address  
>> relationships that need to be tracked for Outbound MTAs represent  
>> data sets orders of magnitude smaller and dramatically more stable  
>> that that represented by MAIL commands or PRAs.
> However, one year after changing the IP address of my MTA, many MX  
> receivers are not yet up to date. I'll have to manually update that,  
> where possible, taking into account each domain idiosyncrasies. It  
> is so because those name-address relationships are still too many.  
> If you consider only the right hand side (RHS) of MAIL or PRAs,  
> you'll get much smaller figures.

Dependence upon just the domain of MAIL commands or PRAs would be  
vulnerable to exploitation.  Assertions that authorizations offer  
authentication are not safe.   In addition, there are hundreds of  
millions of MAIL command or PRA domains to be tracked, white there is  
about two to three orders of magnitude fewer EHLO domains.  A mistake  
made with a MAIL command or PRA domain will create serious and  
irreconcilable problems for the domain.  A mistake made with a EHLO  
host is both less likely, and will be far less catastrophic since  
services elsewhere can be sought.  In addition to being safer, more  
accurate, EHLO assessments are more efficacious and effective.  There  
are fewer in which to deal with, and this instills a hierarchy of  
management that better confronts rampant abuse largely caused by bot- 

>>> In case runs outbound MTA services for third  
>>> parties, I would hold the originating third party accountable for  
>>> the message.
>> Why not hold the entity offering access to those abusing email  
>> accountable?
> If they just offer a transport service, I see no reason I should.  
> Vice-versa, if they are accountable, then _they_ are the true MTA,  
> transmitting on behalf of what I called a vanity domain. (This  
> distinction does not have to be static, as example.ORG may send  
> directly in some cases, via in others.)

Those offering the service should still be assessed upon their  
stewardship of who is allowed to send messages.  When they fail to  
remove problematic access to their Outbound MTAs, those MTA might  
become blocked, and their customers will then need to seek service  
elsewhere.    When a MAIL command or PRA domains are blocked for  
because authorization has been confused with authentication or when  
spam is spoofing the domain, those affected are left without  
recourse.  Not wanting to track dramatically fewer EHLO host names  
with that of a small number of IP addresses is poor justification for  
a potentially injurious practice making guesses about MAIL commands or  
PRA domains. :^(

>> You have no assurance whether third-party domains originated the  
>> message, even when the domain offers authorization.  This assumes  
>> Outbound MTAs ensure both the PRA and MAIL commands are restricted  
>> to specific and verified users.  While this might be the case, this  
>> is not the norm.
> OTOH, if we cannot spot whether an MSA has been used, the advantages  
> of clean transmission remain confined within the first hop. An MTA  
> who accepted to relay on behalf of an authenticated user may be  
> willing to take accountability. The point is that it has no verb to  
> express that will.

IMHO, systems used within private or authenticated exchanges is of no  
concern.  It is only the Outbound MTA sending messages to different  
domains on port 25 without authentication that needs management.   
Guesses about what might have occurred ahead of the Outbound MTA can  
be injurious to otherwise innocent domains.

>> It would also be foolish to annotate email as having been  
>> "authenticated" on the basis of Outbound MTA authorization for the  
>> same reason.  Large companies place a higher priority on their  
>> messages being received than ensuring authorizations do not expose  
>> exploits to bad actors.
> If they take accountability, then it's their problem. Their vouchers  
> should take that behavior into account.

Vouchers?  Taking accountability?  Logically extending that concept  
should then involve significant liabilities for providers that fail to  
ensure MAIL commands or PRAs are limited to their rightful owners.   
What RFCs should these providers be following?  How does one determine  
who is the rightful owner, and have you ever seen such agreements, and  
do you know which standards need to be followed?  Is this assurance  
expressed within your SLA with your provider?  Does this agreement  
specify exclusivity for use of MAIL commands or does it also include  
PRAs?  You are describing a fantasy that may cause injury when  
believed.  We need to hold parachute manufactures liable for their  
product, and not those using parachutes.

>>> However, there is no way I can tell that is indeed the case,  
>>> neither from the IP address nor from the name. I'd need, say, a  
>>> CSA SRV record from example.ORG saying: "we authorize  
>>>", _and_ on starting a new session the client shall  
>>> say: "Hello on behalf of example.ORG: check their CSA settings".  
>>> No guessing required, then.
>> Yes, the CSA record would help, but this EHLO information still  
>> offers value.  Especially when considering the use of IPv6 where  
>> block lists are unlikely to prove effective.
> I agree EHLO information has some value. In some cases, it may be  
> redundant (e.g. if there is a vouch, or in case of ideal DNS  
> settings.) In most cases, it is not enough, as it doesn't lead to an  
> accountable administrator's name, address, phone number, etc.

It only needs to lead to an identifier that can be fairly and safely  
blocked while mitigating email abuse.

>> The issue is simpler than that.  The issue is to simply hold the  
>> Outbound MTA accountable for the message sources for whom it grants  
>> access.  DKIM offers a reliable means to verify where a message  
>> originated without impractical and unscalable efforts aimed at  
>> registering all authorized paths for MAIL commands or PRAs.
> Both Outbound MTAs and DKIM offer no hint about a message's  
> Originator and related accountability issues.

The task of holding individuals accountable needs to be delegated to  
the Outbound MTA providers.  After all, these providers are being  
compensated, and not their recipients.  Expecting recipients to make  
guesses about who the originators were overlooks the reality that  
Outbound MTA provider granting access are the _only_ entities able to  
make this determination.  When they haven't or can't, they should be  
blocked when abuse is being emitted.

> For counting, note that the number of DKIM signers potentially  
> exceeds the number of valid RHS domain names, since each mail domain  
> can be a DKIM signer, but a DKIM signer doesn't have to be a mail  
> domain.

DKIM is to prevent spoofing.  DKIM is not intended to serve as a means  
to mitigate email abuse.

>> DNS CIDR notation is specified by RFC 3123.  This resource record  
>> can still be used to establish email white-list strategies instead  
>> of SPF records.   APL records exclude potentially problematic  
>> macros as well.  Since email CIDR records should not be obtained in  
>> response to SMTP connections, APL might be chained with a  
>> convention for _n._smtp APL, as an alternative publishing location  
>> for _smtp APL.  When _smtp is truncated, either TCP fallback could  
>> be used, or _[0-9]._smtp APL queries might be used to recover from  
>> response truncation.
> However well designed, such scheme will thickens the ranks of mail  
> transmitter authentication schemes. All of them are optional, and  
> checking which one may apply requires an increasing amount of DNS  
> transactions, possibly amplified by DNSSEC. That's why VHLO, besides  
> taking the mail domain of the accountable organization, can also  
> take the parameters indicating which authentication method applies.

This alternative for white-listing was mentioned only to suggest safer  
methods that don't rely upon potentially hazardous scripts.