It seems to me that there are two questions that a receiving
SMTP server might try to use the distributed DNS database to
answer about a remote machine that has just connected to its
SMTP service:
1. Does the hostname provided in the HELO/EHLO resolve?
2. Does the IP address resolve (via rDNS)?
These are easy and fast -- and, these days, the answers are
likely to be "Yes" even for spam and SMTP-borne viruses.
There are two deeper questions we might prefer to ask:
1A. Does the hostname resolve to this IP address?
It still seems that a lot of spam I get tries to fake this in one
form or another, often supplying the IP or hostname of the recipient
server in its HELO. So this EASY check would still be pretty effective.
2A. Does the IP resolve, via rDNS, to this hostname?
For an awful lot of systems, this is not currently true -- nor is
it an error! It is perfectly legal for multiple hostnames/aliases
to resolve to the same address/machine, but usually only one will
be found via rDNS. And since it's hard to delegate rDNS except at
octet boundaries, many organizations must rely on someone else to host
and maintain rDNS for their addresses....
There was a time, when the net was young, when it was fairly safe to
assume that clients did not have rDNS entries, and vice versa. And
while some ISPs may still be reluctant to provide rDNS for their clients'
servers, many more seem to be willing to provide "generic" rDNS results
for their entire delegated address space, just to avoid breaking email.
(Many servers ask question 2, not 2A....)
The result is that rDNS in the form of question 2 has lost virtually
all of the anti-spam value it once had, and so we see some push toward
2A. But I suggest that 1A is actually a better choice, and sidesteps
virtually all of the objections to rDNS that some people have raised.
David Gillett
-----Original Message-----
From: Derek Schaible [mailto:dschaible@cssiinc.com]
Sent: Wednesday, August 25, 2004 11:20 AM
To: security-basics@securityfocus.com
Subject: Re: educating rDNS violators
On Wed, 2004-08-25 at 13:55, someone wrote:
This becomes even further complicated if a company is hosting with
somebody who provides "virtual domain" mail hosting. The
server could
be mail.somefamily.net, but have a reverse DNS entry that points to
mail.myprovider.net. How is that invalid? Just because the records
don't match doesn't make me a spammer!
Mail servers should have correct DNS info. Forward and
reverse. It is
the sysadmin's responsibility to ensure that their systems are
configured properly. Period.
I wanted to respond to this point to the list before I get
flooded with
similar replies.
True, such a situation does not make you a spammer but using a virtual
domain will in no way impact the reverse DNS of the smtp server from
which the email is delivered. Reverse DNS is not matching the
address of
the smtp server to the domain name in the email address. This would
break many things like reply-to, etc.
All it is doing is verifying that the server is who it claims to be.
Virtual mail domains are not impacted. I run many virtual
email domains
as well for every website we host. These accounts can happily
send mail
through our company's SMTP server, arrive in tact and survive an rDNS
lookup.
As I've stated earlier, filtering out mail from servers with
a bad rDNS
will dramatically reduce your spam and that's a fact to live by. There
is always a means in which you can configure a valid email system that
will pass this test. Some require more imagination than others, but it
can always be done and should always be done if you want to guarantee
that your mail will be delivered and not rejected.
--
Derek Schaible <dschaible@cssiinc.com>
CSSI, Inc.
---------------------------------------------------------------------------
Computer Forensics Training at the InfoSec Institute. All of our class sizes
are guaranteed to be 12 students or less to facilitate one-on-one
interaction with one of our expert instructors. Gain the in-demand skills of
a certified computer examiner, learn to recover trace data left behind by
fraud, theft, and cybercrime perpetrators. Discover the source of computer
crime and abuse so that it never happens again.
http://www.infosecinstitute.com/courses/computer_forensics_training.html
----------------------------------------------------------------------------
