nslookup from WinNT machine

[Brad Knowles]

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.

>  I believe that in the case of AOL, you have your own in-house DUL.

	They have their own black lists, that's true.

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

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

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

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

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

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

-- 
Brad Knowles, <brad.knowles at skynet.be>

/*        efdtt.c  Author:  Charles M. Hannum <root at ihack.net>          */
/*       Represented as 1045 digit prime number by Phil Carmody         */
/*     Prime as DNS cname chain by Roy Arends and Walter Belgers        */
/*                                                                      */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob        */
/*   where title-key = "153 2 8 105 225" or other similar 5-byte key    */

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'