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

Alessandro Vesely <> Wed, 01 July 2009 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DC8E28C554 for <>; Wed, 1 Jul 2009 07:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dFDQb1N41eRu for <>; Wed, 1 Jul 2009 07:31:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A115A28C579 for <>; Wed, 1 Jul 2009 07:30:33 -0700 (PDT)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by with esmtp; Wed, 01 Jul 2009 16:20:13 +0200 id 00000000005DC030.000000004A4B709D.000057A8
Message-ID: <>
Date: Wed, 01 Jul 2009 16:20:12 +0200
From: Alessandro Vesely <>
User-Agent: Thunderbird (Windows/20090605)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <> <> <> <> <> <20090630200150.GL57980@verdi>
In-Reply-To: <20090630200150.GL57980@verdi>
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: Wed, 01 Jul 2009 14:31:49 -0000

John Leslie wrote:
>> In facts, we don't even have a term for "the accountable party related 
>> to an IP address".
>    Are you sure that's a useful concept?

Not at all. However, after noting that per-user accountability in the 
pgp/smime sense cannot be used for general email, the tendency seems 
to look after the IP address of the transmitters, much like pinching 
hackers on the fly is sometimes shown on the movies.

>    The CSV paradigm is that the operator of a MTA should exercise some 
> responsibility for what is sends. The HELO string identifies the MTA 
> (though not necessarily one string exclusively by one MTA), and the 
> DNS management for that domain-name string states whether that domain 
> exercises responsibility (and by automatic return of A)ddress RRs on 
> SRV queries, what IP address(es) that MTA uses).

The link from the MTA to its operator is still missing.

>    While this perhaps comes "close", it's not designating an "accountable 
> party"; and the IP address is related to the HELO string, not the other 
> way around. It does _not_ lead to an "accountable party" -- it merely 
> associates a reference string (the domain name) that we can use as a 
> query to reputation services.

To this end, I'd prefer the use of a domain name. One reason is that 
large ESP have many MTAs that can be used interchangeably. In 
addition, the person responsible for an MTA is not always identifiable 
(in Italy, the mandate to state who are the sysadmins of an MTA is 
being procrastinated every few months, since November 2008.) By 
contrast, domain registrants often have whois records pointing to them.

>> 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.
>    Actually,
> "
> " Relaying and delivering employ policies that occur after submission and
> " are outside the scope of this document.
> RFC5068 deals with the operation of Mail Submission Agents. I don't agree 
> it even "suggests" how accountability should follow the message as it 
> winds its way to the recipient.

It does. Notwithstanding the sentence you quoted, there is a 
"Submission Accountability after Submission" paragraph in section 3.1, 

       For a reasonable period of time after submission, the message
       SHOULD be traceable by the MSA operator to the authenticated
       identity of the user who sent the message.

A similar norm is mandated by anti-terrorism regulations, in the EU at 

That way, accountability could be theoretically traced, _if_ the first 
submission followed those guidelines. While I can be reasonably sure 
that the connecting client is not an open relay, after IP based DNSBL, 
I have no means to know that the site either enforces the submission 
protocol in general, or did so for at least the messages it is about 
to relay.

Thus, it turns out that if an MTA does mixed MSA and old fashioned 
port 25 relaying for its clients, its IP cannot convey accountability.