Postfix smtps y confusión de sumisión


13

He configurado postfix para que los clientes de correo electrónico utilicen el puerto 465 (smtps) para el correo saliente. Realmente no entiendo la diferencia entre smtps (puerto 465) y sumisión (puerto 587)

¿Cuál es la 'mejor práctica' al configurar postfix para que los clientes envíen correo de forma segura? ¿Solo usa smtps? ¿O usar tanto sumisión como smtps?

Respuestas:


21

El puerto 465 se usó para conexiones SMTP aseguradas por SSL. Sin embargo, el uso de ese puerto para SMTP ha quedado en desuso con la disponibilidad de STARTTLS: "Revocación del puerto TCP smtps" En estos días ya no debería usar el Puerto 465 para SMTPS. En su lugar, use el puerto 25 para recibir correos para su dominio de otros servidores, o el puerto 587 para recibir correos electrónicos de clientes, que necesitan enviar correos a través de su servidor a otros dominios y, por lo tanto, a otros servidores.

Como nota adicional, el puerto 587, sin embargo, está dedicado al envío de correo, y el envío de correo está diseñado para alterar el mensaje y / o proporcionar autenticación:

  • ofreciendo y requiriendo autenticación para clientes que intentan enviar correos
  • Proporcionar mecanismos de seguridad para evitar el envío de correo masivo no solicitado (spam) o correos infectados (virus, etc.)
  • modificar el correo a las necesidades de una organización (reescribir la parte de, etc.)

Se supone que el envío al puerto 587 es compatible con STARTTLS y, por lo tanto, puede cifrarse. Ver también RFC # 6409 .


Gracias por su respuesta, configuré con éxito el envío con postfix y ahora las cosas están mucho más claras para mí. :-)
Aditya K

De nada =)
liquidat

1
El tráfico en el puerto 465 está completamente encriptado. Cuando usa starttls, el cliente puede ingresar una transmisión segura y salir de ella enviando datos sin cifrado. serverfault.com/q/523804/201912
QkiZ

2

TL; DR

La nueva recomendación es apoyar tanto las presentaciones / smtps como la presentación con STARTTLS por el momento, eliminando gradualmente la última una vez que ya no se use. (Las mismas recomendaciones también se aplican para POP3 vs POP3S e IMAP vs IMAPS).

Detalles

La mejor práctica ha cambiado con RFC 8314 Sección 3.3 :

Cuando se establece una conexión TCP para el servicio de "envíos" (puerto predeterminado 465), un apretón de manos TLS comienza de inmediato. [...]

El mecanismo STARTTLS en el puerto 587 está relativamente implementado 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 TLS implícito se implementa más ampliamente en los servidores que STARTTLS. Es deseable protocolos principales utilizados por Migración de software MUA a TLS implícitos en el tiempo, por consistencia, así como por las razones adicionales discutidos en el Apéndice A . Sin embargo, para maximizar el uso del cifrado para el envío, es conveniente admitir ambos mecanismos para el envío de mensajes a través de TLS durante un período de transición de varios años. Como resultado, los clientes y servidores DEBEN implementar STARTTLS en el puerto 587 y TLS implícito en el puerto 465 para 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 una negociación exitosa de TLS antes del envío del mensaje.

El Apéndice A citado luego desarrolla la decisión de preferir TLS implícito para todos los SMTP, POP3 e IMAP, porque estos puntos principales

  1. De todos modos, solo queremos tener conexiones cifradas en todas partes, por lo que no tiene sentido mantener una versión compatible con versiones anteriores de todos estos protocolos cuando, en la práctica, no se utiliza la compatibilidad
  2. Ha habido vulnerabilidades en la fase de negociación de STARTTLS debido a problemas idénticos en varias implementaciones
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.