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

Alessandro Vesely <vesely@tana.it> Fri, 03 July 2009 11:48 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9CB3A6CCF for <asrg@core3.amsl.com>; Fri, 3 Jul 2009 04:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.314
X-Spam-Level:
X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=1.805, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzJWE6GTL79W for <asrg@core3.amsl.com>; Fri, 3 Jul 2009 04:48:05 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 9A0713A68EA for <asrg@irtf.org>; Fri, 3 Jul 2009 04:48:04 -0700 (PDT)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 03 Jul 2009 13:48:23 +0200 id 00000000005DC031.000000004A4DF007.00006EC3
Message-ID: <4A4DF007.6070909@tana.it>
Date: Fri, 03 Jul 2009 13:48:23 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <C8F0F10E-E1A4-4D25-AF20-31E3F0DB68DF@mail-abuse.org> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <FED77586-8800-4BA6-99EA-30A1D9C089B6@mail-abuse.org> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <B5252B96-F0AB-4D4A-A0DA-8314AA8E038F@mail-abuse.org> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <CA9E386E-44BA-4E3B-8A91-A99B07393BA0@mail-abuse.org> <4A4CCC56.8090804@tana.it> <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org>
In-Reply-To: <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org>
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-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2009 11:48:06 -0000

Douglas Otis wrote:
>> In general an MTA provides a FQDN like mta.example.com, and we are 
>> unable to say whether it "is a member of" example.com. In addition, 
>> the MTA's administrator may be unrelated to example.com'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 example.com can unilaterally 
delegate mta.example.com 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.

>   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.

> With EHLO mta.example.com 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.

>> In case mta.example.com 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 example.com in others.)

> 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.

>  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.

>> 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 mta.example.com", _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.

>   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.

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.

> 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.