[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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