Josh-IT
asked on
Cant send email to one specific domain, times out during nslookup test also.
We can't send e-mail to one of our clients. It sits in the transfer queue and generates a delay, then failure eventually. The domain I am talking about is remotedomain.com
Other email is flowing fine, and we can receive email from them.
It doesn't look to be making it to their end at all, so I don't believe it to be a spam filter issue.
Exchange queue states "The remote server did not respond to a connection attempt"
Message history shows the last external step to be- "SMTP: Message Routed and Queued for Remote Delivery"
nslookup with type=mx times out.
A tracert to remotedomain.com times out after the hop at-
aggr116a.dfw1.rackspace.ne
I tried the tracert from a completely separate DSL connection we have here that doesn't touch my production network, and it timed out at the same point.
And nslookup from the DSL connection yields the same time out result as from my production network.
I am in the Chicagoland area. I had a friend at his work do an nslookup and his worked fine. He is located about 50 miles away from me. I am waiting for tracert results to see what his shows.
Looking for any idea's what this could be. The fact that from two separate ISP connections here it doesn't work seems strange to me.
Thanks,
Josh
Other email is flowing fine, and we can receive email from them.
It doesn't look to be making it to their end at all, so I don't believe it to be a spam filter issue.
Exchange queue states "The remote server did not respond to a connection attempt"
Message history shows the last external step to be- "SMTP: Message Routed and Queued for Remote Delivery"
nslookup with type=mx times out.
A tracert to remotedomain.com times out after the hop at-
aggr116a.dfw1.rackspace.ne
I tried the tracert from a completely separate DSL connection we have here that doesn't touch my production network, and it timed out at the same point.
And nslookup from the DSL connection yields the same time out result as from my production network.
I am in the Chicagoland area. I had a friend at his work do an nslookup and his worked fine. He is located about 50 miles away from me. I am waiting for tracert results to see what his shows.
Looking for any idea's what this could be. The fact that from two separate ISP connections here it doesn't work seems strange to me.
Thanks,
Josh
ASKER
I shouldn't have any entries in my hosts/lmhosts.sam since I tested it from two separate computers on two separate connections. I know I one of the machines has never so much as gone to their website or connected to my production network.
SMTP connecter / Send Connecter should be able to be ruled out since one of the machines is on a separate guest network and doesn't connect to my exchange or firewall.
Nothing locally in DNS for that domain on the DSL connected machine at least.
I will have to check into the DNS forwarder settings.
But on my guest DSL, that is just going from a linksys WRT-54G into the Covad DSL modem/router.
So I am not sure where the DNS settings would sit on that.
If you do a tracert, do you even see the last hop my end is able to make?
Thanks so much for the help and idea's so far!
Josh
SMTP connecter / Send Connecter should be able to be ruled out since one of the machines is on a separate guest network and doesn't connect to my exchange or firewall.
Nothing locally in DNS for that domain on the DSL connected machine at least.
I will have to check into the DNS forwarder settings.
But on my guest DSL, that is just going from a linksys WRT-54G into the Covad DSL modem/router.
So I am not sure where the DNS settings would sit on that.
If you do a tracert, do you even see the last hop my end is able to make?
Thanks so much for the help and idea's so far!
Josh
Well, tracert isn't a good option in fact to test a tcp connection.
Use a tcptrace to see if you can reach his host.
Now to fully analyze this issue, i would recommend wireshark.
Also, picking a packet crawler and crawling a DNS request would be good to see if you can acquire his DNS.(or using nslookup + wireshark would also work)
But in fact, you could also do some tests before digging into those tools.
Like trying to use his direct IP instead of his domain.
In fact, rackspace(the domain where your request stops) is his hosting service.
Interestingly it's the last loop before you reach his server.
I might have guessed that IT MIGHT BE his firewall.
Your ping requests are stopping there.
But ICMP requests don't prove enough.
You should try to use nslookup + wireshark or packet crawling.
Use a tcptrace to see if you can reach his host.
Now to fully analyze this issue, i would recommend wireshark.
Also, picking a packet crawler and crawling a DNS request would be good to see if you can acquire his DNS.(or using nslookup + wireshark would also work)
But in fact, you could also do some tests before digging into those tools.
Like trying to use his direct IP instead of his domain.
In fact, rackspace(the domain where your request stops) is his hosting service.
Interestingly it's the last loop before you reach his server.
I might have guessed that IT MIGHT BE his firewall.
Your ping requests are stopping there.
But ICMP requests don't prove enough.
You should try to use nslookup + wireshark or packet crawling.
Can you check to see if you are RFC compliant (you have Reverse DNS configured and your FQDN is correct) and you are not blacklisted:
https://www.experts-exchange.com/Software/Server_Software/Email_Servers/A_2427-Problems-sending-mail-to-one-or-more-external-domains.html
https://www.experts-exchange.com/Software/Server_Software/Email_Servers/A_2427-Problems-sending-mail-to-one-or-more-external-domains.html
ASKER
Starting to read that article-
When I ran the reverse DNS check it came back with these results-
Non-authoritative answer:
xx.xx.21.216.in-addr.arpa name = domain.com.
Authoritative answers can be found from:
56.21.216.in-addr.arpa nameserver = ns2.firstcomm.com.
56.21.216.in-addr.arpa nameserver = ns1.firstcomm.com.
ns1.firstcomm.com internet address = 208.40.1.6
my MX Records show as-
10 domain.com.inbound10.mxlog
10 domain.com.inbound10.mxlog
MXLogic does our external spam filter on Inbound mail only, but they also archive any mail sent/received from my mail server.
domain.com is my domain.
When I ran the reverse DNS check it came back with these results-
Non-authoritative answer:
xx.xx.21.216.in-addr.arpa name = domain.com.
Authoritative answers can be found from:
56.21.216.in-addr.arpa nameserver = ns2.firstcomm.com.
56.21.216.in-addr.arpa nameserver = ns1.firstcomm.com.
ns1.firstcomm.com internet address = 208.40.1.6
my MX Records show as-
10 domain.com.inbound10.mxlog
10 domain.com.inbound10.mxlog
MXLogic does our external spam filter on Inbound mail only, but they also archive any mail sent/received from my mail server.
domain.com is my domain.
This is what I see when I perform a reverse DNS check:
Answer:
216.21.xx.xx PTR record: domain.com. [TTL 10800s] [A=173.161.xxx.xxx] *ERROR* A record for domain.com. does not point back to original IP (A record may be cached).
Thus you are not RFC compliant because your Reverse DNS does nit resolve back to the same IP address that you are sending mail from.
Thus will be one BIG reason for mail-flow problems.
If you want to test on another domain, please ping me a test email to alan @ it-eye.co.uk and see what my servers responds with.
Answer:
216.21.xx.xx PTR record: domain.com. [TTL 10800s] [A=173.161.xxx.xxx] *ERROR* A record for domain.com. does not point back to original IP (A record may be cached).
Thus you are not RFC compliant because your Reverse DNS does nit resolve back to the same IP address that you are sending mail from.
Thus will be one BIG reason for mail-flow problems.
If you want to test on another domain, please ping me a test email to alan @ it-eye.co.uk and see what my servers responds with.
ASKER
Could that be because of my MXLogic hosted email filtering service?
Since my mail flows through them before me with the MX Records as they are.
To my understanding-
Mail flows through them, gets filtered, goes to my Exchange Box, get's journaled then picked up by them for archiving.
216.21.xx.xx is my IP here.
Since my mail flows through them before me with the MX Records as they are.
To my understanding-
Mail flows through them, gets filtered, goes to my Exchange Box, get's journaled then picked up by them for archiving.
216.21.xx.xx is my IP here.
Okay - test message received - thanks.
Your sending IP is as above and as mentioned, Reverse DNS in incorrect. Running an NSLOOKUP on domain.com returns an IP Address of 173.161.xxx.xxx and that's the problem. If you have Reverse DNS configured as mail.domain.com then you shouldn't have a problem.
Time to call your ISP and get Reverse DNS changed.
Your sending IP is as above and as mentioned, Reverse DNS in incorrect. Running an NSLOOKUP on domain.com returns an IP Address of 173.161.xxx.xxx and that's the problem. If you have Reverse DNS configured as mail.domain.com then you shouldn't have a problem.
Time to call your ISP and get Reverse DNS changed.
ASKER
173.161.xxx.xxx is the company hosting my Website.
So that is a valid address for www.domain.com
Could it be because my MX Records show as-
10 domain.com.inbound10.mxlog
10 domain.com.inbound10.mxlog
and not mail.domain.com
???
Or would that not matter since it ends in mxlogic.net anyways?
So that is a valid address for www.domain.com
Could it be because my MX Records show as-
10 domain.com.inbound10.mxlog
10 domain.com.inbound10.mxlog
and not mail.domain.com
???
Or would that not matter since it ends in mxlogic.net anyways?
That doesn't matter.
When a server receives a connection from your server, it checks your IP Address and finds 216.21.xx.xx - it then checks Reverse DNS on your Domain and find domain.com and then will perform a Reverse Lookup and it will find 173.161.xxx.xxx - these two MUST match for some mail servers to be happy. As they don't match with your domain, some mail servers will reject you.
When a server receives a connection from your server, it checks your IP Address and finds 216.21.xx.xx - it then checks Reverse DNS on your Domain and find domain.com and then will perform a Reverse Lookup and it will find 173.161.xxx.xxx - these two MUST match for some mail servers to be happy. As they don't match with your domain, some mail servers will reject you.
ASKER
Just received a reply from my ISP-
"You have one PTR record. 216.21.xx.xx points at domain.com"
So I am not sure where this mixup may be happening...
"You have one PTR record. 216.21.xx.xx points at domain.com"
So I am not sure where this mixup may be happening...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks, I had the ISP make the change.
Hopefully it works. I will be back to follow up or finish off this question depending on my results.
Thanks again!
Hopefully it works. I will be back to follow up or finish off this question depending on my results.
Thanks again!
Sure - no problems - will be keeping an eye out for the change.
Alan
Alan
I can see the record change already.
ASKER
Can you also remove the domain from line 2 of the first posting?
Thanks.
Thanks.
ASKER
So, the day after the change was made my OWA was down, as well as mobile e-mail.
Typical step one, I had the previous change reversed.
Hours later, still no OWA/Mobile Email.
A reboot of the Exchange box got everything back in order.
So I am not even sure if the fix we discussed corrected my issue or not, I am going to have to have the ISP make the change again and see what happens.
Probably not going to be able to do it until this weekend, just in case it is in fact what killed all my mobile access to email.
Typical step one, I had the previous change reversed.
Hours later, still no OWA/Mobile Email.
A reboot of the Exchange box got everything back in order.
So I am not even sure if the fix we discussed corrected my issue or not, I am going to have to have the ISP make the change again and see what happens.
Probably not going to be able to do it until this weekend, just in case it is in fact what killed all my mobile access to email.
Reverse DNS won't have any bearing on problems with your server - it is like sticking a road sign pointing to a town. Then as soon as the sign is up - the town has a power-cut. Totally unrelated - just a coincidence that they happened one after the other.
Alan
Alan
This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.
Have you got a specific SMTP connector / Send Connector configured for that domain?
Have you got anything configured locally in DNs for this domain?
Their inbound mail uses Postini, so you should be able to see their Mx records happily.
You may also be using DNS forwarders for an old ISP and might need to update them to your existing ISP's DNs servers.