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.
