New ISP & my poor exchange server :(
Stephen
My company changed ISP's on Tuesday and now I'm having all sorts of strange
email issues.
My Exchange 2003 server resides inside my private network. I changed my DNS
MX records with Network Solutions, set the tty low and monitored with
nslookup until i saw the ip change propagate.
Now I have instances of users not being able to send outside the domain,
external domains not being able to send to us, but not consistantly... I can
send and receive to myself from my company account and a gmail account no
problem. But then I get reports of my payroll person able to receive a test
email she sent to herself through an AOL account, but she has not gotten a
single email from her payroll company and she has been expecting them since
tuesday.
I disabled all my GFI MailEssential filters and removed my old smart-host
relay server as well from my routing and smtp connectors.
The strangest part is these external people who have been trying to send us
mail for two days now cannot report a single instance of mail being returned
with a delivery error.
I'm running out of ideas where to look for the problem and could really use
someone pointing me in the right direction.
TIA!!!
Ed Crowley [MVP]
For users not being to send outside the domain, ensure that your new ISP
handles SMTP properly, and that your server is smart-hosted to their SMTP
server if it needs to be.
For users not receiving mail, you may have to wait up to one or two days for
mail to bounce if it's retrying, and that can happen when you've made a
change. (Next time you change ISPs, leave the old one working for a few
days while you start up with the new one, perhaps.) The best way to tell
what's going on is to ask a sender's administrator to do a NSLOOKUP on your
MX record, verifying the associated A record(s) and then seeing if he can
telnet to port 25 of the server(s) specified in the A record(s).
--
Ed Crowley MVP
"There are seldom good technological solutions to behavioral problems."
.
"Stephen" <Ste...@discussions.microsoft.com> wrote in message
news:1081FE3B-FDE6-45E8...@microsoft.com...
Stephen
The end result was having to add my internal dns servers to the list of
external dns servers on my default smtp virtual server.
Prior to cutting over to my new provider we used a smarthost and the isp's
dns. The new isp doesn't provide for a smarthost so when we cutover I
removed the smarthost entry and changed the external dns servers to only
those of the new provider.
As such most smtp mail came in with the exception of about a half dozen
reported domains. As soon as I added my internal dns servers to the list the
mail started flowing again.
Is this the correct configuration given the removal of the smart host or
does it indicate a problem with the new isp's dns servers?
Could I have avoided all this by creating a reverse lookup zone on my dns
servers for my isp's subnet?
Thanks in advance for helping to straighen me out.
"Ed Crowley [MVP]" wrote:
> You need to evaluate each of these independently.
>
> For users not being to send outside the domain, ensure that your new ISP
> handles SMTP properly, and that your server is smart-hosted to their SMTP
> server if it needs to be.
>
> For users not receiving mail, you may have to wait up to one or two days for
> mail to bounce if it's retrying, and that can happen when you've made a
> change. (Next time you change ISPs, leave the old one working for a few
> days while you start up with the new one, perhaps.) The best way to tell
> what's going on is to ask a sender's administrator to do a NSLOOKUP on your
> MX record, verifying the associated A record(s) and then seeing if he can
> telnet to port 25 of the server(s) specified in the A record(s).
> --
> Ed Crowley MVP
> "There are seldom good technological solutions to behavioral problems."
> ..
> .
>
Ed Crowley [MVP]
your internal DNS servers to use root hints, or under certain circumstances,
forwarders. That way, there's no confusion about what the name resolution
path is, and your Exchange server is certain to be able tor resolve internal
names.
--
Ed Crowley MVP
"There are seldom good technological solutions to behavioral problems."
.
"Stephen" <Ste...@discussions.microsoft.com> wrote in message
news:2FE26982-41A6-45D7...@microsoft.com...