elkay wrote:That's where my understanding differs. My understanding of TLD is that everything is encrypted between the server that is sending and the final server receiving the email, and any servers in between will not be able to see the content of the message.So man-in -the-middle interceptions and the like are not possible. The content is encrypted.
P.S. It occurs to me that you may be getting a little confused about the levels of protocols here and talking about a slightly different thing to what is actually the case. Apologies if not and you already know this stuff....
The first thing to get clear is that with TLS it's not the
contents of the email that's encrypted but rather the
connection between two servers (or client<->server).
That
connection will go through several
nodes in the network, that is computers that route the packets from source to destination. As is the nature of packet switching networks, the first 1500 bytes (standard IP4 packet size) of your email to California may go through a bunch of nodes to Cornwall to be sent through the transatlantic cable that starts there and the second 1500 bytes may go through another bunch of nodes to Ireland to be then sent through the Ireland-US cable, etc, etc, with them all getting collated at the destination.
If the
connection between source and destination is TLS encrypted then none of those
nodes transporting the connection will be able to see the contents being carried over the connection (that's why it's Transport Layer Security
).
Now, in the simple case what we have on sending an email is:
sending client -> sending SMTP server (which stores the message*, and tries to forward it on at its own convenience)
sending SMTP server -> receiving SMTP server (which stores the message* until it's collected)
receiving SMTP server -> receiving client
Now, each of those connections (the "->") can be TLS encrypted, but there is no end-to-end connection between sending client and receiving client.
* And how the servers store the email is up to them, it could well be in plain text as that's what they'll receive from the transport layer, as it's just the
connection (the "->") that's encrypted, not the email.
Now, things can get more complicated, esp. when using large email providers, who tend to have farms of servers handling email. If you take a look at the headers of an email between such providers you'll find several "Received From/By" headers, usually with gobbledygook server names. So, you might well get:
client ---> sender.com server -> s_int_1 server -> s_int_2 server ----------> receiver.com server -> r_int_1 server -> r_int_2 server ---> client
Each of the connections (-> of any length) may be TLS encrypted but each will be only a this-to-next encryption, and not one that goes on to the following connections; each will have its own. Of course, the s_int_1 & s_int_2 servers, being part of sender.com's setup are all very likely in the same computer room, and ditto for r_int_1 & r_int_2 as part of receiver.com's setup.
Now, having (hopefully) clarified all that, I do agree that the use of TLS has definitely made emails more secure. But, as I say, if you want to have end-to-end encryption to guarantee that nobody else can see your emails, you need to use PGP.
You may find this, and in particular the links in the first paragraph, of interest:
https://elie.net/blog/security/how-email-in-transit-can-be-intercepted-using-dns-hijacking/