John Rudd wrote: > That seems to be an important distinction for > strict/rigorous/theoretical discussions of "what is full circle > reverse DNS", and things along those lines... but I'm not sure if > it really is an important distinction for the practical matter of > how you handle tests in SA.
I think FCrDNS stands for "Forward-confirmed reverse DNS" as noted at http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS :-) To clarify your four examples (as I understand them): IP = 222.252.188.181 1: IP -> rDNS: localhost -> DNS: [none] -> FAIL* (DNS is missing) 2: IP -> rDNS: localhost ->-> ~FAIL (rDNS result is forbidden) 3: IP -> rDNS: localhost -> DNS: 127.0.0.1 -> FAIL (mismatch) 4: IP -> rDNS: localhost -> DNS: 127.0.0.1 -> ~FAIL (DNS is forbidden) I don't think we ever discussed #2 or #4, which state that entering "localhost" as a domain or "127.0.0.1" as an IP is explicitly forbidden. As a matter of fact, there is nothing stopping a domain from resolving to 127.0.0.1 (or 127.0.0.1 from resolving to a domain, regardless of whether or not it is "localhost") and no reason for SMTP to complain about it, so those aren't always automatic failures. > All four of these are, practically speaking, the same, regardless > of whether or not you're saying that the first one is strictly > speaking a "full circle reverse DNS check". We were discussing #1 and #3. My argument is that #1 is what happens in this case, which is significant because FCrDNS's failure to close the loop can result in ambiguous data (mu) could arise (thus my quotes); as with SPF, which does nothing if there is no SPF record by which to compare, some FCrDNS mechanisms will ignore (or pass) entrants that lack one of the components. SENDMAIL HAS THIS AMBIGUITY. It only places the "(may be forged)" marker on servers that have existing but invalid rDNS, as judged by the rDNS domain resolving to IP(s) that do not include the server, so sendmail correctly fails #5 (same as #3) but NOT #6, and I'm not sure about #7 (same as #1) in the following. Note that 1,3,5,6,7 are FCrDNS failures while 2,4 are not (and 3 requires local DNS entries). 5. IP -> rDNS: Domain -> DNS: IP2 -> FAIL (mismatch) 6. IP -> rDNS: [none] ->-> FAIL (no rDNS, doesn't fail in sendmail) 7. IP -> rDNS: Domain -> DNS: [none] -> FAIL (no DNS, sendmail=?) Within SpamAssassin, RDNS_NONE catches #6, my KHOP_MAYBE_FORGED catches #5 (on sendmail servers), and I think #7 goes uncaught. The other rule I described, KHOP_HELO_FCRDNS, catches #8, which isn't technically FCrDNS: 8. IP -> rDNS: Domain != HELO -> ~FAIL (mismatch) The other reason I took the argument was to answer Matus's SPF question; SPF depends on actual DNS records, and there is no authoritative name server for the TLD-lacking localhost or localhost.localdomain, so an SPF record for those would require a custom entry on the local caching DNS server (a local/LAN caching DNS server is essential for SpamAssassin implementations using DNSEval and URIDNSBL, which IMHO should be all SpamAssassin implementations given their high effectiveness). -- Adam Katz khopesh on irc://irc.freenode.net/#spamassassin http://khopesh.com/Anti-spam
