SMTP Issue to remote Exchange

dman

dman

Perch
So I've been trying to figure out the problem with sending email to a remote Exchange server using CDOSYS for two weeks and I'm getting a bit frustrated. Everything worked until April 21st on two sites using basically the same ASP Classic script. Starting on the 21st or 22nd all emails starting failing with the following error:

The message could not be sent to the SMTP server. The transport error code was 0x800ccc67. The server response was 421 4.3.2 Service not available

I initially contacted the Exchange admin and they told me it's an issue with the web server and that I need to contact Jodo. They are stating it's a frozen connection on Win33 to the Exchange server.

I've had an open ticket since April 28th (GSU-91358-702) when I discovered the issue but Jodo support is stating it's an issue with the script or the remote server.The script works on another server without issues and it can send via Gmail, it only has an issue sending thru the Exchange server.

I really need more info from either side but the Exchange admin is adamant that it's an issue with Jodo. I think it might be an issue with Exchange but I need something to refute the claims that it is an issue at Jodo. I've gone back and forth between both and I'm not getting any clear answers from either.... I've Googled the error but nothing seems to clearly state where the issue is.

Does anyone have any experience with this error, specifically with CDOSYS and Exchange? Any help would be appreciated!
 
If it works to other remote servers it really should work to exchange as well as long as the user and password are allowed and they allow the IP to connect.

there's a change they are dropping the connection at the exhcange server by doing a PTR (reverse DNS) lookup and seeing it doesn't have a record it auto drops. This is not uncommon for those connecting directly to a mail server SMTP outside.
They could technically claim this is 'our fault' as we control that, and we do, but we do not rDNS the windows and linux web server IP addresses in general because it responds in lookups and has to have a real domain attached to it, which resellers don't like in general. In addition on the windows 2008 servers the sending IP can randomly change so we'd have to rDNS basically every IP address.
 
Hey Stephen,

Thanks for your reply! I agree it should work and it has for at least the last two years. I believe every time this client switches IT vendors for their internal servers this occurs and it is usually something with Exchange but it's like banging my head against a wall. I understand they are trying to lock things down but there has to be some middle ground...

So the username and password are allowed and supposedly the IPs are added to the receive connector. Both these sites have dedicated IPs which are the IPs that have been added to the connector. Is it possible the SMTP connection is occurring from a different IP then the web server on Win33? You mentioned that the sending IP can randomly change on windows 2008 servers, so is there a range of IPs that we need to add?

I'll check on the PTR with the Exchange admin as maybe this is the issue. One possible issue is that the error response doesn't seem to be as detailed as it could be. Do you have any insights into the specific error "The server response was 421 4.3.2 Service not available"? They are stating that this is a "frozen connection" on the server and the server needs to be rebooted to fix it. Do you have any details that I can use to clarify that this is an Exchange issue? Are there any more details I can get from Jodo about the connection issue, maybe telnet?

Thanks for any help!
 
Actually the frozen connection would likely be due to a PTR record check in my experience. And yes it would need a range of IPs added, as the one for your sites isn't always the socket picked for the outgoing connection on a shared server. 173.0.128.0/20 would likely cover it all but is a large subnet range they may not be willing to add. A VPS would be a lot easier, but on the shared/reseller platform we add IPs often, sometimes remove them to move clients to another machine etc, so we can't really say exactly which IP will show up from them.
I've also seen in the past that even whitelisted IPs if they do not have PTR record are caught prior to the anti spam scanning and such it executed, so it makes some difficulty tracking such issues down.
 
Hey Stephen,

Thanks for your last reply. I think this issue is now resolved. The Exchange admin added additional IPs and IP ranges to the receive connector and it appears to be working. In the end it's not clear if this was a IP authentication and/or "frozen" connection issue but adding the IPs seems to have corrected the issue. Thanks again for your help!
 
You must log in or register to reply here.
Back
Top