Aquí hay dos aspectos separados de la configuración: la seguridad a nivel de conexión y la seguridad a nivel de autenticación. En la práctica, como el nivel de conexión (TLS) protege a ambos, es común que la seguridad del nivel de autenticación sea baja ("Contraseña normal"). Mientras esté utilizando TLS (SMTP / POP / IMAP sobre SSL / TLS o STARTTLS), está bien.
¿Por qué?
Hace mucho tiempo, antes de que SSL / TLS / STARTTLS se hicieran comunes, las credenciales eran la única parte de la conexión que a la gente le importaba proteger. Como usted dice, el correo electrónico puede transmitirse sin cifrar tan pronto como sale de su servidor, por lo que las personas no estaban profundamente preocupadas por la posibilidad de que se lea. Sin embargo, estaban preocupados por sus credenciales. Y las credenciales utilizadas para pasar por un enlace SMTP / POP / IMAP sin cifrar.
Por esa razón, se diseñaron varios protocolos especialmente diseñados para cifrar las credenciales. Digest-MD5, GSSAPI y OAUTH eran métodos SMTP AUTH más seguros que se pueden usar en una conexión no cifrada. Los tipos más comunes PLAIN y LOGIN, que no cifran las credenciales, dejarían la contraseña vulnerable si no hubiera cifrado a nivel de conexión .
Pero entonces el mundo comenzó a cifrar la conexión. Los clientes y servidores SMTP, POP e IMAP agregaron soporte para SSL / TLS o STARTTLS para proteger toda la conexión. Una vez que se volvieron comunes, hubo poca motivación para usar los métodos SMTP AUTH protegidos más complejos, porque el TLS proporcionaría toda la protección necesaria. Es por eso que su ISP solo se siente cómodo al ofrecer "Contraseña normal" (que es PLAIN y / o LOGIN) - ellos saben que la capa TLS lo protege.
(De hecho, algunos métodos más sólidos debilitan la seguridad al requerir que el servidor almacene una copia cifrada reversible o de texto simple de la contraseña de cada usuario, en lugar de un hash de una sola vía. Para citar Wikipedia en Autenticación de resumen ), " Algunos servidores requieren que las contraseñas se almacenen utilizando un cifrado reversible. Sin embargo, es posible almacenar el valor digerido del nombre de usuario, dominio y contraseña. "El enlace de la nota al pie de esta última declaración va a RFC 2617 lo cual explica más detalladamente las compensaciones de seguridad de Autenticación Digest ... He considerado implementar la Autenticación Digest con Postfix, Dovecot, Courier y Cyrus a lo largo de los años; cada vez que decidí que no me gustaba la compensación.)