----- replying to a message -----
By: Chris Holt <[EMAIL PROTECTED]>
To: Mailinglist 'miami-talk-ml' <[EMAIL PROTECTED]>
On: Thursday, August 17, 2000 10:12 AM
Re: DNS settings
Hi Chris,
> This is the message I wrote to Earthlink Tech support, followed by
> their reply. His analogy sounds fishy to me, but whatever. I have
> already figured out how I can allow DNS lookup and still use SMTP
> without errors returned. <shrug>
>
> (the part about firewalls sounds totally bogus to me)
>>> Could you guys do me a favor and explain why I have to manually
>>> configure DNS servers as opposed to allowing them to be looked up?
>>>
>>> Everything seems to work on systems where I allow the server to
>>> provide DNS entries, with the exception of SMTP services. There
>>> I get "relaying denied". Why would the SMTP server care about
>>> the DNS servers that I use?
>>>
>>> Or, is my local POP providing an incorrect hostname when reverse
>>> DNS lookup is used?
>>>
>>> I would think that since my username is prefixed, that the POP could
>>> provide a correct hostname regardless of the DNS. Or is that just
>>> not possible?
>> The reason we specify the domain numbers instead of letting the
>> server assign them, and the prefix is just for authentication,
>> is that we cover several platforms and software programs.
>
>> It is kind of like driving a car over long distance, you could
>> specify the route or you could have a general idea, by specifying
>> you will shorten your travel time tremendously.
>>
>> Yes you do have to name the mail servers either by name or number,
>> and if you use the wrong DNS numbers and you have an issue of getting
>> mail, then more than likely those numbers are behind a firewall
>> somewhere.
It sounds like either they don't know what they're explaining, or don't
know how to explain it (their first paragraph certainly sounds like
English isn't their first language). It doesn't matter which type of
computer that you're using, they can all (so far as I know), get the IP
information from the server. And obviously, if you use the wrong IPs,
you're not going to be connecting to what you expect to be.
Usually it's best to get DNS server IPs from your ISP, when you dial in,
so that you're getting the correct ones (in case they change them for
some reason - system updates; or, if they have several different systems
that my accept calls from the one POP dial-in). Unless, their system is
slow at responding to requests for what the IPs are (the usual reason
for YOU setting their DNS server IPs into your TCP/IP stack as permanent
entries), or their set up is so broken that it doesn't work. And if you
are setting the IPs as permanent entries, they need to be the right IPs
for every call.
If you poll your ISP for it's DNS server IPs, and use them, or use the
correct DNS server IPs anyway (manually), then the only way you can try
to access their SMTP server at the wrong IP (they have several SMTP
servers, but you're only allowed to use the one they want you to), is if
their system is misconfigured.
I'm not aware that SMTP servers bother to authenticate you, as such,
just only accept mail from directly connected clients (don't care who,
but you have to be dialled in to them - my ISP will not let me use their
SMTP server, if I dial in from my second ISP). So I'm guessing that
SMTP sends have to come from a range of acceptable IPs, or addresses
(and I'd guess they'd use IPs, as it's simpler to specify some net mask,
or similer - e.g. 204 to 206.xxx.xxx.xxx, as opposed to a range of
names).
If I've got this right...
Some ISPs have more than one mail server, and which one you use, depends
on which equipment actually accepted your incoming call. In this case,
you want your TCP/IP stack to ask their server for which DNS servers to
use, so that you'll get the ones applicable for this call.
i.e. In this case, mail.isp.com is given to a certain numericalal IP,
but on another call, mail.isp.com is given to another numerical IP -
which will only be returned by using the DNS server appropriate for your
current call.
The idea being that you can happily set your mail client to use the
server at mail.isp.com, and if that server happens to be located
elsewhere (at a different IP), for this call, it doesn't matter. Else
you'd need to configure your mail client to use mail1.isp.com for one
call, mail2.isp.com for another call, etc., and somehow know which was
the appropriate one to use.
All of which smacks of SysAdmins playing silly buggers. I'm on a
National ISP (in a big country), we all use the same mail server
addresses (which is a pest, as the country covers at least three
timezones, and they all get the same headers, so some mails aren't set
correctly), and so far as I can see, we all actually do use the same
server. And with some 600,000 (approx) users, they don't seem to need
to have several SMTP servers.
It sounds like they may be doing this sort of thing, and my guess is
that you're getting a relaying error, because you're not
using the particular SMTP server they want you to use for this call
(you're not using the one you've got a more direct connection to).
You (usually) get "relaying" error messages because you're trying to
post a message to someone that's not one of their own clients (assuming
their server isn't having some other type of error, and is returning the
wrong error
message).
e.g. I'm at [EMAIL PROTECTED], you're at [EMAIL PROTECTED],
and I know someone at [EMAIL PROTECTED]
I can post to "you," using either my own ISP's SMTP server, because
it'll deal with posting to someone who isn't one of their own clients,
or I can directly post to "you" via your ISP's own SMTP server, because
they'll (usually) allow outsiders to post to their own members directly.
But I can't post to someone ("them") outside of your ISP, through your
ISP's SMTP server, because they'll disallow that (if they're any good),
to prevent spammers abusing their system. However, my ISP will let me p
ost to "them" through my ISP's SMTP server (that's how I'm always
supposed to send my mail), it'll take care of how to route the message
through to the right place.
Bye,
Tim.
--
http://www.picknowl.com.au/homepages/tim_seifert/
mailto:[EMAIL PROTECTED]
(Modbury, near Adelaide, South Australia)
Video productions, electronics engineering, service and technical
support, and more. For further information, visit the web site.
*** Do not send junk mail ***
--
To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
