Re: FCrDNS and localhost
mouss wrote: Adam Katz a écrit : Actually, localhost doesn't resolve via DNS; I don't know where you're taking this from: $ host localhost 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: localhost.netoyen.net has address 127.0.0.1 Although I like host a lot in this case I think dig gives more convincing results. $ dig -x 127.0.0.1 ptr ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 604800 IN PTR localhost. $ dig localhost a ;; ANSWER SECTION: localhost. 604800 IN A 127.0.0.1 it has no A record, nor any other record type. It resolves locally without using DNS; see your /etc/hosts file. Similarly, 1.0.0.127.in-addr.arpa. has no PTR record indicating it should be called localhost. Both localhost and 127.0.0.1 resolve as expected. They definitely have A and PTR records. It does here. we BSD users love DNS ;-p And here too. (Debian GNU/Linux but we could list out virtually every legacy Unix and modern system.) In contrast, localdomain is not a valid TLD. localdomain, as in localhost.localdomain is a clever hack to initially provision a generic system such that everything is consistent and somewhat functioning in a standalone way without having an actual real domain. By using localhost.localdomain in the MTA and everywhere else it is needed the software can be configured for a fqdn without actually having a fqdn. It's fake. But self-consistent. And so useful as a generic placeholder configuration. For machines visible on the Internet this should be replaced with real configuration. Machines that are not visible can happily not worry about it. I suppose I could place such an entry in my local DNS server... Actually, I like that idea. Don't forget to also create an A record! You'll want TXT record v=spf1 ip4:127.0.0.0/8 -all for both localhost. and localhost.localdomain. why bother yourself with SPF since nobody remote should call himself localhost. localhost is a reserved domain. I reject at SMTP time clients who claim to be localhost at the MTA level. This is a well known anti-spam technique and I am sure most of us on this list have this as a standad configuration. A lot of spam is rejected very quickly this way. Bob
Re: FCrDNS and localhost
On 05.06.09 23:55, mouss wrote: localhost.netoyen.net has address 127.0.0.1 Actually, I think this is not good. localhost. should resolve, but putting localhost to other domains even with 127.0.0.1 address is something that should be imho avoided ;) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. M$ Win's are shit, do not use it !
Re: FCrDNS and localhost
Matus UHLAR - fantomas wrote: Actually, I think this is not good. localhost. should resolve, but putting localhost to other domains even with 127.0.0.1 address is something that should be imho avoided ;) I think it is okay and normal to have localhost.$mydomain resolve to 127.0.0.1. But the reverse 127.0.0.1 should never resolve to localhost.$mydomain but always to localhost. It is recommended not to send queries for local addresses off to the root nameservers. localhost by itself is used and expected to work. Therefore enabling localhost.$mydomain to resolve prevents this. Bob
Re: FCrDNS and localhost
Matus UHLAR - fantomas wrote: Actually, I think this is not good. localhost. should resolve, but putting localhost to other domains even with 127.0.0.1 address is something that should be imho avoided ;) On 06.06.09 11:28, Bob Proulx wrote: I think it is okay and normal to have localhost.$mydomain resolve to 127.0.0.1. But the reverse 127.0.0.1 should never resolve to localhost.$mydomain but always to localhost. It is recommended not to send queries for local addresses off to the root nameservers. localhost by itself is used and expected to work. Therefore enabling localhost.$mydomain to resolve prevents this. what's why localhost zone should be configured in each resolving nameserver... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm
Re: FCrDNS and localhost
Matus UHLAR - fantomas a écrit : On 05.06.09 23:55, mouss wrote: localhost.netoyen.net has address 127.0.0.1 oh, I didn't even realize it was the .$domain one! old habit to avoid nslookup barking and then lusers asking what's the problem... Actually, I think this is not good. localhost. should resolve, but putting localhost to other domains even with 127.0.0.1 address is something that should be imho avoided ;) why? if it's because of xss and the like, it doesn't apply here, because attacker can use http://localhost/ as well (or even http://127.0.0.1/). or am I missing something?
Re: FCrDNS and localhost
On Thu, Jun 4, 2009 at 16:32, Adam Katzantis...@khopis.com wrote: 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 :-) Every place I've seen it talked about, including past discussion on this list, calls it Full Circle, not Forward Confirmed. Based on that page, I assume they're synonymous. 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. I was trying to cover more bases in the localhost/127.0.0.1 results, to be more complete/thorough. 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. I didn't imply that they're automatically failures. It was an implication that the rule that does the checking might be set up to reject those results. I got back localhost as a result, and I don't want that, so I'm going to give a rule failure of some sort, rather than continue on to some other result. SENDMAIL HAS THIS AMBIGUITY. In fact, Sendmail's ambiguity on the subject was part of why I wrote Botnet. 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) I'm pretty sure, but I'd have to re-check, that Botnet catches all of those. Btw: are you the Adam Katz that used to be Mr. Curtain in the Santa Cruz/UCSC geek scene?
Re: FCrDNS and localhost
John Rudd wrote: I think FCrDNS stands for Forward-confirmed reverse DNS as noted at http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS :-) Every place I've seen it talked about, including past discussion on this list, calls it Full Circle, not Forward Confirmed. Based on that page, I assume they're synonymous. I hope so. They both sound like great names for the concept, anyway. 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. I didn't imply that they're automatically failures. It was an implication that the rule that does the checking might be set up to reject those results. I got back localhost as a result, and I don't want that, so I'm going to give a rule failure of some sort, rather than continue on to some other result. So then they are specific samples that despite not failing FCrDNS, you would like to discriminate against? I misunderstood your intent. Checking against private and local networks sounds like a good idea. SENDMAIL HAS THIS AMBIGUITY. In fact, Sendmail's ambiguity on the subject was part of why I wrote Botnet. Ah, that was you (this list is awesome; everybody's here!). I keep meaning to try that plugin, but I'm wary of all the false positives I hear it creates (so I'd have to turn the scores down to near-zero and then slowly turn them up). I also find that greylisting, even if solely against Windows desktops (p0f is now supported in milter-greylist, and I'd be happy to share my rules that let servers through), seems to alleviate my need for botnet detection. 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) I'm pretty sure, but I'd have to re-check, that Botnet catches all of those. Interesting. Catching #7 would be nice, though not worth too many points given how often servers accidentally use their internal (non-TLD) names. However, regexps can solve that quite nicely. Does botnet create pseudo-headers for later polling? Btw: are you the Adam Katz that used to be Mr. Curtain in the Santa Cruz/UCSC geek scene? Nope, haven't been there since I was a kid. There are thousands of people with my name (and yet I'm the one with www.adamkatz.com). There are only a handful of us in the geek world, so I think I can isolate the one you're thinking of to the guy at www.geekeasy.com. Heck, I live only a few blocks from another Adam Katz who is a professional web designer (which I've done from time to time). I'm the (only?) one that does F/OSS, DD, and spam-fighting stuff. ... I'm also a famous dog trainer, MLB sports agent, several journalists, and I teach plastic surgery, religion, English, and literature at various universities. :-D -- Adam Katz khopesh on irc://irc.freenode.net/#spamassassin http://khopesh.com/Anti-spam
Re: FCrDNS and localhost
Matus UHLAR - fantomas a écrit : Actually, I think this is not good. localhost. should resolve, but putting localhost to other domains even with 127.0.0.1 address is something that should be imho avoided ;) On 06.06.09 20:39, mouss wrote: why? if it's because of xss and the like, it doesn't apply here, because attacker can use http://localhost/ as well (or even http://127.0.0.1/). or am I missing something? it's either useless or hides a problem elsewhere... however it's OT here... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
Re: FCrDNS and localhost
On Thu, Jun 4, 2009 at 16:32, Adam Katzantis...@khopis.com wrote: I think FCrDNS stands for Forward-confirmed reverse DNS as noted at http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS :-) On 06.06.09 13:39, John Rudd wrote: Every place I've seen it talked about, including past discussion on this list, calls it Full Circle, not Forward Confirmed. Based on that page, I assume they're synonymous. I have never seen the full circle until this discussion. googling gives the other name at least on first 10 results... 5. IP - rDNS: Domain - DNS: IP2 - FAIL (mismatch) 6. IP - rDNS: [none] -- FAIL (no rDNS, doesn't fail in sendmail) because this is not fail. This just means the IP does not have RDNS, not that anyone is trying to fake that. So I think that's a different thing. 8. IP - rDNS: Domain != HELO - ~FAIL (mismatch) I'm pretty sure, but I'd have to re-check, that Botnet catches all of those. Well, this is catched by RCVD_HELO_IP_MISMATCH with quite high score. (And, the SMTP connection MUST NOT be rejected (only) because of this mismatch, we talked about this already) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Re: FCrDNS and localhost
mouss wrote: $ host localhost 127.0.0.1 localhost.netoyen.net has address 127.0.0.1 You forgot the trailing dot, so it tacked your own domain onto the end of that. I'm believe localhost.$domain is not required by any specs and is non-standard. ... That's okay, I'll just assume your DNS serves that A record as you've stated. I've got servers all over the place, so here's a better tally than the previous hasty checks. This crosses FreeBSD, Red Hat, and Debian just fine, since it's more a result of the upstream DNS than the local instances. I've purposefully removed any DNS servers I administer from consideration, instead using their upstream sources. Results: two of my company's colocation providers resolve localhost while the three others do not. My office T1s do not. My alma mater does not (and unless I'm mistaken, neither do its upstream providers). My home cable does not. Four of my colos resolve 1.0.0.127.in-addr.arpa while one does not. My cable ISP resolves it, and my office T1s resolve it to the wrong domain (as a subdomain of one of their subsidiaries). My alma mater also resolves it. It does here. we BSD users love DNS ;-p This is not OS-dependent. My BSD boxes exhibit the same results as the Linux boxes, and the BSD box running a BIND server fails to resolve localhost (note, BIND was not installed via ports). To be thorough, I checked host, dig, and nslookup on a BSD server to ensure consistency. Maybe SPF, I expect someone to comment on this... Same problem as above: localhost is not actually a domain. it _is_. [...] In contrast, localdomain is not a valid TLD. Are you also arguing that the localhost FQDN has a TXT record in addition to its A record? How can you argue that localhost is a FQDN while localdomain, which is equally hacked, is not a TLD? localhost is not a domain because it has no whois entry and no NS record (which consequently means no A record and no TXT record). It is reserved. I suppose I could place such an entry in my local DNS server... Actually, I like that idea. Don't forget to also create an A record! You'll want TXT record v=spf1 ip4:127.0.0.0/8 -all for both localhost. and localhost.localdomain. why bother yourself with SPF since nobody remote should call himself localhost. localhost is a reserved domain. Two proposals with the same goal have been made: specific hunting for localhost and friends or SPF entries for them. Since this specific hunting is not built into SA or the MTA by default, it must be added, just as SPF would need. I chose to add SPF; six of one, half-a-dozen of the other. Let me rephrase my whole argument: Different DNS servers, depending on their administrators, have different results for localhost and localhost.localdomain. Even rDNS on 127.0.0.1 can fail to resolve (or resolve correctly). Therefore, it may be troublesome to make assumptions on these grounds. That's it.
Re: FCrDNS and localhost
Adam Katz a écrit : Matus UHLAR - fantomas wrote: 181.188.252.222.in-addr.arpa domain name pointer localhost. That is why FcRDNS is being used everywhere... localhost has address 127.0.0.1 = fail. Actually, localhost doesn't resolve via DNS; I don't know where you're taking this from: $ host localhost 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: localhost.netoyen.net has address 127.0.0.1 it has no A record, nor any other record type. It resolves locally without using DNS; see your /etc/hosts file. Similarly, 1.0.0.127.in-addr.arpa. has no PTR record indicating it should be called localhost. It does here. we BSD users love DNS ;-p if anyone uses reverse DNS name without forward-confirming it, it's their own fault and they can take all consequencies from such stupid setup. afaik some reverse-checking services are more strict about invalid than about nonexisting hostnames. And I recommend to behave like that. SA (usually) uses hostname passed by MTA, so if an MTA is affected by this bug, blame MTA, not SA. And I'm not sure if the hostname is used by any checks that would cause positive (oor lower negative) score. 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. My khop-general.sa.khopesh.com channel contains: # Sendmail's FCrDNS, see http://www.sendmail.org/faq/section3#3.38 header KHOP_MAYBE_FORGED Received =~ /\(may be forged\)/ describe KHOP_MAYBE_FORGED Relay IP's reverse DNS does not resolve to IP scoreKHOP_MAYBE_FORGED 0.8 # 20050802, raised 0.15-0.8 20090603 # Violates rfc2821? See http://en.wikipedia.org/wiki/FCrDNS#Uses headerKHOP_HELO_FCRDNS X-Spam-Relays-Untrusted =~ /^[^\]]+ rdns=(\S+) helo=(?!\1)\S/ describe KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS score KHOP_HELO_FCRDNS 0.4 # 20090603 Maybe SPF, I expect someone to comment on this... Same problem as above: localhost is not actually a domain. it _is_. $ host -t TXT localhost. localhost has no TXT record $ host -t TXT localhost.localdomain. localhost.localdomain has no TXT record In contrast, localdomain is not a valid TLD. I suppose I could place such an entry in my local DNS server... Actually, I like that idea. Don't forget to also create an A record! You'll want TXT record v=spf1 ip4:127.0.0.0/8 -all for both localhost. and localhost.localdomain. why bother yourself with SPF since nobody remote should call himself localhost. localhost is a reserved domain.
Re: FCrDNS and localhost
Adam Katz a écrit : John Hardin wrote: So that data comes from /etc/hosts. How does that materially affect the FCrDNS sanity test? By definition, FCrDNS uses DNS lookups. Unless you're using dnsmasq, the entries in /etc/hosts are ignored during DNS lookups. This is wrong. FCrDNS lookup uses a DNS resolver, which could use whatever you setup on your system, including /etc/hosts. for example, postfix uses the system resolver, which can be configured via nsswitch.conf to query /etc/hosts and/or DNS. Unless I'm mistaken, no FCrDNS implementation ever queries /etc/hosts (nor should it). Are you saying that all those widely used servers that do this are wrong? This means FCrDNS will conclude that localhost does not resolve I don't know why you say that localhost doesn't resolve. It resolves on all systems I have ever used. my basic DNS template files include resolution for reserved domains and IP blocks (so that resolving private IPs doesn't go over the network uselessly...). and that 127.0.0.1 has no rDNS (excepting cases where the admins have manually placed such entries into the local DNS). which is the default in *BSD and other distributions.
Re: FCrDNS and localhost
On Fri, June 5, 2009 23:55, mouss wrote: why bother yourself with SPF since nobody remote should call himself localhost. localhost is a reserved domain. will you wake up one day and beat me in my foot ? :))) localhost check does not rule out that spf check can be usefull -- http://localhost/ 100% uptime and 100% mirrored :)
Re: FCrDNS and localhost
Matus UHLAR - fantomas wrote: 181.188.252.222.in-addr.arpa domain name pointer localhost. That is why FcRDNS is being used everywhere... localhost has address 127.0.0.1 = fail. On 03.06.09 19:31, Adam Katz wrote: Actually, localhost doesn't resolve via DNS; it has no A record, nor any other record type. It resolves locally without using DNS; see your /etc/hosts file. Similarly, 1.0.0.127.in-addr.arpa. has no PTR record indicating it should be called localhost. 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. However if anything doesn't resolve, MTA should not accept/use it. if anyone uses reverse DNS name without forward-confirming it, it's their own fault and they can take all consequencies from such stupid setup. afaik some reverse-checking services are more strict about invalid than about nonexisting hostnames. And I recommend to behave like that. SA (usually) uses hostname passed by MTA, so if an MTA is affected by this bug, blame MTA, not SA. And I'm not sure if the hostname is used by any checks that would cause positive (oor lower negative) score. 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. 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). 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. 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. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges.
Re: FCrDNS and localhost
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.
Re: FCrDNS and localhost
On Thu, 4 Jun 2009, Adam Katz wrote: 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 that data comes from /etc/hosts. How does that materially affect the FCrDNS sanity test? 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. You're treating localhost as a special case of FCrDNS. While that's reasonable, you shouldn't have to do that. If you don't have localhost in the /etc/hosts file on a production machine you shouldn't be an admin... (-- sweeping generalization, I know.) -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- When I say I don't want the government to do X, do not automatically assume that means I don't want X to happen. --- 2 days until the 65th anniversary of D-Day
Re: FCrDNS and localhost
John Hardin wrote: So that data comes from /etc/hosts. How does that materially affect the FCrDNS sanity test? By definition, FCrDNS uses DNS lookups. Unless you're using dnsmasq, the entries in /etc/hosts are ignored during DNS lookups. Unless I'm mistaken, no FCrDNS implementation ever queries /etc/hosts (nor should it). This means FCrDNS will conclude that localhost does not resolve and that 127.0.0.1 has no rDNS (excepting cases where the admins have manually placed such entries into the local DNS).
Re: FCrDNS and localhost
On Thu, 4 Jun 2009, Adam Katz wrote: John Hardin wrote: So that data comes from /etc/hosts. How does that materially affect the FCrDNS sanity test? By definition, FCrDNS uses DNS lookups. Unless you're using dnsmasq, the entries in /etc/hosts are ignored during DNS lookups. Unless I'm mistaken, no FCrDNS implementation ever queries /etc/hosts (nor should it). This means FCrDNS will conclude that localhost does not resolve and that 127.0.0.1 has no rDNS (excepting cases where the admins have manually placed such entries into the local DNS). Okay, I'll buy that. I guess I usually think in terms of gethostbyname() and related functions, rather than a pure DNS query. Apologies. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Our government wants to do everything it can for the children, except sparing them crushing tax burdens. --- 2 days until the 65th anniversary of D-Day
Re: FCrDNS and localhost
On Thu, Jun 4, 2009 at 13:57, Adam Katz antis...@khopis.com wrote: John Hardin wrote: So that data comes from /etc/hosts. How does that materially affect the FCrDNS sanity test? By definition, FCrDNS uses DNS lookups. Unless you're using dnsmasq, the entries in /etc/hosts are ignored during DNS lookups. Unless I'm mistaken, no FCrDNS implementation ever queries /etc/hosts (nor should it). This means FCrDNS will conclude that localhost does not resolve and that 127.0.0.1 has no rDNS (excepting cases where the admins have manually placed such entries into the local DNS). 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. some IP - in-addr lookup - localhost - FAIL (because localhost isn't in DNS, and thus the test failed because the name listed in the PTR record doesn't resolve to an A record) vs some IP - in-addr lookup - localhost - FAIL (because localhost is a forbidden result) vs some IP - in-addr lookup - localhost - 127.0.0.1 - FAIL (because locally we do have localhost in DNS, and 127.0.0.1 isn't the IP address we started with) vs some IP - in-addr lookup - localhost - 127.0.0.1 - FAIL (because locally we do have localhost in DNS, and 127.0.0.1 is a forbidden result) 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.
Re: FCrDNS and localhost
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
Re: FCrDNS and localhost
On Wed, 3 Jun 2009, Adam Katz wrote: Matus UHLAR - fantomas wrote: 181.188.252.222.in-addr.arpa domain name pointer localhost. That is why FcRDNS is being used everywhere... localhost has address 127.0.0.1 = fail. Actually, localhost doesn't resolve via DNS; it has no A record, nor any other record type. It resolves locally without using DNS; see your /etc/hosts file. Similarly, 1.0.0.127.in-addr.arpa. has no PTR record indicating it should be called localhost. I think what Matus was saying is: 181.188.252.222.in-addr.arpa - localhost - 127.0.0.1 = FAIL. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- North Korea: the only country in the world where people would risk execution to flee to communist China. -- Ride Fast --- 3 days until the 65th anniversary of D-Day
