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