nslookup from WinNT machine

[Kevin Darcy]

Brad Knowles wrote:

> At 5:55 PM -0400 5/29/01, Kevin Darcy wrote:
>
> >  As for the general practice of mailers refusing mail from IP addresses
> >  that don't reverse-resolve, I consider that one of the crudest and most
> >  false-rejection-prone anti-spam mechanisms ever dreamed up.
>
>         Contrariwise, being the original Senior Internet Mail Systems
> Administrator for AOL, and one of the originators of many of the
> early anti-spam techniques, I consider it to be one of the most
> effective (and simple) measures available.

Oh, so *you're* the one responsible! :-)

>         There is no way I would even consider setting up a mail server
> without turning on this feature -- certainly, I wouldn't do so except
> under extreme pressure, and even then I would only do so under
> violent protest.

As you may recall from one of our early disagreements (over forwarding and
centralized caching, I believe), our environment here -- and I think it's
probably quite typical of other large companies -- is very "un-ISP" and
oriented towards using email as a *tool* in our mainline business rather than
selling it as end product/service. As such, the focus is on delivering as much
mail as possible, rather than maximizing the subjective "quality" of the email
delivered (i.e. by "sanitizing" spam from it). When it comes to email, it's
quantity over quality, basically. The last thing I need is to have to explain
to the VP of Manufacturing why a plant was idled because my mail servers
rejected a trading partner's email due to PTR cruftiness. Do you think he
cares about that? Do you think he gives a damn whether a little spam trickles
through here and there? What he cares about is that we can talk reliably with
our trading partners so that we can keep our plants running. Spam may be
expensive, but plant downtime is *REALLY* expensive. Obviously this is a
different focus from an ISP. I'm not saying everyone should have the same
level of spam-tolerance. I'm just pointing out that, by the same token, not
everyone is going to leap on every spam-avoidance mechanism they can get their
hands on, especially if the mechanism has a significant false-rejection
potential.

And, as spam-avoidance mechanisms go, the PTR-based one is pretty much
bottom-of-the-barrel, IMO. It'll become completely obsolete once spammers
learn how to make PTR records. I mean, what is the PTR requirement besides
some sort of intelligence test, really, essentially just
security-through-technical-obscurity? What do we do next? Require all mail
senders to implement RFC 2317? Use wildcards properly? Require them to
implement A6 records? DNAME? Frankly, I don't see the point of basing an
anti-spam mechanism on the sender's ability to implement increasingly arcane
features of DNS which have no direct relationship to whether they are a
spammer or not. Spammers can implement PTRs and non-spammers can fail to do
so. So how does requiring PTRs ultimately help one distinguish a spammer from
a non-spammer? I think this mechanism only sorta-kinda-worked to begin with,
because many of the early spammers used such cheapo cut-rate dial-in services
that didn't bother with PTR records. Now that the spammers are more
sophisticated (some of them now run their *own* ISPs), I wouldn't be surprised
if the false-rejection rate of the PTR mechanism is actually higher than the
legitimate-rejection rate.

BTW, we *do* implement some spam-avoidance mechanisms here. But they are
mainly in the form of rejecting mail outright from "free" mail services like
Hotmail. Mail is for business purposes only, and our policy is that our
trading partners, if they wish to use email to communicate with us, must use a
for-pay service to do so. This cuts down on a lot of spam, with no risk of
false rejections. And, just between you and me, it also helps cut down some of
the illicit non-business-related email as well.


> >                                                               I put it in
> >  roughly the same category as basing your remote-execution/
> >  remote-login security on .rhosts and/or hosts.equiv files.
>
>         Right, well I don't use .rhosts or hosts.equiv at all.  If you
> want onto my machines, you have to have your ssh key in the
> appropriate file, otherwise you don't get through at all.

Which pretty much proves my point. PTRs are useless for authentication,
whether you're trying to authenticate someone as a non-spammer, or as a
trusted admin of your sensitive systems. One of the biggest reasons people
started maintaining PTR records in the first place is because it facilitated
.rhosts/hosts.equiv-style authentication. Now that that form of authentication
is recognized as pitifully weak, one of the biggest justifications for
maintaining PTRs has evaporated and in fact may be lulling people into a false
sense of security. If given a choice between using crypto or DNS for
authentication, we all know that folks *should* be using crypto. But due to
laziness or ignorance, many if not most of them *will* continue to choose DNS
instead, since it's more familiar to many old-time admins, less "scary" and
generally easier to set up. Time to break that crutch.


- Kevin