Email encryption - what is needed?

[Softbox44]

This question relates to emails with personal or sensitive content and attachments.
I am trying to figure out if I should encrypt my emails processed in DMS. I am not concerned with safety of my emails on my own internal DMS host, but I am unsure about data security during the mail forwarding process.
As I understand, emails usually get sent through many mail agents until they reach the final destination server. In that process it is not guaranteed that the emails remain SSL encrypted or is it?. If they are SSL encrypted, there is no need to encrypt the content. Right?

[casperklein]

In that process it is not guaranteed that the emails remain SSL encrypted

SSL/TLS is only used to encrypt the traffic between mail servers (or from a client to a server). Every mail server (MTA) gets the mail in plain text. It's not guaranteed, that every MTA to MTA connection is encrypted.

If only the receiver should be able to read the mail content, you should look into S/MIME or GPG/PGP.

[Softbox44]

OK will look into GPG/PGP - thanks

[polarathene]

@casperklein answered this well! My response is just a longer version of that saying effectively the same thing 😅

---

When you access a website, you will connect from the web browser (client) to the server over HTTPS, your connection is secure.

• On the server, often the traffic is proxied to an internal service without encryption which should be fine.
• Some times this connection is not direct, it may connect to the IP of a proxy like Cloudflare first, and that may terminate TLS, then make a new connection to the real server for the website over TLS/HTTPS again (although technically it does not have to).

Mail is not too different from that, your mail client (submitting mail to be sent, or retrieving mail from the server) can function in the same way. More often accessing your mailbox is more like the web browser scenario.

Submitting mail is a connection between you and DMS, where that mail is then queued up for delivery. Unlike the other two scenarios the connection has finished between your client and DMS. Now the mail will be sent to the intended mail server for the recipient, but this is done via port 25 (STARTTLS) where encryption is not guaranteed (unlike port 465 for mail submission from your client to DMS).

Technically, if your DNS was compromised your connection could go to a different server, this could happen if you connect to public wifi (a less trustworthy network) or even from your ISP as traffic can flow through different systems along the way as your connection is routed to the intended IP address. As port 25 is STARTTLS it begins unencrypted, and must negotiate between the server to upgrade to TLS. Thus the malicious party could prevent this upgrade and force the traffic to be unencrypted where they can inspect the content and potentially alter it. This was found to be done in the past by an ISP or Airport in Thailand I think?

For compatibility it's expected that mail servers allow unencrypted mail delivery on this port when they receive mail. When the mail server is sending mail out on this port however, it can choose to only send mail that is successfully upgraded to TLS. You can learn about this with MTA-STS, which is a way to say "if we have had a secure connection previously, there should be no reason for an insecure connection to occur, I will only trust secure connections with this server now".

This does only ensure TLS between the direct connection DMS makes however, as similar to proxies there are also mail relays. You may choose to use one yourself like SendGrid, where instead of port 25, DMS authenticates over port 465 (or 587) to SendGrid and sends the mail for SendGrid (the relay) to send to your recipient mail server. You lose control over how secure the network is from there on. Likewise, a big mail provider could have many mail servers that you connect to publicly, and these may forward the mail internally to their own private mail servers.

---

All this to say that regardless of mail server or web server, a client only has a direct connection with the first hop/server that they are connected to.

• With web traffic your connection needs to reach a point where it can return a response, that could be the real server or it could be only at the CDN.
• With mail, you could directly connect to DMS but mail being sent out is done separately over another connection, unlike the web server you're already done on the client side by this point. Now DMS would be the client to the next mail server and so forth.

The other difference is with the web server, even if there are multiple hops, it's generally trustworthy because the web browser to web server connection is predictable (A => B), implicit TLS from the start is all that really matters there if you trust the web service and the web service trusts any additional proxies they have actively chosen (that said a forward proxy can exist like in businesses with you as an employee on their network that sits between your client and the service, the business controls enough to terminate TLS and inspect the traffic before making the outbound connection to the real server over TLS).

With mail submission you only have implicit TLS on the users side from their client to your mail server (DMS), and optionally to any relay service you may use. MTA-STS may help you ensure TLS to the mail-server if you send mail out via port 25 directly, similar to the webserver flow.

---

Anyway, point is TLS works great when it's used, but it's encryption only applies between the direct connection, not necessarily the full traffic route.

You can use PGP / GPG to encrypt your mail itself, but each recipient needs the secret to decrypt your encrypted mail.

If it helps, think of it this way:

• You have a mobile phone with a mail client app
• You connect to your server with DMS and send a mail
• You have a 2nd server that runs DMS and it will relay mail from your 1st server.
• You have a 3rd server that runs DMS and it will be for the recipient domain, so the mail gets delivered here.
• In between these connections, there is your router. It's a separate device that helps connect each system involved, DNS could be on a separate system too. And if these weren't all in your local network, then there is probably a few of these involved, especially when in a real scenario you as the user only control your device.

[Softbox44]

Thanks for the detailed explanation. This makes sense. I am just surprised that unencrypted connections through port 25 are still common. If everyone forced encrypted (like on web browsers), all senders would be forced to encrypt email traffic too.
What is the advantage of being compatible with an unencrypted standard if encryption is free in ever sense.

[polarathene]

What is the advantage of being compatible with an unencrypted standard if encryption is free in ever sense.

I don't make the rules. I assume it's on the basis that users rather have mail delivered to the inbox instead of it being rejected. For the most part though I believe it's just legacy.

Unlike HTTP and HTTPS which have different ports and protocols, mail is over port 25 with STARTTLS. It would always start unencrypted so even if you did enforce encryption it may be viable to tamper with that, it's been a while since I thought about it 😓

I don't think you can redirect traffic like with HTTP to HTTPS, and you can't require implicit TLS for port 25 without breaking compatibility with anyone else that doesn't use it, which would upset users? That's kind of why we have all this extra stuff with DNS records and signing to prevent tampering and better establish trust.

So AFAIK the main issue is that someone may have the opportunity to peek at the content if encryption isn't established during a hop, but they shouldn't be able to manipulate the content 🤔 MTA-STS should help ensure encryption is used though, so long as you trust your recipient MTA once they receive the mail.