nslookup from WinNT machine

Brad Knowles brad.knowles at skynet.be
Fri Jun 1 08:31:44 UTC 2001


At 11:45 PM -0700 5/31/01, Chris Buxton wrote:

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

	Then get another ISP, or get another access package from the same 
ISP.  If they give you Internet access, then they should also be 
willing to act as your outbound mail relay service.

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

	Running Internet mail services is my profession, and my area of 
greatest expertise.  It has been since the early 1990's (probably 
sometime around 1992).  I've done this at the largest Internet mail 
site in the world, and I've done this or consulted on doing this at 
many other large sites around the world.

	Running an Internet mail service is an extremely hard task to get 
done right, something that very, very, very few people in the world 
give proper credit to.  Tools like EIMS, Stalker, or CommuniGate 
don't come anywhere *REMOTELY* close to doing the job right, or 
making it easier for you to do the job right, or even perhaps 
allowing you the possibility of doing the job right.

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

	Right.  Yet more proof that it is harder to do this job right 
than virtually anyone ever gives it credit for, including some of the 
largest ISPs and telcos in the world, who should be in a position to 
know this as well as or better than anyone else in the world.

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

	Agreed.  A separate, but related issue.

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

	Yup.  In fact, I wouldn't be at all surprised if, by default, 
they can't even receive mail from other normal AOL users (of course, 
AOL can always force their customers to accept mail that they send 
themselves, regardless of whatever your mail preferences settings may 
be).

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

	It's basically the same as a properly configured firewall -- 
Disallow everything, except that which you know to be okay.


	Unfortunately, I really don't have a way of testing this myself. 
My wife has had an AOL account for a very long time, and despite my 
best efforts to get her moved onto a "real" e-mail account with a 
real ISP, and despite her frequent extreme frustration with AOL, she 
still refuses to let me move her off.

	My parents, my in-laws, and many other relatives are in a similar 
situation.  Despite all my best efforts, the only relative I know of 
that *doesn't* use AOL is my brother-in-law, who is about as much of 
a techno-geek (in other ways) as I am.

	I also don't subscribe to any magazines that hand out free AOL 
CD-ROMs, and they'd be useless in Belgium anyway.  So, it's a little 
hard for me to create a new account and then go in to see what the 
defaults are set to.

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

	Unfortunately, log monitoring/parsing/summary and user 
notification tools such as this are somewhat non-trivial to create 
(various bits and pieces exist today, but no one that I know of has 
put together all the necessary parts into one complete system). 
Moreover, I can't really think of how you would bundle something like 
this with mail server software.

>  That depends on your mail server software.

	IMO, this is a part of doing the job right.  So, by definition, 
if you can't do this, then you can't do the job right.

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