Re: Final Words on "Educating RDNS violators" - Debunking the Myth's

[Derek Schaible <dschaible () cssiinc com>]

My last thought on this issue:

While LordInfidel's comments are true, I still advocate that DNS should
be properly setup for any SMTP service. Many, many, many places do
filter on this. Here's why:

1. First and foremost, it does tremendously aid in spam reduction
*before* the messages reach your filtering program, thus reducing cpu
cycles.

2. It does prevent a large number of email-borne viruses before they
reach your virus scanner, thus reducing cpu cycles. Why do I say this,
when we know it is not a virus scanner? Because like much spam, viruses
are frequently sent out en masse from systems that will fail this simple
rDNS test - stopping them from reaching the server. Of course this is no
protection from a directed attack. But it makes your resources more
efficient in some capacity to deal with a directed attack. And that's
the name of the game.

Now, it is true that this is far from a fool proof scheme but many of us
use this method because a perfect system as of yet does not exist. This
is one technique of many that you can employ. Some may argue that rDNS
will block valid mail. There is that possibility. Consider, however,
that virtually any filtering method has this possible side effect. I can
only report that in my experience I've had no reports of missing valid
customer email due to rDNS filtering. I have, however, lost valid
customer email because they ended up on a blacklist erroneously, which
can be difficult to be removed from, often taking up to 72 hours before
your removal is successful! Any votes to stop the RBL movement?

Another consideration: There are many debates over what will be the best
method to stop spam. There is little agreement on what technology will
eventually win. Many of these technologies will in some way or another
rely on proper name resolutions. As a result, the day will inevitably
come when all ISPs must provide accurate name services for their
customers. Now is the best time to start anyway. 

Whether you like the thought that people such as myself employ rDNS
filtering or not is moot. If you don't like, I'm still going to do it.
I'm not the only one who will take this position either. The real answer
is to demand proper service from your ISP in some manner. There are some
places out there that don't provide this service and laziness really is
the only excuse.

And I am done with this thread.

Still happily dropping mail via rDNS,
- Derek

On Tue, 2004-08-31 at 17:38, LordInfidel () directionweb com wrote:
> There has been many a discussion on this list about RDNS relating to the
> security of mail servers.  This is an attempt to dispel the myth's that have
> sprung up from this thread.
>
> First off, the use of RDNS boils down to the prevention of spam.  Very few
> valid reasons for the use of RDNS and SMTP communication exists, and general
> security is not among those reasons.  This (spam prevention) is the main
> reason why the developers of MTA products include it in their respective
> packages(exchange, procmail, qmail, sendmail, postfix).
>
> With that said, I urge ~ALL~ readers of this list, regardless of whether you
> are pro RDNS or con RDNS. Read the RFC's that govern e-mail transmissions;
> RFC821 and RFC822, (superseded by 2822 and 2821), so that you can make a
> well informed decision on whether or not to implement RDNS.
>
> http://www.faqs.org/rfcs/rfc2821.html; http://www.faqs.org/rfcs/rfc2822.html
>
> Readers should pay Particular attention to
> http://www.faqs.org/rfcs/rfc2821.html Section 7.  Section 7 covers "Security
> Considerations" regarding electronic mail transmissions.  Additional focus
> should be turned to 7.7, as it sums up the use of Mail Servers better then I
> could paraphrase it.
>
> Additionally the policy of rejecting e-mail for any reason is covered in
> Section 5.2.5 of rfc1123, which, as I stated in a previous e-mail, covers
> this quite explicitly.  Rejecting mail based on RDNS (aka the failure to
> verify a mail servers identity) ~~~***VIOLATES***~~~ the RFC:
> http://www.faqs.org/rfcs/rfc1123.html

-- 
Derek Schaible <dschaible () cssiinc com>
CSSI, Inc.

Attachment: signature.asc
Description: This is a digitally signed message part