nslookup from WinNT machine

[Kevin Darcy]

Brad Knowles wrote:

> At 9:00 PM -0400 5/29/01, Kevin Darcy wrote:
>
> >                                     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.
>
>         Which is *precisely* what spammers want.  When management starts
> counting up the cost of spam, I think that they'll almost certainly
> change their minds.  That's certainly been my universal experience
> everywhere I've gone.

Have you dealt with any huge "old-economy" companies that are aggressively trying
to cut supplier costs using Internet technologies? I doubt anyone's minds would
change here. Even if our mail increased tenfold due to spam, the extra hardware,
etc. to accommodate that volume would still be a tiny drop in the bucket of our
expenses, compared to what we pay for automobile components, sheet metal, etc. Even
if we could prevent just one shift-long assembly-plant outage in the course of a
year, it would probably be worth it. Of course, the impact of spam on people's
productivity is a lot harder to measure...

> >  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.
>
>         But you still have to get them delegated to you, which is the
> truly hard part.  Of course, while anyone can own their own forward
> DNS, it is much, much harder to own your own reverse DNS, and that
> means that PTR records really are a good way to keep down the noise
> from garbage throw-away dialup lines.

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.

>         At AOL, we found that this reduced the amount of spam we got by
> more than 25%, and when you're talking about a site that does
> multiple millions of mail messages per day, and spends tens of
> millions of dollars per year to buy new mail servers to replace the
> overloaded mail servers from last year, this is a *HUGE* cost savings.

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. I really didn't want to get into a discussion of how much spam is too
much spam (that would be technically OT here anyway). 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.

> >                               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.
>
>         PTR records are not particularly arcane, and since they require
> delegation, you can be reasonably sure that the delegating authority
> is aware at some level of what the delegee is doing, and you can hold
> them legally responsible for the actions of their customer.

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?

> >                                       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.
>
>         There are still far more spammers out there using garbage
> throw-away free dialup lines than anything else, because there are
> still a lot of sites out there that are backwards enough (such as
> yours) that they accept anything without validating the PTR record.

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.

> >  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.
>
>         How can you be sure that you would never get a business mail
> message from hotmail?

Apparently you didn't read the part of my message where I explained that our
trading partners are *required* to use only for-pay services to communicate with us
via email. It's amazing how much what-if speculation can be eliminated with a
simple edict.

> Indeed, hotmail (and many other free e-mail
> services) actually gets quite a bad rap, because the spam never
> actually originates at hotmail, it simply claims a hotmail return
> address to try and throw people off the track.

Of course I'm aware of that. But the fact remains that virtually everything
claiming to originate from hotmail.com is from a free mail service and/or it is
spam. Neither of which we care to accept.

>         I've seen this untold numbers of times, and indeed it is one of
> the simplest tricks that spammers use.  Anyone remotely familiar with
> spammers and proper anti-spam techniques should be aware of this
> issue, and not fall into such a ludicrously silly trap.

Well, duh, you think I didn't know that? Should I show you the many complaints
we've gotten because some spammer forged *our* address on a piece of spam? Of
course I'm aware of these spoofing methods. But, spoofed or not, messages
*appearing* to originate from hotmail.com (among others) are messages that we
blackhole. And that works out just fine.

>         Let's take a better case -- AOL.  Let's say you want to block all
> e-mail coming from AOL.  Well, how do you do this, by domain name or
> by IP address?  It is trivially easy for someone to use AOL as a
> dial-up service provider to send e-mail to you, but to claim a
> non-AOL return address.  As shown above, it is trivially simple for
> someone to claim an AOL return address regardless of what IP address
> they're coming in from.
>
>         So, if you really wanted to do this properly, you'd have to do it
> by IP address and not by domain name.  Problem is, AOL also operates
> one of the largest hosting/housing/co-location services in the world,
> with some of the worlds busiest web sites directly on their premises.
> Many of these companies could very well be customers or suppliers of
> yours, but of course their IP addresses would be in the same ranges
> as owned by the rest of AOL.
>
>         So, what do you do?  You're screwed if you do, and screwed if you don't.

Agreed. That's why we don't blackhole AOL. But by the same token, smaller ISPs that
mix their business like that (dial-up with hosting/colo/etc.) should realize that
they run the risk of their hosting/colo/etc. customers being blackholed as
collateral damage in reaction to the nefarious activities of their dial-up
customers. It is in their interest to maintain a strict separation between the two
different kinds of business. Plus, there is sometimes a bit of a fine line to be
drawn sometimes -- even a "respectable" hosting/colo customer can sometimes go
overboard with their marketing and send out a bulk email which meets some people's
definition of "spam" (e.g. "we see in our records that you've bought a widget from
us in the last 5 years, so we thought you might be interested in this month's
specials on doohickeys").

> >  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.
>
>         It's virtually useless as a server-to-server validation
> mechanism, but not as a client-to-server mechanism.  It does prevent
> people from coming in from a garbage throw-away free dialup system
> from abusing the network and transmitting spam directly to your
> servers (if they really wanted to get e-mail to you, they can route
> it through the servers provided by the ISP that gives them dial-up
> access).  In my experience, this catches at least 25% of all spam (if
> not more), and has a very low number of false positives.
>
>         For the rest of the spammers, there are other mechanisms you can
> employ to try to deal with them.
>
> >                      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.
>
>         Put your money where your mouth is.  Turn off all your machines
> until such time as crypto-based authentication is the only method
> available world-wide, and then I might be willing to listen to you.

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?

>        However, even then, we should continue to maintain PTR records,
> for they serve purposes in addition to authentication.

For instance? The only other use I can think of is the convenience of seeing names
instead of addresses on e.g. a traceroute or netstat display. BFD.


- Kevin