nslookup from WinNT machine

Brad Knowles brad.knowles at skynet.be
Thu May 31 18:48:31 UTC 2001


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

	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.

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

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

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

>  The reason I believe PTR records should be maintained is, as someone
>  else posted, as a matter of courtesy. Similarly, silently trashing
>  email, with no bounce message, is extremely discourteous behavior.

	I agree.  However, this is a policy that AOL started after I 
left.  Indeed, I didn't actually find out about it until a while back 
when I tried to send e-mail to a friend and former colleague who 
still works there, and I wondered why I never heard back from him.

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

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

	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.

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


More information about the bind-users mailing list