Subject: [Asrg] Wierd reverse DNS resolution might affect spam filters

From: "Douglas Campbell" <[email-masked]>
Date: Fri, 23 Jun 2006 09:01:01 -0700 (PDT)

Just noticed something really strange show up in my milter logs:

2006-06-23 08:15:09.589901-07:00 [mx]
connect(821,localhost,[222.252.168.54]) 1
2006-06-23 08:15:09.968668-07:00 [mx]
helo(821,2g4i9a.oq4ihijo.comcast.net,invalid)
2006-06-23 08:15:10.453522-07:00 [mx]
envfrom(821,argv[0]=<[email-masked]>)
2006-06-23 08:15:10.489847-07:00 [mx]
envrcpt(821,argv[0]=<[email-masked]>)
2006-06-23 08:15:10.829801-07:00 [mx]
header(821,Message-ID,<53327639439490.8D11BD6FB3@OQTQ>)
2006-06-23 08:15:10.869782-07:00 [mx] header(821,From,"Wilda"
<[email-masked]>)
2006-06-23 08:15:10.909778-07:00 [mx] header(821,To,<[email-masked]>)
2006-06-23 08:15:10.949778-07:00 [mx] header(821,Subject,Hottest new offer
Diplomas Without Exams)
...

Notice the "connect" line -- it appears that reverse DNS is resolving the
offered IP address to "localhost".  samspade.org also reverse DNS's the ip
address to "localhost".  In fact, a sampling of the entire address block
containing the IP address (222.252.0.0/16) indicates that ALL the hosts in
the block are "localhost".  It might be a misconfiguration by Vietnam
Posts and Telecommunications Corp (the owner of the netblock), or a
deliberate configuration.

In any case, spam detectors who rely on "localhost" as the reverse lookup
for an IP address as a condition of passing the e-mail are at risk of
producing false negatives.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 23 Jun 2006 18:15:34 +0200

> producing false negatives.

Reverse lookups fortunately works a bit different:
(unless wrongly implemented)

1) IP address (a) -> Hostname
2) Hostname -> IP address (b)
3) Compare IP address a + b -> reject hostname if no match
4) accept hostname

As such 'localhost' in step 2 resolves to 127.0.0.1 (or ::1 ;) and the
hostname should get rejected, or at least noted, but not used for any
security stuff.

Greets,
 Jeroen

---

From: David Wilson <[email-masked]>
Date: Fri, 23 Jun 2006 17:34:16 +0100

> producing false negatives.

Some years ago a colleague told me that some resolvers, when doing rDNS
lookup with then perform a forward lookup of the hostname, to check that
the A records for the name contain the IP address with which you
started.

Does anyone know if this is true (if so, which)?

If not true, perhaps it is something which SMTP servers should do
themselves, before using the rDNS name for authorization.

A mismatch in the round-trip rDNS->DNS would be a sign of a suspicious
host, as well.

Can anyone foresee an issue with this?

cheers

David Wilson

---

From: Tony Finch <[email-masked]>
Date: Fri, 23 Jun 2006 19:26:03 +0100

>the A records for the name contain the IP address with which you

I believe this is usually done in the applications rather than in the
resolver itself.

>themselves, before using the rDNS name for authorization.

What do you mean "perhaps"? Decent MTAs (e.g. Exim) have been doing this
for many years.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
DOGGER FISHER: SOUTHWEST 4 OR 5. SHOWERS. MAINLY GOOD.

---

From: Bill Cole <[email-masked]>
Date: Fri, 23 Jun 2006 20:48:46 -0400

At 7:26 PM +0100 6/23/06, Tony Finch  imposed structure on a stream 
>What do you mean "perhaps"? Decent MTAs (e.g. Exim) have been doing this

And see http://www.sendmail.org/faq/section3.html#3.38

Note that the date is the date that entry made it into the FAQ, not 
the implementation date. Sendmail has been noting such errors in 
Received headers since 8.8.6, almost exactly 10 years.

Basically, this is a non-issue. Reverse DNS has never really been 
trustworthy, and trusting an unverified rDNS result by itself for 
authentication is an unlikely error for any serious piece of modern 
software.

-- 
Bill Cole
[email-masked]

---

From: der Mouse <[email-masked]>
Date: Sat, 24 Jun 2006 22:13:49 -0400 (EDT)

> 2006-06-23 08:15:09.589901-07:00 [mx] connect(821,localhost,[222.252.168.54]) 1

> Notice the "connect" line -- it appears that reverse DNS is resolving
> the offered IP address to "localhost".  [...]

> In any case, spam detectors who rely on "localhost" as the reverse
> lookup for an IP address as a condition of passing the e-mail are at
> risk of producing false negatives.

Anyone who does anything with untrusted rDNS without making sure it
crosschecks with fDNS is at risk of misfires (either way).

That is, given an address, you do an rDNS lookup and get a set of names
(usually zero or one, but not always).  Do fDNS lookups on those,
resulting in a set of addresses for each one; any which do not include
the original address in their sets should be discarded.  (If this
leaves zero names, well, treat the IP as having no rDNS.)

Anything else is asking for misfires.

I'd almost go so far as to say that if any of the names fail that
crosscheck, they *all* should be discarded (since it implies there is
forgery going on), but the net is not that well run; in addition to
forgery, there are still far too many version skews, mistakes, and
providers that don't bother to set up the one or the other....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Seth Breidbart <[email-masked]>
Date: Sat, 24 Jun 2006 23:05:39 -0400 (EDT)

der Mouse <[email-masked]> wrote:

> That is, given an address, you do an rDNS lookup and get a set of
> names (usually zero or one, but not always).  Do fDNS lookups on
> those, resulting in a set of addresses for each one; any which do
> not include the original address in their sets should be discarded.
> (If this leaves zero names, well, treat the IP as having no rDNS.)

Should following CNAMEs be included here?  I can see arguments both
ways.

Seth

---

From: der Mouse <[email-masked]>
Date: Sun, 25 Jun 2006 12:25:46 -0400 (EDT)

>> names ([...]).  Do fDNS lookups on those, resulting in a set of
>> addresses for each one; any which do not include the original
>> address in their sets should be discarded.

I would say CNAME following should be done as normal, both de-jure (the
DNS spec says that CNAMEs should be followed whenever the query type is
neither CNAME nor ANY - see RFC 1034 3.6.2) and de-facto (RFC2317-style
delegation for the reverse, and lots of things for the forward).

I'd be interested in what arguments you see for not following CNAMEs.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign