Solo quería señalar esto ya que parece haberse convertido en un malentendido común: 587 no es “el futuro”, sino el TLS implícito sobre 465.
Llegué a esta revelación a través de esta publicación.
Y al leer el RFC real de 2018, queda claro: no es que STARTTLS sea el camino a seguir, sino que SMTPS no es el camino a seguir, y el TLS implícito sobre el puerto 465 (o 587) es lo que los administradores deberían elegir en el futuro.
El soporte de TLS sobre 465 no debería clasificarse (y probablemente despriorizarse) como “mantenimiento de compatibilidad con versiones anteriores” o cualquier noción similar.
El mecanismo STARTTLS en el puerto 587 está relativamente muy desplegado debido a la situación con el puerto 465 (discutido en la Sección 7.3. Esto difiere de los servicios IMAP y POP, donde el TLS implícito está más ampliamente desplegado en los servidores que STARTTLS. Es deseable migrar los protocolos centrales utilizados por el software MUA al TLS implícito con el tiempo, por coherencia y por las razones adicionales discutidas en el Apéndice A. Sin embargo, para maximizar el uso de la encriptación para la entrega, es deseable soportar ambos mecanismos para la entrega de mensajes sobre TLS durante un período de transición de varios años. Como resultado, los clientes y servidores DEBERÍAN implementar tanto STARTTLS en el puerto 587 como TLS implícito en el puerto 465 durante este período de transición. Tenga en cuenta que no hay una diferencia significativa entre las propiedades de seguridad de STARTTLS en el puerto 587 y TLS implícito en el puerto 465 si las implementaciones son correctas y si tanto el cliente como el servidor están configurados para requerir la negociación exitosa de TLS antes de la entrega de mensajes.
La transición no es a submissions sobre 587 a través de STARTTLS, sino a submissions a través de TLS implícito en el puerto 465 (en contraposición a SMTPS sobre el puerto 465, que ahora está obsoleto).