Forward Confirmed Reverse DNS

Determine if the SMTP sender has matching forward and reverse DNS.

This plugin is automatically installed with Haraka >= 2.8.14 and needs only to be activated by removing the leading comment (#) symbol:

cd /path/to/haraka
sed -i '' -e '/fcrdns/ s/^# //' config/plugins

To upgrade from versions of Haraka <= 2.8.13

cd /path/to/haraka
npm install haraka-plugin-fcrdns
sed -i '' -e 's/connect.fcrdns/fcrdns/' config/plugins
mv config/connect.fcrdns.ini config/fcrdns.ini

Other plugins can use FCrDNS results like this:

const fcrdns = connection.results.get('fcrdns');
if (fcrdns) {
    if (fcrdns.fcrdns) {
        // they passed, reward them
    }

    if (connection.results.has('fcrdns', 'fail', /^is_generic/)) {
        // their IP is in their hostname, unlikely to be MX, penalize
    }
}

Edit config/fcrdns.ini

This plugin honors the whitelisting of IPs as set by the rdns_access plugin. For that to work, rdns_access needs to be listed before this plugin in config/plugins.

• timeout=30

When performing DNS lookups, time out after this many seconds.

The following settings permit control of which test will block connections. To mimic the lookup_rdns.strict plugin, set no_rdns=true.

    [reject]
    ; reject if the IP address has no PTR record
    no_rdns=false

    ; reject if the FCrDNS test fails
    no_fcrdns=false

    ; reject if the PTR points to a hostname without a valid TLD
    invalid_tld=false

    ; reject if the rDNS is generic, examples:
    ; 1.2.3.4.in.addr.arpa
    ; c-67-171-0-90.hsd1.wa.comcast.net
    generic_rdns=false

The reverse DNS of zombie PCs in bot nets is out of the bot operators control. This presents a significant hurdle for a large portion of the hosts that attempt spam delivery.

From Wikipedia: Forward Confirmed Reverse DNS

1. First a reverse DNS lookup (PTR query) is performed on the IP address, which returns a list of zero or more PTR records.

2. For each domain name returned in the PTR query results, a regular 'forward' DNS lookup (type A or AAAA query) is then performed.

3. Any A or AAAA records returned by the second query are then compared against the original IP address. If there is a match, FCrDNS passes.

The iprev results are added to the Authentication-Results header.

RFC 1912 RFC 5451 RFC 7001

2.6.3. "iprev" Results

pass: The DNS evaluation succeeded, i.e., the "reverse" and "forward" lookup results were returned and were in agreement.

fail: The DNS evaluation failed. In particular, the "reverse" and "forward" lookups each produced results, but they were not in agreement, or the "forward" query completed but produced no result, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) in a reply containing no answers, was returned.

temperror: The DNS evaluation could not be completed due to some error that is likely transient in nature, such as a temporary DNS error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or other error condition resulted. A later attempt may produce a final result.

permerror: The DNS evaluation could not be completed because no PTR data are published for the connecting IP address, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) in a reply containing no answers, was returned. This prevented completion of the evaluation. A later attempt is unlikely to produce a final result.