Subject: RE: [Asrg] Amend the RFC to require reverse DNS

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 18 Mar 2003 13:51:28 -0800

I do not believe that the user community is likely to take any notice.

Operational injunctions of this sort are the type of thing that the ISPs
and the general user community tend to push back on severely.

There is no existing protocol that depends on reverse DNS. As a result 
the reverse DNS is only deployed to a degree that supports advisory and
debugging type uses. Any proposal that depends on the roll out of a
production reverse DNS is requiring the hard 90% of a major infrastructure
deployment.

Another problem is knowing what the reverse DNS is telling you. All you
can do is to map an IP address to a domain name (or names). That gives
zero information about the authenticity of the information concerned.
A spammer can insert false information in the reverse DNS without obstacle.

Another practical deployment problem is the fact that a single IP can 
serve, hundreds, thousands or even tens of thousands of mail domains.
So how does the reverse DNS tell you anything of interest?

Yet another problem is that in many cases control over the reverse DNS does
not lie anywhere close to the end user. I have zero control over the 
reverse dns for the IP address I rent from Comcast. It is actually set
to an address that depends on the ethernet mac address of my nic...

But strip off the host part of the domain and I have a reverse DNS that
looks like I am in the comcast domain.

Assigning a reverse DNS name does not today imply any intention on the 
part of the reverse IP address maintainer to authorize any use for the
domain. 

		Phill

-----Original Message-----
From: M Wild [mailto:[email-masked]]
Sent: Tuesday, March 18, 2003 11:04 AM
To: [email-masked]
Subject: [Asrg] Amend the RFC to require reverse DNS

Greetings - One of the most effective anti-spam measures I have taken on my
mail servers is to require the sending mail server's IP address to reverse
resolve to the name it uses in its HELO command.  While this is a violation
of the RFC it eliminates lying machines and forces accountability on the
sending server.  Yes, I know it can be forged or spoofed however it still
significantly raises the level of effort required on the part of the
spammer.  I've had to turn this check off due to customer complaints however
I am reconsidering this decision.  Amending the RFC to *REQUIRE* correct and
complete DNS setup for a SMTP client would go a long way towards reducing my
undesired traffic.  It would also address the customer (and clueless
administrator) complaints with a simple "I am following the rules"  How can
you argue with that?

Regards
Mike

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

---

From: "Ronald F. Guilmette" <[email-masked]>
Date: Tue, 18 Mar 2003 15:56:02 -0800

In message <[email-masked]>,

>part of the reverse IP address maintainer to authorize any use for the

Yes, quite so.

Most specifically, _either_ the presence or, conversely, absense of
rDNS doesn't clearly designate a given IP address as being one which
either the ``owner'' fully intends to act as an outgoing mail server
or conversely as one which the owner DOES NOT intend to act as a mail
server.

But it is often helpful to be aware of exactly such a distinction.  at
the present time, large amounts of spam come from either (a) end-luser
broadband lines where the end-lusers in question are running unsecured
proxy servers (and where they are not even aware that their machines
can send e-mail, directly, via SMTP, to arbitrary other places) or else
(b) from end-luser dialup lines.

I have a simple idea that could be used to classify SMTP client as being
either ``intentional outgoing mail servers'' or not.  And this idea is
largely compatible with existing practice.

Quite simply, if a given SMTP client connects to you and then says:

	HELO d.e.f.g

then you look to see if any of the following names have associated MX
records:

	d.e.f.g
	e.f.g
	f.g
	g

For all MX records found for any of these names, if any of the FQDNs
in any of the MX records resolve to the IP address of the SMTP client
in question, then you know that it is an ``intentional mail server''.
Otherwise, it probably isn't.

My own outgoing mail server... and MANY others... would pass this simple
test, because it greets via `HELO mail.monkeys.com', and if you look for
MXes associated with these FQDNs:

	mail.monkeys.com
	monkeys.com
	com

you will find that the FQDN `monkeys.com' has one, and that it resolves
to the IP addres of my outgoing mail server.  Case closed!  My mail server
_is_ a mail server, and it is a mail server NOT accidentally, but by my
explicit intent.

OK, now somebody will ask  ``What about this thing that just greeted my
incoming mail server as `imo-97.mx.aol.com'.  That is an outbound-only
server for a MAJOR domain and all of the given domain's _inbound_ MXs
are at totally different IP addresses.

No problem.  We just have to figure out some inducement to get AOL
to create a (pseudo) MX record for the FQDN `imo-97.mx.aol.com'...
something like `pseudo-mx.imo-97.mx.aol.com', and then define an
A record for that that points, specifically, to the `imo-97.mx.aol.com'
server.  If they do that, then they will pass the ``Is this an intentional
mail server'' test also.

One last point:  End-lusers on dynamic dialups _could_ theoretically
pass this test also, *if* they make clever use of one of these so-
called ``dynamic DNS'' services.  But there is an esay way to defeat
such shenanigans.  All you have to do is to force your lookups (first
of the MX records and later of the A records associated with those) 
to require ``authoratative'' answers.  Then check the TTLs in those
answers.  If it is 5 minutes or less, then they guy is on a dynamic
dialup line and is using a dynamic DNS service.  Otherwise, he isn't,
and you can count of that mail server being at that same location
for awhile... probably a long while.

---

From: [email-masked] (Claus Färber)
Date: 19 Mar 2003 00:00:00 +0000

> Otherwise, it probably isn't.

In larger email setups, the sending mail host often is not identical to
the hosts that are listed as MX records, for example:

. usersmtp.example.net is the MTA for customers of the ISP example.net
  (with different domains) but ownsmtp.example.net handles mail for own
  mail of the ISP.
. mailin.example.com handles incoming mail (and is the MX) but
  mailout.example.com handles outgoing mail.
. a multihomed host receives mail on one IP address (listed as MX) but
  does use different IP addresses for sending.

Claus
-- 
http://www.faerber.muc.de/
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg