nslookup from WinNT machine

[Brad Knowles]

At 4:00 PM -0400 5/30/01, Kevin Darcy wrote:

>  But, as I understand it, you don't need to own your *own* reverse DNS. The
>  PTR-based mechanisms I've seen just verify that the address reverse-resolves
>  to *something*. So ISP's that just give placeholder names (e.g.
>  123-abc-dialup-podunk.someisp.net) to all of the addresses in the dialup
>  pools, defeat the mechanism quite handily.

	There are additional anti-spam mechanisms which you seem to be 
ignoring.  They include validating that the claimed relay name 
actually matches what was found in the DNS (typically done through 
procmail or other after-the-fact filters, and not as an interactive 
part of the SMTP dialog, although some servers have been configured 
to do even that).  They also include things like refusing to accept 
mail from any IP address that is on a known dial-up network, through 
things like the MAPS DUL.

	Requiring reverse resolution to work is just one of a number of 
interlocking strategies that, when combined, are far more effective 
than when any of them are used alone.

>  Yes, as I said, when email *is* your business, you care more about such
>  things. But most companies are in some other line of business and email
>  is just a tool that they use.

	Most companies probably don't have multi-billion dollar annual 
revenue sources to consider.  When you compare the cost of your 
e-mail system to the overall revenue generated by your company, even 
if it became a hundred times more expensive for you do handle e-mail 
for the company, that would still be a drop in the bucket.

	However, most companies don't operate on profit margins that fat, 
and a 25% reduction in spam (and therefore a 25% reduction in the 
cost of running their mail system) could mean the difference between 
turning a profit or not, and being in business or not.  Actually, 
it's not really a 25% reduction in costs, using it is *preventing* a 
25% increase in costs, which is actually a considerably larger number.

>  My main point here is that PTR-based anti-spam mechanisms aren't really
>  feasible in the long haul. So their use doesn't really justify the
>  maintenance of PTRs.

	Just because this particular mechanism is not of value to you 
does not mean that it is totally worthless universally, and 
everything that could possibly be used to support it should be 
scrapped on your personal whim.

>  Some ISPs are spammer-friendly and don't really care whether their
>  customers send spam or not. So how does a PTR-based mechanism help
>  you there?

	It's part of something called "defense in depth".  You may or may 
not have heard of this premise, but it's basically what the Germans 
*didn't* have during D-Day.  They were attacked at their weakest 
point, and everything possible was done to keep it as weak as 
possible for as long as possible, until such time as the Allies could 
get their forces ashore, and start the arduous journey towards 
destroying the Third Reich.

	Defense in depth is also a common recommended strategy by 
Internet security experts around the world.


	In this particular case, we have other tools that we use to deal 
with problematical ISPs.

>  Sounds like you're trying to cast blame on us. Hey, if we don't want to
>  use a flawed, near-obsolete anti-spam mechanism, nobody says we have to.
>  Come up with something better, and we'll consider it.

	When it comes to anti-spam techniques, you are free to hold 
whatever opinions you may like, and you are free to implement 
whatever mechanisms you may choose.


	However, when it comes to methods that can be used to support 
anti-spam techniques at other sites (who have their own freedom to 
implement whatever anti-spam techniques they may choose), you are 
*NOT* free to disparage them or to actively discourage their use.

	Especially not when those methods are recommended at the highest 
level by the guys who invented the DNS, and by the guys who have 
taken on the mantle since then of continuing to develop the DNS 
infrastructure to support further development of the Internet.


	If you want to do that, you should do so in private, and on the 
same mailing lists that these current experts frequent, and work to 
get your personal private agenda reflected in the next revision of 
the DNS standards.

	Until then, you're basically a moron yelling "fire!" in a crowded theatre.

>  We implement RADIUS for remote access, and Kerberos internally, and we
>  have an official security policy forbidding source-IP-based authentication
>  for remote login or remote execution. Good enough?

	Nope.  None of those do a damn bit of good for authenticating 
other types of connections, such as SMTP.  You still have to turn off 
all SMTP that does not use SMTPAUTH or TLSSMTP, among all the other 
communications services that are not likewise authenticated.  Also 
make sure that you turn off the use of all DNS records that are not 
cryptographically signed.

	And even once you've turned off every form of communication that 
is not cryptographically authenticated, you still have to wait for 
the rest of the world to catch up.

-- 
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,$_)}'