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

Bill Cole <asrg3@billmail.scconsult.com> Wed, 17 June 2009 03:36 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 766123A68B0 for <asrg@core3.amsl.com>; Tue, 16 Jun 2009 20:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level:
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 yLRVXZa5mGul for <asrg@core3.amsl.com>; Tue, 16 Jun 2009 20:36:26 -0700 (PDT)
Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 82BED3A6778 for <asrg@irtf.org>; Tue, 16 Jun 2009 20:36:26 -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 DE7608D5549 for <asrg@irtf.org>; Tue, 16 Jun 2009 23:36:37 -0400 (EDT)
Message-ID: <4A3864C5.1050006@billmail.scconsult.com>
Date: Tue, 16 Jun 2009 23:36:37 -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>
In-Reply-To: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local>
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: Wed, 17 Jun 2009 03:36:27 -0000

Franck Martin wrote, On 6/16/09 6:20 PM:
> I recently encountered the following question/problems.
>
> I have a mail server and one of my users complains he is not receiving
> emails from a domain. How do I find if I have blocked the domain from
> sending to my server. Meaning, knowing the domain name of the sender,
> how do I find the IPs from where the mail could be sent from.

There is no reliable way to do so.

> It seems
> that SPF is the only tool to provide that answer?

Only partially. SPF cannot be considered reliable, since not all domains 
publish records and some publish inaccurate records.

There have been other proposed approaches that may have some deployment:

CSV/CSA: http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.html
DRIP: http://tools.ietf.org/html/draft-brand-drip-02

> In another related problem, which is linked to IPv6 and RBL. Buidling an
> IPv6 RBL could lead to a huge database. Sure you can alleviate by using
> "wildcards", but why not use the reverse DNS resolution to add a TXT
> record associated to the IP to indicate the IP is the one of a mail
> server? So any IP that does not have this record would be blocked for
> SMTP. As IPv6 is not used for SMTP (or barely), this could be made
> mandatory for IPv6 and optional for IPv4. An MUA could talk to an MTA on
> port 25 because we know the the etwork range of the MUA or the
> alternative is to use the new mail submit port.

Similar proposals have been made before, and I'm pretty sure one such has 
been made on this list although I can't find proof of that at present.

There's always some degree of resistance to putting information into the 
reverse zone because it is frequently under different control than related 
forward zones and can be a chore to get set or changed. There are also 
concerns about loading up new sorts of records into the reverse zone because 
it is a simpler tree that has traditionally had light query volume, and the 
existing systems may not be prepared to handle an extra query down the 
reverse tree for every SMTP connection.

That said, I think that adding DNS records that map specific network 
addresses to their legitimate behaviors in a generalized model would be a 
positive advance.