In the hotel the last days I used one of my business apps to send emails to clients. Now it happened that some emails didn't come through and later I got emails telling me I sent too much (transfer limit). But those emails didn't came from my hoster where I have also my mail server. It was the mail server from the hotel network provider! Now what was going on there and how did they get my mail?
So I checked my configuration there. I was using SMTPSecureSocket, with Secure = true, a port for SSL, the SSL smtp server. I also set connection type to TLS 1.2 and a certificate to use. The idea is of course that all data is encrypted and server certificate is verified against the local one to only trust this one. Trusting either any certificate will not help as anyone could fake it. Also trusting any certificate based on a common root certificate doesn't help much. We all carry root certificates on our computers from various governments and military organizations. So trusting them doesn't help me, as I don't want to trust a certificate they generate. So I really want to either login and send email over my provider or I want an error before the credentials are sent.
In my recent testing the SMTPSecureSocket doesn't do it. Even with the settings asking for secure connection and TLS 1.2, I can see my email data in plain text if I watch network traffic using tcpdump utility in terminal. But I can get it to work by using my MBS CURL Plugin. When the connection is properly encrypted, the hotel network does not route it through their smtp proxy which counts mail and checks them for spam.
For the next days I have something to do:
- replace all uses of SMTPSecureSocket with my CURL Plugin
- change all email account passwords to long random text strings.
- use different accounts for sending/receiving, so if smtp is compromised, a hacker doesn't see incoming mail.
- check with tcpdump and CURL log messages that data is encrypted.
What do you do for sending emails secure in your applications?
See also forum thread on this topic and the Feedback case 39516.