¿Sigue siendo "incorrecto" requerir STARTTLS en los mensajes SMTP entrantes?

15

De acuerdo con la sección 5 de la especificación STARTTLS

Un servidor SMTP de referencia pública NO DEBE requerir el uso de la
extensión STARTTLS para entregar correo localmente. Esta regla
evita que la extensión STARTTLS dañe la interoperabilidad de la infraestructura SMTP de Internet. Un servidor SMTP de referencia pública es un servidor SMTP que se ejecuta en el puerto 25 de un host de Internet que figura en el registro MX (o un registro A si no hay un registro MX) para el
nombre de dominio en el lado derecho de una dirección de correo de Internet .

Sin embargo, esta especificación fue escrita en 1999, y considerando que es 2014, esperaría que la mayoría de los clientes, servidores y relés SMTP tengan algún tipo de implementación de STARTTLS.

¿Cuánto correo electrónico puedo esperar perder si necesito STARTTLS para los mensajes entrantes?

email  smtp  starttls 
— Jackweirdy
fuente
1
Buena pregunta. Sin embargo, tener TLS forzado no va a prevenir el SPAM.
— Matt
1
No lo espero, solo quiero el cifrado (que parece que
— obtengo
2
@ Matt Revisé los correos recibidos recientemente en un servidor de correo en particular y encontré esto. De los correos recibidos con TLS hubo 4% de spam, de los correos recibidos sin TLS hubo 100% de spam. No bloquearía completamente los correos electrónicos sin TLS basado en esto, pero ciertamente es una señal fuerte, que podría utilizarse en el filtrado de spam.
— kasperd
@kasperd: puede activar TLS o usarlo como un medio para reducir el correo no deseado, pero no durará. Todo lo que significa realmente es que el cliente smtp que están utilizando para enviar spam a su servidor no está usando TLS, o tal vez intenta no usar TLS de manera predeterminada, pero puede probar una sesión habilitada para TLS si es necesario. En el mejor de los casos, verá una reducción temporal en el SPAM, pero espero que vuelva a los niveles normales con el tiempo.
— Matt
@Matt Eso se aplica a la mayoría de los enfoques que actualmente se toman contra el spam. Otro problema con la mayoría de los enfoques es que bloquean demasiados correos electrónicos legítimos. La gente rara vez considera cuántos correos electrónicos legítimos es aceptable bloquear.
— kasperd

Respuestas:

19

Sí, sigue siendo una mala idea.

Tres razones:

  1. Si bien el RFC que citó ( RFC 2487 ) está de hecho obsoleto por el estándar actual RFC 3207 , el estándar actual mantiene la palabra que NO DEBE ser verbal en su pregunta.

  2. Los clientes SMTP no están obligados a implementar STARTTLS. Es totalmente aceptable no hacerlo. Si bien STARTTLS se está volviendo más común, no es absolutamente universal.

  3. Como resultado de las razones 1 y 2, si necesita STARTTLS en todas las conexiones entrantes, perderá el correo.

Sin embargo:

Su servidor: sus reglas. Si desea rechazar arbitrariamente cualquier correo por cualquier motivo, o incluso sin motivo, ese es su derecho y privilegio. (Sin embargo, no significa que sea necesariamente una gran idea)

Notas al margen:

No evitará el spam solicitando STARTTLS, incluso si requiere autenticación mutua de STARTTLS. Los spammers también pueden obtener certificados, o crear certificados autofirmados. Rechazar certificados de cliente autofirmados también provocará la pérdida de correo legítimo.

STARTTLS es encriptación punto a punto. El sistema de conexión aún puede leer el contenido del correo electrónico. Si desea privacidad real, necesita algo de extremo a extremo, como OpenPGP o S / MIME.

Dicho esto, STARTTLS elimina una posible vía de intercepción o MITM y, por lo tanto, sigue siendo una buena idea usarlo cuando sea posible, es decir, cuando el otro lado también lo admite.

— Joe Sniderman
fuente
1
La nota sobre certificados y spam está fuera de lugar. Es el receptor el que necesita un certificado, no el remitente.
— kasperd
No ayudará a prevenir el spam. Incluso si hace que la autenticación mutua de STARTTLS sea obligatoria. Se actualizará la respuesta para aclarar.
— Joe Sniderman
2
+1 en nota sobre spam. El hecho de que esté encriptado no lo hace seguro.
— Matt
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.