At 11:03 PM 11/29/2005, Dave Doherty wrote:
Hi, Orin-
A couple of suggestions....
First, look at your HOSTS file in c:\winnt\system32\drivers\etc to
see if 64.62.134.10 is listed there. Delete the entry if you find it there.
Thanks. Done that. Nothing there.
Next, add DNS service to your IMail server.
I have been hesitant to do our own DNS services because of others who
have told me doing your own DNS can become a full time job. I am
assuming they are talking about a registered DNS server when every
hacker in the world wants to play with it. I hadn't thought about
activating DNS though. We are running a 2000 server and I would have
to figure out how to turn it on. We will be going to 2003 soon if we
can ever get the servers running correctly. I hate hardware!!
Set the DNS servers in Network Properties to known-good upstream DNS
resolvers.
Other than this, the primary servers for all our domains are thought
to be good. I believe they have another server we could add to the stream.
Set the DNS address in IMail to 127.0.0.1. This has the effect of
providing mulitple DNS servers to IMail.
Ahhh. That was a piece I was missing here. We have 64.85.13.6 which
is the primary DNS server. Will this then use the servers in Network
Properties or is it going to expect the local server to be providing
DNS services?
Thanks for the suggestions.
-d
----- Original Message ----- From: "Orin Wells" <[EMAIL PROTECTED]>
To: <Declude.JunkMail@declude.com>
Sent: Wednesday, November 30, 2005 1:35 AM
Subject: [Declude.JunkMail] OT - At wits end
We have a bit of a puzzler with one our clients in trying to
communicate with another domain. What happens is they get 20
attempts failure to deliver. What is REALLY happening is that the
DNS servers that service our environment do not see the target
domain for some unknown reason and thus iMail is unable to resolve
the domain to an ip address for delivery. And since our imail
server is pointing to one of these DNS servers as our primary
server I have been unable to find a way around the problem.
It seems to have started on or about November 9th when the firewall
at the target site received the last message from our server. We
think something changed but no one will admit to anything changing.
The sending environment is running under iMail 7.07 and is
cado-oregon.org (IP 64.85.18.53). There are two dns servers
providing our DNS: ns1.dnswizards.com and ns1.dnswizards.com (IP
64.85.13.6 and 64.85.14.6). The first is what iMail has as the
designated DNS server. No domain on our server can send email to
the domain ucancap.org (ip 64.62.134.10) - this actually ends up
going to a domain called altrue.he.net which apparently hosts their
website. This is odd, but they are happy with it and it is not the
problem. Their mail is hosted on their own exchange server and the
mx record at the destination hosting company shows it going to
mail.ucancap.org (IP 216.110.199.124). The remote hosting DNS
server is ns1.douglasfast.net (IP 216.110.195.3)
I thought out of desperation that if I added an outside DNS server
to the list used by our mail server that iMail would trip down to
it and find the target. I first tried a qwest.net DNS server and I
thought it was going to work until I got back a message saying the
destination email address was not valid (no relaying). I thought
that odd so I replaced the server with the douglasfast.net dns
server. I was right back to where I started wondering why anything
different happened when the Qwest sever was in place because it
appears iMail only knows about a single DNS server. The one
entered in iMail itself. I am not about to make the
douglasfast.net server our primary dns server to solve this for a
single client.
Now it appears our DNS servers see every known domain in the world
except any behind this service (douglasfast.net - which is an
electric company offering network services in Roseburg, OR). And
apparently every DNS server in the world can see their domains except ours.
The two ISPs are apparently not eager to talk to each other to help
resolve the problem so we have the usual "the problem has to be on
their end" finger pointing. And I don't have the experience to try
to figure out why the DNS servers at our server farm can not talk
to the DNS servers at the destination site or even to spot the real problem.
It does not appear to be an issue of IP blocking as such because I
can telnet into the destination mail server from within our server
(behind the 64.85... ) using their ip address. Both ends have
verified that there is no IP blocking going on at fire walls,
routers or in the Exchange server - or they have claimed to have
checked this. I can also see their domain from my workstation that
is connected to qwest.net. Why do the qwest DNS servers work OK
and the DNSWizards do not? The folks at our server farm have tried
a variety of tests, cache flushes and re-acquisitions along with a
lot of other things and have not figured out what is going on nor
made any headway.
If you use dnsstuff.com on the douglasfast.net DNS servers the
results are sometimes odd. There are some "FAIL" issues indicating
there are some timing problems on the server (using
DNSReport.com). Checking for the MX records seems to correctly
identify the mail server (DNS Lookup).
The other day when I looked for the reverse DNS for the mail server
it came back with an error, but I see it is working fine tonight.
Checking DNS timing always returns 250 + ms and a grade of "F". I
do not know the significance of this. Could it be the reason our
DNS server can not get a good fix on this? But why (apparently)
just the dnswizards servers? Why not everybody else?
Can someone a little brighter than I am take a look and tell me if
you see anything that could be contributing to this problem? If
anyone can even suggest a reasonable work-around until this
resolves itself (my bet is on or about December 9th)?
If you can see the problem, please give it to me an a way I can
convey it to the party that has the problem and maybe get them to fix it.
---
[This E-mail was scanned for viruses by Declude EVA www.declude.com]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
[This E-mail was scanned for viruses by Declude EVA www.declude.com]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
[This E-mail was scanned for viruses by Declude EVA www.declude.com]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
