You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Adam Katz <an...@khopis.com> on 2009/06/04 01:31:54 UTC
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.
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.
> 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
score KHOP_MAYBE_FORGED 0.8 # 20050802, raised 0.15->0.8 20090603
# Violates rfc2821? See http://en.wikipedia.org/wiki/FCrDNS#Uses
header KHOP_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.
$ host -t TXT localhost.
localhost has no TXT record
$ host -t TXT localhost.localdomain.
localhost.localdomain has no TXT record
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.
--
Adam Katz
khopesh on irc://irc.freenode.net/#spamassassin
http://khopesh.com/Anti-spam
Re: FCrDNS and localhost
Posted by Benny Pedersen <me...@junc.org>.
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
Posted by Bob Proulx <bo...@proulx.com>.
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
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> 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, uhlar@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
Posted by mouss <mo...@ml.netoyen.net>.
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
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> 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, uhlar@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
Posted by Bob Proulx <bo...@proulx.com>.
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
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
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, uhlar@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
Posted by Adam Katz <an...@khopis.com>.
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
Posted by mouss <mo...@ml.netoyen.net>.
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
> score KHOP_MAYBE_FORGED 0.8 # 20050802, raised 0.15->0.8 20090603
>
> # Violates rfc2821? See http://en.wikipedia.org/wiki/FCrDNS#Uses
> header KHOP_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
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Re: FCrDNS and localhost
Posted by Adam Katz <an...@khopis.com>.
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, D&D, 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
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Thu, Jun 4, 2009 at 16:32, Adam Katz<an...@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, uhlar@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
Posted by John Rudd <jr...@ucsc.edu>.
On Thu, Jun 4, 2009 at 16:32, Adam Katz<an...@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
Posted by Adam Katz <an...@khopis.com>.
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
Posted by John Rudd <jr...@ucsc.edu>.
On Thu, Jun 4, 2009 at 13:57, Adam Katz <an...@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
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by mouss <mo...@ml.netoyen.net>.
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
Posted by Adam Katz <an...@khopis.com>.
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
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by Adam Katz <an...@khopis.com>.
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
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> 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, uhlar@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.