John Hardin wrote: >> I think what Matus was saying is: >> 181.188.252.222.in-addr.arpa -> "localhost" -> 127.0.0.1 = FAIL.
And what I'm saying is that the second step of that: "localhost" -> 127.0.0.1 doesn't work since "localhost" has no A record. So it should actually go: 181.188.252.222.in-addr.arpa -> "localhost" -> FAIL and I'm not sure if that result nulls the equation or if it actually outputs an FCrDNS failure. My guess is that it does. YMMV by MTA. Matus UHLAR - fantomas then wrote: > actually, many recursive DNS servers have configured zone for > "localhost" by default and for "0.0.127.in-addr.arpa" or > "127.in-addr.arpa". That's what I was musing at the end of my email, complete with SPF. > However if anything doesn't resolve, MTA should not accept/use it. I've already responded to this. As you quoted me: >>> Sadly, too many servers are set up improperly in this context, >>> so I doubt I'm in the minority when I say that I don't use this >>> metric to single-handedly block mail. The custom SA rules I included in my email do indeed rely upon the MTA's ability to measure FCrDNS and HELO FCrDNS. As referenced in my email, sendmail performs FCrDNS checking out of the box, tacking a "(may be forged)" to the end of the Received: header for FCrDNS failures. You can also set PICKY_HELO_CHECK if you want your logs littered with myriads of FCrDNS warnings. I'd love to also get sendmail (or SA) to resolve the HELO domain. Sure, it's nice to see IP -> domain -> IP, and then compare the HELO to that domain (KHOP_HELO_FCRDNS, IP -> domain == HELO), but how do I check HELO -> IP? I can make a regular expression to do what I want (for sendmail's headers, as documented at http://tinyurl.com/pb8vje section 10.7.2), but I can't use this in SA because I have no way of performing it only on the firsttrusted relay (the first hit in X-Spam-Relays-Untrusted). The solution is to name my relay, so if it's mx.example.com, I'd have: Received =~ /from (\S+) \((?!\1)\S+\.\w{2,6} \[[0-9.]{7,15}(?: \(may be forged\))?\) by mx\.example\.com[ (]/ Developers: I'd /love/ to be able to use trusted_networks and internal_networks as regex variables like: trusted_networks example.com 1.2.3.4 header TEST1 Received =~ /from .* by $trusted_networks[ (]/ # which translates to: #header TEST1 Received =~ /from .* by (?:example.com|1\.2\.3\.4)[ (]/ (or perhaps use "mx example.com 1.2.3.4" and $mx becomes that regex.) I'd also (or even alternatively) love to see X-Spam-Received-[type] (where type is one of Trusted, Untrusted, Internal, External) which is merely a bracket-bounded collection of properly ordered Received tags, as presented by the parsing relay. This would let me parse those things manually without getting the order wrong (since SA rules are not capable of understanding order). > I was only talking that SA does not resolve IPs but hostnames are taken from > Received: headers (there was an exception for MTA that does not resolve DNS) > so the MTA not the SA should be blamed if the "hostnames" are not correct > (forward confirmed). I see nothing wrong with assuming the MTA did its job correctly. >>> Maybe SPF, I expect someone to comment on this... >> Same problem as above: "localhost" is not actually a domain. > >> $ host -t TXT localhost. > > I was not talking about localhost, but about SPF resolution. Sorry, I thought that you were trying to apply SPF to localhost, since that was the issue we were discussing. > The TXT must be of course taken from DNS, but if the record > contains "A:" etc, it can be compared to resolved hostname in > Received: header. And by the sentence above I meant that someone > who understands the SPF should comment this issue. I've got a pretty good understanding of SPF, thank you. All I'm missing is an understanding of what you want to do with it. You appear to be trying to parse the SPF record manually. SPF records can contain "a:" or "ip4:" or several other things. What kind of comparison are you trying to do? Comparing an "a:" entry to the resolved hostname (rDNS) is exactly what SPF does ... there are no bidirectional requirements for within SPF records. Perhaps that's what you were trying to get to? You think SPF "a:" records must pass FCrDNS? That won't work for a domain "example.com" that uses a round-robin A record in its SPF declaration, for example: $ host -t TXT example.com example.com descriptive text "v=spf1 a:spf.example.com ~all" $ host -t A spf.example.com spf.example.com has address 1.2.3.4 spf.example.com has address 1.3.4.5 spf.example.com has address 1.4.5.6 $ host -t PTR 1.2.3.4 4.3.2.1.in-addr.arpa domain name pointer mx1.example.com. FCrDNS is a decent metric by which to measure spamminess because it is required by the SMTP RFC. SPF requires neither FCrDNS nor even rDNS.
