nslookup from WinNT machine

[Chris Buxton]

At 8:48 PM +0200 5/31/01, Brad Knowles wrote:
>At 2:58 AM -0700 5/31/01, Chris Buxton wrote:
>
>  >  Put more bluntly, the failure rate caused by the mail filtering method
>  >  we are discussing is unacceptably high to those whose non-spam messages
>  >  fail. In a sense, use of PTR records for SMTP authentication is a form
>  >  of discrimination against small businesses.
>
>	Every single last one of those customers should be using the
>outbound mail relay facilities provided by their ISP.  They should
>not be attempting to do end-to-end mail delivery on their own.

What if their ISP doesn't permit that, on the basis that they're 
running their own mail server and shouldn't need outbound relay 
service? One of my customers reported that his provider, which is the 
phone company for roughly 40% of the US, told him just that.

This was shortly after he gave up trying to get AOL to take messages 
directly from his mail server. He'd been getting mail out 
successfully using his provider's relay server for about a week 
before they arbitrarily decided to cut him off.

>Running a mail server properly has always been a relatively hard
>thing to do, and the job has only gotten more and more difficult as
>time has gone by.

It's only difficult if you use sendmail, which IMHO is not a smart 
way to spend your time. If you use Eudora Internet Mail Server, or 
Stalker Internet Mail Server, or Communigate (also from Stalker), 
then running a mail server really is very easy. The hardest part, for 
someone who doesn't know all the ins and outs, is knowing that PTR 
records are important and how they should look.

>	Of course, the outbound mail relay servers operated by the ISP
>should accept mail from "local" IP addresses regardless of whether or
>not the IP address has a proper reverse DNS entry for it.

Agreed, they should. They sometimes don't.

>  >  Since new spammers would have tried other methods, and some of the old
>  >  ones would have moved to other methods, dropping that guard should yield
>  >  a smaller increase than what you initially stopped. Furthermore, since
>  >  the overall flow has increased, by your own description, then the amount
>  >  added by dropping your guard is less than 25% of the whole, even if it
>  >  hasn't decreased.
>
>	My experience is that the old ones never go away, and indeed they
>simply continue to crank up their efforts, but using the old
>techniques.
>
>	The problem is that there are always new ones to come along to
>fill the void left by implementing measure that end up stopping some
>of the old ones.  However, like the Hydra who grows two heads when
>you chop off one, they usually generate more volume per message and
>higher quantities of messages than the ones they are replacing.

You have more experience in this than I do, so I will not argue this 
point further.

>  >  Too many pronouns. I wasn't able to follow the preceding in the
>  >  context of this discussion.
>  >
>  >  We're not talking about AOL users having their own mail servers. We're
>  >  talking about AOL users whose account is <someuser at aol.com>.
>
>	This also affects anyone who uses a "real" mail client to pull
>down and respond to e-mail from non-AOL servers, but who use AOL
>dialups to get access to the 'net.
>
>	You may have configured Eudora to use pop.yourisp.com as your
>POP3 server, and relay.yourisp.com as your outbound mail relay, but
>when your laptop *thinks* it's talking SMTP to relay.yourisp.com, it
>is in fact talking to the transparent proxy servers that AOL has set
>up.
>
>	Worse, AOL has requested that these transparent proxy servers be
>manually added to the MAPS RBL, so your probability of getting mail
>successfully transmitted to your intended recipient has just taken a
>major nosedive.

That's interesting (and no doubt aggravating to AOL users who need to 
send outgoing messages), but it doesn't address the issue I raised. 
The issue at hand is false positives in the AOL incoming mail filters.

>>>	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.
>>
>>Would you like to explain that again? Are you saying that any AOL user
>>who doesn't configure this filter doesn't get any mail whatsoever?
>
>	Yup.

That sounds ridiculous. You're asserting that a newbie AOL user with 
a new account, by default, will not be able to receive mail from 
anyone at all. They'll never get any email at all. The only possible 
exception is other AOL users.

Is that really what you're saying? I don't have an AOL account, so I 
can't debate the point with facts, but it sounds like it would be a 
good way for AOL to lose customers in a hurry.

>  >  How does your software identify a false positive? If there is some means
>  >  to do so in an automated fashion, why doesn't your mail server use this
>  >  to prevent the problem?
>
>	Count the number of PTR mismatch refusals.  Count the number of
>claimed envelope senders that go along with those PTR mismatch
>refusals.  Count the number of multiple hits from the same obviously
>bogus envelope sender addresses and compare those against the
>individual hits from potentially valid envelope sender addresses.

OK, that's interesting.

>  >  - Your users almost never know that legitimate messages addressed
>  >  to them didn't reach them.
>  >
>  >  - When they do find out, they usually don't have any idea why.
>  >
>  >  - Even if they somehow figure out the basic cause (your mail server
>  >  rejected the message), they point the finger at the other mail server
>  >  or DNS setup. However, getting this far is pretty rare for nontechnical
>  >  users.
>
>	I keep an eye on the false positive rejection rates, and this
>doesn't seem to be a real problem.  Nevertheless, one thing I'd like
>to see is more transparency from the server side, to the customers.
>
>
>	For example, a daily (or weekly) summary that gets sent to each
>and every customer, telling them what messages the system accepted
>for/from them and from/to whom, what messages were refused, what the
>error messages were, etc....  Then, follow that up with a relatively
>simple explanation of the different types of errors and what might
>cause them.

That would be pretty cool, actually. If every mail server that uses 
PTR record filtering had an easy way to do this, I would stop 
objecting to PTR record filters.

>	All this could easily be done based solely on the data sent to
>syslog, and should be able to be done with relatively minor
>modifications to existing syslog parsing programs.

That depends on your mail server software.
____________________________________________________________________

Chris Buxton <cbuxton at menandmice.com>

Men & Mice <http://www.menandmice.com/> provides:
  - DNS training, including Active Directory
  - QuickDNS, a DNS management system for servers on Linux & Mac OS
    (Solaris support coming soon!)
  - DNS Expert, a DNS analysis and troubleshooting utility
____________________________________________________________________