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

Bill Cole <asrg3@billmail.scconsult.com> Fri, 03 July 2009 04:34 UTC

Return-Path: <asrg3@billmail.scconsult.com>
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 CBFEA3A6927 for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 21:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.682
X-Spam-Level:
X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599]
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 VMemINomRcL0 for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 21:34:11 -0700 (PDT)
Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 8298B3A67EA for <asrg@irtf.org>; Thu, 2 Jul 2009 21:33:42 -0700 (PDT)
Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 226C88E43E8 for <asrg@irtf.org>; Fri, 3 Jul 2009 00:33:56 -0400 (EDT)
Message-ID: <4A4D8A34.8000106@billmail.scconsult.com>
Date: Fri, 03 Jul 2009 00:33:56 -0400
From: Bill Cole <asrg3@billmail.scconsult.com>
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 <asrg@irtf.org>
References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <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>
In-Reply-To: <4A49C1DD.8020205@tana.it>
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-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: 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 04:34:12 -0000

Alessandro Vesely wrote, On 6/30/09 3:42 AM:
> Bill Cole wrote:
>> 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.
>
> At a first glance, this may seem a flaw in the rDNS/whois systems. Upon
> reconsideration, I realize I have no means to accept accountability for
> an IP address of mines, since SPF or CSV/CSA only convey authorization
> for using a name. In facts, we don't even have a term for "the
> accountable party related to an IP address".

See RFC1183, which defines the "Responsible Party" RR type (RP). It states 
that a RP record can be associated with any node in the DNS hierarchy, and 
of course in-addr.arpa is part of the DNS hierarchy.

RP records are rarely published, and their operational use is even rarer. In 
my experience, RFC1183 is referenced most frequently as a caution against 
expecting too much from the RFC process.

> Dave's Email Arch mentions an Originator as "accountable for the message
> content", but doesn't relate it to an IP address. Rfc5068 associates
> accountability after submission with traceability features of the MSA,
> apparently suggesting that the first relaying thereafter is from an IP
> which is (indirectly) accountable for the message content. Reasoning by
> induction on the hops, one may conclude that all relays using a
> smarthost are accountable: smarthosts require either IP/firewall
> configuration or authentication (assuming they are not open relays.)
> Accountability breaks at the MX-driven relay, often referred as "boundary".

My reason for citing the IP address is that the IP address of the immediate 
client is the only fact that a host acting as an MX can trust to any useful 
degree for every message offered to it. Absent a means of reliably and 
quickly identifying a responsible party from *any* legitimate client IP, the 
suggestion that every MUA might be its own MSA is irrelevant.

>> 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.
>
> Why is it partial?

Because all it does is narrow the population of legitimate MX clients to a 
set that are more likely to have some responsible party identifiable by some 
means. Yet at the same time, the responsible party for a outbound mail 
server handling mail from many ultimate originators may well simultaneously 
reject full responsibility for spam it transports and refuse to identify the 
ultimate originator. The best examples of this for me are the big freemail 
providers, all of whom seem to have shunned the entire notion of 
accountability.

> "Domain-level accountability" is a good approximation.

Only in a relative sense. In an absolute sense, it has proven rather poor.

All it takes for domain-level accountability to fail is a big enough domain.

 > However, a
> smarthost is not necessarily within the same domain (e.g. ukisp.com is
> not even in the same 1st level domain) or the same organization. How
> does accountability degrade through indirection? That is, would you
> trust an SMTP client the same if it relays on behalf of some other party?

Of course not.