IETF Logo Mail Archive

RE: The anti-abuse rDNS check that FTP gave up

"Storz, Michael" <Michael.Storz@lrz.de> Wed, 05 October 2011 15:28 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p95FSf0b058989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2011 08:28:41 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p95FSfiK058988; Wed, 5 Oct 2011 08:28:41 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from mailrelay1.lrz-muenchen.de (mailrelay1.lrz-muenchen.de [129.187.254.106]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p95FSecp058976 for <ietf-smtp@imc.org>; Wed, 5 Oct 2011 08:28:40 -0700 (MST) (envelope-from Michael.Storz@lrz.de)
Received: from postout2.mail.lrz.de ([10.156.6.19] [10.156.6.19]) by mailrelay1.lrz-muenchen.de with ESMTP; Wed, 5 Oct 2011 17:28:08 +0200
Received: from BADWLRZ-SWHBT1.ads.mwn.de (BADWLRZ-SWHBT1.ads.mwn.de [IPv6:2001:4ca0:0:108::125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postout2.mail.lrz.de (Postfix) with ESMTPS id 93108A5108; Wed, 5 Oct 2011 17:28:08 +0200 (CEST)
Received: from BADWLRZ-SWMBX1.ads.mwn.de ([fe80::11b4:b130:c4e2:2d0e]) by BADWLRZ-SWHBT1.ads.mwn.de ([fe80::e42f:e9f5:bde9:f99b%16]) with mapi id 14.01.0339.001; Wed, 5 Oct 2011 17:28:08 +0200
From: "Storz, Michael" <Michael.Storz@lrz.de>
To: "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu>
CC: SMTP Interest Group <ietf-smtp@imc.org>
Subject: RE: The anti-abuse rDNS check that FTP gave up
Thread-Topic: The anti-abuse rDNS check that FTP gave up
Thread-Index: AQHMeiOzvk3AcF+9o0207DlJADfey5VtR0IYgACiSIA=
Date: Wed, 05 Oct 2011 15:28:08 +0000
Message-Id: <91A6E2FC874989448F4162C59414813D268B800C@BADWLRZ-SWMBX1.ads.mwn.de>
References: <4E7CD4F3.5000703@tana.it> <13829.1317790675@turing-police.cc.vt.edu>
In-Reply-To: <13829.1317790675@turing-police.cc.vt.edu>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4ca0:0:300::71]
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p95FSfcp058982
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

> On Fri, 23 Sep 2011 20:50:27 +0200, Alessandro Vesely said:
> 
> > Most SMTP servers duly lookup the client's IP and annotate the
> > resulting name as comment in Received fields.  However, I don't
> recall
> > denying SMTP access based on the "iprev" test (as RFC 5451 named it.)
> >  Was it ever à la mode to do so?
> 
> At one time, the net was still small enough that it was a safe
> assumption that
> if you got mail from an IP address that didn't have a valid rDNS, it
> was (a) a rare
> event because (b) a missing rDNS meant the provider was asleep at the
> wheel.
> 
> Now-a-days, most providers have automatic provisioning systems that
> assign rDNS
> for customer addresses, so most of Vint Cerf's famous 140 million
> compromised
> machines have an rDNS entry, which means it's not that effective
> anymore.
> 
> (What *is* used a lot today is 'rDNS looks like a customer
> cablemodem/adsl connection')

Another name for the iprev test is "Forward Confirmed reverse DNS" (FCrDNS). With Postfix you configure it with the two commands

   reject_unknown_reverse_client_hostname
   reject_unknown_client_hostname

We use this check since years as our first defense against botnet spam with great success. In the last 7 days we rejected emails for nearly 22.000.000 recipients. 49% did not have a PTR record, 29% did not have a matching A record. Therefore the FCrDNS was responsible for 78% of all rejections. This means your statement, that this check is not working, is definitely not true.

However you have to live with a moderately false positive rate. Before we implemented the check, we analyzed out traffic for 3 months and build an automatic whitelist with 4.000 wrongly configured MTAs. Since the beginning of the check we get about 1-2 false positives per week reported by our users. This second whitelist has 230 entries at the moment. This means about 4% of the MTAs we accept emails from are wrongly configured. We can live with that.

Michael

v2.23.0 | Report a Bug | By Email