SSL & TLS are encryption methods. They are not used for 'end-to-end' encryption but for 'session encryption'. Session encryption protects data from being spied on while it is being transferred between the client and server software. It does NOT encrypt the data stored on the server or client. So, for instance, when sending a message using SMTP with TLS, the SMTP session is encrypted so any login details are encrypted and the message details are encrypted, so no one can spy on them in transit. However, the SMTP server will have access to the unencrypted message, so it could be spied on there. If that server is out of your and the recipient's control then you should not send any top secret information using that method.
If you want to send a message so that no one can read it other than the recipient, then you should use an end-to-end encryption method such as PGP or S/MIME. VPOP3 does not handle encryption or decryption using these methods, but encrypted emails can be sent through VPOP3 without any problems. You can get plugins for many common email clients to support PGP and S/MIME encryption and decryption, but helping with them is outside our remit.
SSL and TLS are very complex systems and we won't go into the technical details here. Basically SSL and TLS are similar systems and the terms are often used interchangeably. In fact SSL was the first system and then TLS replaced it, with TLS 1.0 being based on SSL 3.0. Many systems which support SSL will support TLS and vice versa. With session encryption the two ends of the connection will usually negotiate the type of encryption to use between themselves, choosing the most secure method which both ends support. VPOP3 currently supports all versions of SSL and TLS 1.0, 1.1 and 1.2, however it is possible that software which connects to VPOP3 may not support the later TLS versions. It is recommended to disable SSL v2 and SSL v3 if it does not cause interoperability issues with other software. (As well as the different versions of SSL/TLS there are also various ciphers, such as RSA, EECDH etc, some of which are more secure than others)
In standard Internet protocols which support encryption there are often two ways the encryption can be used.
The 'old' way is to use an alternate TCP port. For instance, HTTP uses port 80 and HTTPS uses port 443. With this system the client needs to know in advance whether encryption is to be used, it connects on the alternate port and the data is encrypted from the start of the connection.
The newer way is to use "opportunistic encryption" (also known as negotiated encryption or STARTTLS/STLS). With this method the client connects on the standard port and then asks the server if it supports encryption. If the server and client both support encryption, the client can choose to switch the encryption on so that the remainder of the connection is encrypted. This requires less configuration at both ends of the connection, but a 'man-in-the-middle' attack can cause the client not to use encryption (by altering the server responses to indicate that encryption is not possible). To get around this problem it is often possible to tell the client or server that encryption is required so it will fail the connection if an encrypted connection is not established.
Encryption in VPOP3
In VPOP3 Enterprise, the general service SSL settings are configured in Services -> General -> SSL and, where appropriate, individual services can be configured to support optional or mandatory STARTTLS connections (on the standard port) or to use the alternate port (SSL) method of encryption.
In each VPOP3 Mail Collector or Sender, you can indicate whether to use SSL or required or optional STARTTLS encryption.
