nslookup from WinNT machine

[Kevin Darcy]

Brad Knowles wrote:

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

I've been ignoring them because if they're not PTR-based they didn't seem relevant to
the PTR issue. But now that you bring them up, why not use *those* mechanisms and
drop the blecherous PTR-based one?

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

I don't see that PTR-verification really "interlocks" with any of the other
mechanisms; seems like it just subjects delivery/connection attempts to yet another,
more-or-less independent dice roll. If the other mechanisms work fine, then why not
get rid of the one which is most subject to false rejections and obsolescence?

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

Again, you're mischaracterizing my statements to be much more absolute and extreme
than I originally expressed them. I'm sure PTR-verification prevents *some* spam.
Today. But as the spammers get more sophisticated, it'll probably prevent less and
less of it. That number will probably never drop to 0%, but if it drops to, say, 1%
or 0.5%, and the false-rejection rate is several times that, wouldn't you agree it's
time to get rid of it in favor of more sophisticated and accurate mechanisms? The
only difference, I think, between my perspective and your (if I may characterize as
ISP-oriented) perspective is that we (DaimlerChrysler) are perhaps further along that
timeline than most because of our relative tolerance of spam versus false-rejection.
But I think eventually almost everyone will eventually reach the same point (unless
their tolerance for spam is *extremely* low); it's just a matter of _when_.

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

Yes, I agree with the strategy of implementing multiple security measures. I just
don't think that PTR-verification makes the cut as a measure which is worth the
effort and (false-rejection) risk to implement as part of that suite. At least not
for us. And probably not for a lot of other companies as well. And looking to the
future, I think PTR-verification will eventually become obsolete.

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

Sorry, but I have to correct you there. I *am* free to do so, unless and until
someone kicks me off the list.

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

Oh, please. Aren't you getting a little carried away? It's not like people are going
to trample each other to death deleting their PTR records...

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

I'm not saying that *everything* needs to be authenticated. In the case of something
like SMTP, oftentimes authentication is not necessary, and if it is necessary, it can
be done at the message-level (using PGP or whatever) instead of at the
transport/connection level. What I'm saying is that source-IP-based authentication
should be discouraged in favor of cryptographic authentication, and inasmuch as
maintenance of reverse DNS encourages the use of source-IP-based authentication, it's
actually a hindrance to security rather than a benefit. This is in response to your
claim that maintaining reverse DNS enhances authentication. It may help slightly in
the spam-prevention context, but IMO those gains are more than offset by the negative
effects reverse DNS indirectly has by fostering bad remote-login/remote-execution
authentication practices.


- Kevin