The main benefit in opting for TLS over SSL is that TLS was incepted as an open-community standard, meaning TLS is more extensible and will likely be more widely supported in the future with other Internet standards. TLS is even backwards compatible, possessing the ability to "scale down” to SSL if necessary to support secure client-side connections that only understand SSL.
Another more immediate benefit, however, is that TLS allows both secure and insecure connections over the same port, whereas SSL requires a designated secure-only port. For users connecting to an email server via POP or IMAP, this means that using TLS will allow you to opt for secure connections but easily switch to insecure connections if necessary without needing to change ports. This is not possible with SSL.

The third an perhaps the best benefit of TLS secure connection is the unknown if the recipients mail server also supports TLS this means the transport of the document can be secure to the destination.

Resumed TLS handshake

Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure shortcut in the handshake mechanism to avoid these operations. In an ordinary full handshake, the server sends a session id as part of the ServerHello message. The client associates this session id with the server's IP address and TCP port, so that when the client connects again to that server, it can use the session id to shortcut the handshake. In the server, the session id maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an eavesdropper from using a session id). The random data in the ClientHello and ServerHello messages virtually guarantee that the generated connection keys will be different than in the previous connection. In the RFCs, this type of handshake is called an abbreviated handshake. It is also described in the literature as a restart handshake.

There is a bit more to TLS than that, but thats the basics in a nutshell. Now to answer your question, if the recipients server supports TLS, provided that you have correctly setup TLS on your server for port 25, any mail that your client sends to that recipient will be encrypted when sent over the wire. In a nutshell, SSL requires the remote host to support SSL, otherwise it will drop the connection, on the other hand, TLS can be "stepped up" to via the STARTTLS command. The sending server determines whether the receiving server can support TLS via the HELO response of that server.
Filed Under: Uncategorized