RE: educating rDNS violators

["David Gillett" <gillettdavid () fhda edu>]

  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
----------------------------------------------------------------------------