Qpsmtpd:fcrdns
NAME
Forward Confirmed RDNS - http://en.wikipedia.org/wiki/FCrDNS
DESCRIPTION
Determine if the SMTP sender has matching forward and reverse DNS.
Adds the 'iprev' section to the Authentication-Results header when there's sufficient DNS (at least rDNS) to be meaningful.
WHY IT WORKS
The reverse DNS of zombie PCs is out of the spam operators control. Their only way to pass this test is to limit themselves to hosts with matching forward and reverse DNS. At present, this presents a significant hurdle.
VALIDATION TESTS
- has_reverse_dns
Determine if the senders IP address resolves to a hostname.
- has_forward_dns
If the remote IP has a PTR hostname(s), see if that host has an A or AAAA. If so, see if any of the host IPs (A or AAAA records) match the remote IP.
Since the dawn of SMTP, having matching DNS has been a standard expected and oft required of mail servers. While requiring matching DNS is prudent, requiring an exact match will reject valid email. This often hinders the use of FcRDNS. While testing this plugin, I noticed that mx0.slc.paypal.com sends mail from an IP that reverses to mx1.slc.paypal.com. While that's technically an error, so too would rejecting that connection.
To avoid false positives, matches are extended to the first 3 octets of the IP and the last two labels of the FQDN. The following are considered a match:
192.0.1.2, 192.0.1.3 foo.example.com, bar.example.com
This allows FcRDNS to be used without rejecting mail from orgs with pools of servers where the HELO name and IP don't exactly match. This list includes Yahoo, Gmail, PayPal, cheaptickets.com, exchange.microsoft.com, etc.
CONFIGURATION
timeout [seconds]
Default: 5
The number of seconds before DNS queries timeout.
reject [ 0 | 1 | naughty ]
Default: 1
0: do not reject
1: reject
naughty: naughty plugin handles rejection
reject_type [ temp | perm | disconnect ]
Default: disconnect
What type of rejection should be sent? See docs/config.pod
loglevel
Adjust the quantity of logging for this plugin. See docs/logging.pod
RFC 1912, RFC 5451
From Wikipedia summary:
1. First a reverse DNS lookup (PTR query) is performed on the IP address, which returns a list of zero or more PTR records. (has_reverse_dns)
2. For each domain name returned in the PTR query results, a regular 'forward' DNS lookup (type A or AAAA query) is then performed on that domain name. (has_forward_dns)
3. Any A or AAAA record returned by the second query is then compared against the original IP address (check_ip_match), and if there is a match, then the FCrDNS check passes.
iprev
2.4.3. "iprev" Results
The result values are used by the "iprev" method, defined in Section 3, are as follows:
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.
AUTHOR
2013 - Matt Simerson
