Exchange 2010 times out (Primary Target IP responded with:"421 4.4.1 Connection timed out.") when sending to military emails.
Exchange 2010 times out (Primary Target IP responded with:"421 4.4.1 Connection timed out.") when sending to military emails. Restarting these directly through the Exchange Admin Console eventually works, but I can't babysit the server.
some stuff:
Send connector address space is just * with cost set to zero so all mail gets the same priority. Have tried creating a custom send connector with same result.
Set inactivity timeout on connector to 15 mins.
Restarted Exchange Transport and other relevant services as expected after any config changes.
nslookup from server resolves DNS (MX records) for recipient(s)
flushed dns
Talked with someone inside a military base. His suggestion was to try and send through OWA. Sent him an email through Outlook/Exchange and another through OWA. Both are sitting in the outgoing queue waiting to try, then timeout again.
These are set to retry every 10 minutes. If left alone, they hang in the queue, send NDRs to my boss and usually fail in 48 hours. Once she gets an NDR, I get a message to do something and restarting (just right-click "Retry") eventually gets them sent though it may take one or ten tries. I welcome another set of eyes. This has been the norm for about 6 weeks and nothing I can think of changed on our end. Thanks! :)
some stuff:
Send connector address space is just * with cost set to zero so all mail gets the same priority. Have tried creating a custom send connector with same result.
Set inactivity timeout on connector to 15 mins.
Restarted Exchange Transport and other relevant services as expected after any config changes.
nslookup from server resolves DNS (MX records) for recipient(s)
flushed dns
Talked with someone inside a military base. His suggestion was to try and send through OWA. Sent him an email through Outlook/Exchange and another through OWA. Both are sitting in the outgoing queue waiting to try, then timeout again.
These are set to retry every 10 minutes. If left alone, they hang in the queue, send NDRs to my boss and usually fail in 48 hours. Once she gets an NDR, I get a message to do something and restarting (just right-click "Retry") eventually gets them sent though it may take one or ten tries. I welcome another set of eyes. This has been the norm for about 6 weeks and nothing I can think of changed on our end. Thanks! :)
ASKER
Thanks David,
It's been several years since I did anything with/in Perl. Nevertheless I downloaded SWAKS and see what I can make of it. At this point I'm just getting "remote host closed connection unexpectedly" but I'll peck away with a test email or two and see if I can get up to speed.
While I don't really want to have to learn something else right now, I'm running out of sensible options just in Exchange/Powershell/etc. I have been a programmer for many years, but this is out of my wheelhouse.
Thanks again! Joe
It's been several years since I did anything with/in Perl. Nevertheless I downloaded SWAKS and see what I can make of it. At this point I'm just getting "remote host closed connection unexpectedly" but I'll peck away with a test email or two and see if I can get up to speed.
While I don't really want to have to learn something else right now, I'm running out of sensible options just in Exchange/Powershell/etc. I have been a programmer for many years, but this is out of my wheelhouse.
Thanks again! Joe
The message "remote host closed connection unexpectedly" means exactly what it says.
Might occur due to...
1) Submission on port 25, when port 587 is required. (unlikely)
2) Submission on port 25 using non-TLS, when TLS is required. (likely, since you mentioned recipient MX server is military)
3) Some firewall in between is blocking one way port 25 submission.
Tip: Try forcing swaks to use TLS for sending + see if submission occurs correctly.
The non-TLS SWAKS connection (default) should show the MX respond with some type of HELO/EHLO string of some form, similar to the following...
If the submission fails before the HELO/EHLO verb is returned, likely Opportunistic TLS is forced on the MX, so you can only submit mail via a TLS (secure) connection.
Might occur due to...
1) Submission on port 25, when port 587 is required. (unlikely)
2) Submission on port 25 using non-TLS, when TLS is required. (likely, since you mentioned recipient MX server is military)
3) Some firewall in between is blocking one way port 25 submission.
Tip: Try forcing swaks to use TLS for sending + see if submission occurs correctly.
The non-TLS SWAKS connection (default) should show the MX respond with some type of HELO/EHLO string of some form, similar to the following...
imac> swaks --to=david@davidfavor.com
=== Trying smtp.davidfavor.com:25...
=== Connected to smtp.davidfavor.com.
<- 220 ready ESMTP
-> EHLO davids-imac.localIf the submission fails before the HELO/EHLO verb is returned, likely Opportunistic TLS is forced on the MX, so you can only submit mail via a TLS (secure) connection.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
To debug this will require having the target IP along with a valid sender/recipient for testing.
You can use SWAKS for running SMTP conversations in debug mode.
Far better to debug using SWAKS than try to debug conversations from your MTA to another MTA.
Tip: The message you mentioned is an MTA error + likely has nothing to do with DNS.