SmtpException in ASP.NET Application with Remote Browser

I have an ASP.NET 4 application running IIS 7 on a Windows Server 2008 machine. The application uses classes System.Net.Mail

to send email through an SMTP server. I am using port 587 for SSL connections. When I view the application from the server, the emails are sent fine. However, when I view the application from a remote computer (client), the email fails from SmtpException

c StatusCode = GeneralFailure

. The message says the SMTP server cannot be connected and there is an internal one SocketException

.

The F-Secure anti-virus system is running on the server. I tried to disable it but the errors persist.

Email sending works or not depending on how I access the web server:

• If I go to http://myapp.mydomain.com from a remote client using the server's public DNS name then it doesn't work.
• If I browse http://193.144.xxx.xxx/myapp from a remote client using the server's public IP plus the web application name in IIS, then it fails as well.
• If I view http: // internal-name / myapp from a remote client using the internal server name in the domain plus the web app name in IIS over VPN, then it works!
• If I view an interactive session on the server itself, no matter how I do it (public DNS name, public IP address, internal domain name, or just localhost
  
  ), then it works too. How is it possible that sending mail works when viewed from the server, but not when viewed remotely? In both cases, this is the same server sending emails.

And if I view the application on my development machine from Visual Studio everything works fine.

See also: https://serverfault.com/questions/845606/iis-randomly-returning-inet-e-resource-not-found

EDIT . The server has a private IP address for internal use at the workplace, as well as a public IP address that resolves public DNS. This public IP address is not configured on the server itself; rather, it is a forwarding service operated by our internet access provider. Is it possible that the SMTP server is confused by the fact that the connection request comes from a client who claims to have an address, but then has a name that resolves to a different address?

Any ideas? Thank.