nslookup from WinNT machine

[Chris Buxton]

Brad,

You seem to have extensive experience with DNS and mail; so do I. My 
experience is evidently radically different than yours. Please 
consider the possibility that I may have information useful to you.

I agree with the basic premise that PTR records should be maintained, 
as a matter of courtesy. I disagree with the premise that they are a 
good way to validate email. Let me state the source of my opinion.

I provide tech support for QuickDNS, a commercial, easy-to-use DNS 
management system. I also provide tech support for DNS Expert, a 
commercial, easy-to-use DNS analysis and troubleshooting tool. I get 
questions every day from customers whose experience ranges from nil 
to advanced (but usually not expert). Many of our customers are small 
businesses or schools, often with a classless subnet. A question I 
get relatively often is, "Why did some message I (or my customer) 
sent bounce?" It's almost always because their ISP has screwed up the 
delegation in some way - many ISP's don't seem to have heard the 
phrase "classless subnet reverse zone". This is especially true 
outside of North America, Europe, and Australia. (We have customers 
on 6 continents.)

Put more bluntly, the failure rate caused by the mail filtering 
method we are discussing is unacceptably high to those whose non-spam 
messages fail. In a sense, use of PTR records for SMTP authentication 
is a form of discrimination against small businesses.

At 6:16 PM +0200 5/30/01, Brad Knowles wrote:
>At 6:34 PM -0700 5/29/01, Chris Buxton wrote:
>
>  >  Suppose someone wishes to spam your users. They get a dial-up
>  >  account, connect, figure out what their PTR record shows (as
>  >  configured by their ISP), and use that in their SMTP greeting. How
>  >  does your reverse lookup strategy stop them?
>
>	That's assuming that their ISP has reverse DNS set up for their
>dial-up lines.  Unfortunately (or fortunately, depending on how you
>look at it), many do not.

That is sometimes true, but not by any means always. This was a 
hypothetical case, not a blanket characterization of all spammers 
using dial-up accounts.

>  >  I believe that in the case of AOL, you have your own in-house DUL.
>
>	They have their own black lists, that's true.

And getting off it is well nigh impossible, according to the 
experiences of some of my customers.

>	However, since leaving AOL, I tend to implement the MAPS RBL,
>MAPS RSS, and MAPS DUL on all inbound mail servers I operate or
>configure, and MAPS RBL, MAPS RSS, and ORBS on all outbound mail
>servers I operate or configure (I don't like the ORBS, but the only
>way to ensure that you keep your mail servers off the ORBS is to
>configure them to use the ORBS themselves and then register them as
>known "mail hubs" with the ORBS project).

Very good; you've implemented all the other anti-spam measures. So 
why use PTR record authentication? Let me paste in your answer from 
another post in this thread:

At 1:29 AM +0200 5/31/01, Brad Knowles wrote:
>	Imagine having a firehose pointed at your head, and you manage to
>do something to get the amount getting through to be reduced by 25%.
>Only, the firehose doesn't stop, and if you let your guard down,
>you'll get blasted again by that part you had previously managed to
>block.
>
>	Meanwhile, there are other people who are working to get the
>pressure increased on the part that is getting through.  At that
>point, if you were to drop your guard, you'd feel a much greater
>increase than just an additional 25%, since it would now be a larger
>portion of a higher-pressure water flow.

Your logic is backwards, starting with, "At that point...."

Since new spammers would have tried other methods, and some of the 
old ones would have moved to other methods, dropping that guard 
should yield a smaller increase than what you initially stopped. 
Furthermore, since the overall flow has increased, by your own 
description, then the amount added by dropping your guard is less 
than 25% of the whole, even if it hasn't decreased.

>	More recently, AOL has started using transparent proxying for all
>of its own dialup customers, so regardless of what server you *think*
>you're contacting, you actually are shunted off to one of theirs,
>which will then accept the message and attempt to transmit it to the
>final destination.

Too many pronouns. I wasn't able to follow the preceding in the 
context of this discussion.

We're not talking about AOL users having their own mail servers. 
We're talking about AOL users whose account is <someuser at aol.com>.

>Of course, AOL also requested that this
>transparent proxy server be added to the MAPS RBL, so there are a
>significant number of sites out there that will refuse to accept the
>message anyway.

Message going from whom to whom?

>  >  [Please correct me if I'm wrong - several of my customers would like
>  >  to know if there is some other reason their mail to AOL accounts is
>  >  sent to the bit-bucket without so much as a bounce message.]
>
>	I believe that this is now the default with AOL mail -- you
>provide them a list of addresses that you will accept mail from, and
>they silently trash anything coming from any other address.  Of
>course, you can always change this default if you want, but 99.9% of
>the people probably don't even know about it, much less know how to
>change it.

Would you like to explain that again? Are you saying that any AOL 
user who doesn't configure this filter doesn't get any mail 
whatsoever?

The reason I believe PTR records should be maintained is, as someone 
else posted, as a matter of courtesy. Similarly, silently trashing 
email, with no bounce message, is extremely discourteous behavior.

>  >                                                                But that
>  >  just tells me that the PTR lookup isn't helping you.
>
>	The PTR lookup is only one of the many techniques I use.

So you keep saying. See my next comments.

>  >  Now suppose someone sets up a mail server and tries to send
>  >  legitimate (non-spam) mail to one of your users. But suppose their
>  >  NSP can't find their rear-end with both hands, and doesn't even have
>  >  the reverse zone delegated to themselves, let alone delegating a
>  >  classless subnet reverse zone to their customer. There is no PTR
>  >  record for the address, so your server rejects their mail. How is
>  >  this beneficial to you, your users, or the net community at large?
>
>	I've watched the log files of mail servers that I've configured
>to use PTR lookups, and I've seen a very, very low rate of false
>positives.  Low enough that it doesn't begin to show up on the radar
>of the "Top Fifty" problems that are found in the logs by the log
>analysis programs I use.

How does your software identify a false positive? If there is some 
means to do so in an automated fashion, why doesn't your mail server 
use this to prevent the problem?

>	Therefore, I am not concerned about this problem.  There are far,
>far bigger problems that I have to worry about.

Let me explain why I think this is such a small problem for you 
(based on my experience in tech support, talking to the people 
affected by this):

- Your users almost never know that legitimate messages addressed to 
them didn't reach them.

- When they do find out, they usually don't have any idea why.

- Even if they somehow figure out the basic cause (your mail server 
rejected the message), they point the finger at the other mail server 
or DNS setup. However, getting this far is pretty rare for 
nontechnical users.
____________________________________________________________________

Chris Buxton <cbuxton at menandmice.com>

Men & Mice <http://www.menandmice.com/> provides:
  - DNS training, including Active Directory
  - QuickDNS, a DNS management system for servers on Linux & Mac OS
    (Solaris support coming soon!)
  - DNS Expert, a DNS analysis and troubleshooting utility
____________________________________________________________________