RE: educating rDNS violators

[LordInfidel () directionweb com]

I am not sure how RDNS and security for e-mail are interrelated, but RDNS
~does~ not offer any security to your mail server, In fact:

1. RDNS does not prevent malicious attacks ~directed~ against your mail
server.

2. While RDNS does help prevent Spam, to say that it also prevents e-mail
borne viruses is a stretch.
Use the right tools when trying to prevent e-mail borne virii, RDNS is not
the right tool; AV software at the mail gateway, extension blocking at the
mail gateway and AV on the client are.

3. RDNS is *NOT* part of RFC822/821, which governs SMTP transmissions.  See
#6.

4. RDNS *will* block legitimate e-mail.  You must be willing to accept the
fact that you will not receive legitimate e-mail from locations that you
want, and be in violation of the RFC.

5. not using RDNS should not be confused with running an openrelay. They are
2 distinctly separate issues.  You can run a secure mail server without
requiring RDNS lookups on every inbound connection to your server.

6. Section 5.2.5 of rfc1123 covers this quite explicitly.  Rejecting mail
based on RDNS ~~~***VIOLATES***~~~ the RFC:
http://www.faqs.org/rfcs/rfc1123.html

5.2.5  HELO Command: RFC-821 Section 3.5

         The sender-SMTP MUST ensure that the <domain> parameter in a
         HELO command is a valid principal host domain name for the
         client host.  As a result, the receiver-SMTP will not have to
         perform MX resolution on this name in order to validate the
         HELO parameter.

         The HELO receiver MAY verify that the HELO parameter really

RFC1123                  MAIL -- SMTP & RFC-822             October 1989

<!------This is the part here covering RDNS----->

         corresponds to the IP address of the sender.  However, the
         receiver MUST NOT refuse to accept a message, even if the
         sender's HELO command fails verification.

         DISCUSSION:
              Verifying the HELO parameter requires a domain name lookup
              and may therefore take considerable time.  An alternative
              tool for tracking bogus mail sources is suggested below
              (see "DATA Command").

              Note also that the HELO argument is still required to have
              valid <domain> syntax, since it will appear in a Received:
              line; otherwise, a 501 error is to be sent.

         IMPLEMENTATION:
              When HELO parameter validation fails, a suggested
              procedure is to insert a note about the unknown
              authenticity of the sender into the message header (e.g.,
              in the "Received:"  line).

Enjoy,

LordInfidel


-----Original Message-----
From: Derek Schaible [mailto:dschaible () cssiinc com]
Sent: Friday, August 27, 2004 6:46 AM
To: Niek
Cc: security-basics () securityfocus com
Subject: Re: educating rDNS violators


On Thu, 2004-08-26 at 03:03, Niek wrote:
> On 8/25/2004 1:08 PM +0200, Derek Schaible wrote:
>
> > on their DSL or cable modem. Such hosts will typically not have a valid
> > rDNS entry. Additionally, if a company is sending legitimate email they
> In my experience almost all 'western' isps have rdns set on their customer
> broadband/dialup ipranges. Sometimes an isp was assigned a new block,
> it can take a while, but it usually gets in place.
>
> Rdns is however missing on the majority of Asian ipblocks.
> I block China, Korea, and a few other countries with dns blacklists.
> 90% of the blocked Asian ips do not have (valid) rdns.
> Names of smtp servers will still be spoofed even if rdns is in place.
> Only something like caller-id/sender-id/spf/domainkeys/'something better
> than before mentioned' solutions will help cut it down a bit.
>
> Moral of this all.
> If you decide to block hosts with missing or incorrect rdns,
> you will loose mail. Period.
>
> If you decide to block hosts with missing or incorrect rnds,
> you will still receive spam. Period.

I disagree and I think we are missing the fact that this is a "security
basics" lists. One basic step you can take to secure your email
communications is to implement rDNS lookups. This is by and large a
standard practice advocated on many other lists, qmail lists certainly
do.

We are here to provide new comers to security with "basic" steps and
information. Setting up rDNS for your email is one we should be
advocating, not excusing. If you are in some bizarre situation where
this is not possible, we should be telling people to pressure their ISPs
to provide them with an SMTP relay that has proper rDNS info. Even if
you want to run your server with no rDNS - do so, but use that rDNS
friendly relay and the world will get your mail - its too simple to
excuse not doing it.

If your ISP is unwilling to take this step, I'd be very concerned about
what other simple, "_basic_" security measures they are too lazy to
implement for their customers. Let's not advocate excusing it, let's
advocate fixing it. This thread is also about "education", remember.

Not only does implementing rDNS filtering at your site reduce spam, but
it will also reduce other malicious, mail-born attacks. You can't tell
me otherwise. Personal experience showed me an 80% or higher success
rate of dropping spam/attacks from these ill-configured servers. I'm
sure I'm not alone.

As advice to those who are learning about security: rDNS does help
verify you're who you say you are. It is a valid method for filtering
mail. Is it perfect? No. None exists as of yet, but every step helps.
You should look into properly configuring DNS for many reasons, not just
spam and other email concerns. You should aid your clients to do so as
well. You should use an SMTP relay that resolves its name in rDNS if one
is not available at your site.

If you don't take these steps, don't complain that some sites summarily
drop your mail. It's their prerogative. Personally, at my location we
have zero complaints of loosing legitimate mail due to rDNS. I've lost
legitimate email because a client was erroneously placed on a blackhole
list. I'm not about to advocate dropping RBLs. I've lost legitimate mail
through commercial spam filter products. You work with it, you deal with
it. 

As security professionals, it is our job to do so and advocate smart
security measures. rDNS should not be left off that list.

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