CDO failed to connect on ports 465 and 587 but works on 25

Question

We have a legacy FoxPro application that uses CDO for NTS to send STMP email through our Exchange server. We have 3 locations: Local (app run on same domain as Exchange server), VPN (app run on external network connected to domain via VPN), External (app run on external network and connects via Internet).

Up to now, Local has been configured to use port 25 with SSL. VPN and External have been configured to use port 465 with SSL. (My understanding from our network admin was that Exchange couldn't be configured to do SMTPS on 465 and we had to use STunnel).

Recently, we made changes to our Exchange server to disable SSL and only allow TLS. We opened up port 587. So according to my network admin, we now have Port 25 & 587 using the same Exchange Receive Connector and are set to use STARTTLS. Port 465 has also been configured to use STARTTLS and uses a different Exchange Receive Connector; however, the properties are all configured the same as the one used for 25 & 587.

After this change was made, our VPN and External sites were no longer able to send email through the application. The error message they get is:

OLE IDispatch exception code 0 from CDO.Message.1: The transport failed to connect to the server.

So, here is the current state of things:

Local - can send on 25 but not on 465 or 587 VPN - can not send on any of these ports External - can not send on any of these ports

I also tried using the same code and was able to send SMTP from our system through gmail on port 465 and port 25 but not 587.

This is getting way beyond me at this point and I really don't know where to go from here. Does anyone have any ideas as to what may be going on?

I used WireShark to try to figure out what was being communicated between my client and the server (this would be for the Local scenario). Here are some the results:

Exchange on port 25 (Worked)

Exchange on port 465 (Fail)

Exchange on port 587 (Fail)

Gmail on port 465 (Worked)

Gmail on port 587 (Fail)

Answer 1

We finally found a workaround in case anyone is interested. Our Network Admin installed STunnel on our Exchange server and configured it to watch port 465. This got everything working again.