¿Cuán ampliamente compatible es el TLS forzado en las conexiones SMTP entrantes?


10

Ejecuto un MTA que consta de las comprobaciones estándar Postfix, SpamAssassin, ClamAV, SPF / DKIM, etc.

Soy consciente de que algunos servicios de correo electrónico están comenzando a intentar conexiones TLS antes de texto sin formato al intentar enviar correo a mi servidor.

Me doy cuenta de que no todos los servicios admitirán TLS, pero me pregunto qué tan bien adoptado está para poder satisfacer el lado de seguridad de OCD de mi cerebro (sí, sé que SSL no es tan seguro como alguna vez pensamos que era ...)

La documentación de Postfix para los smtpd_tls_security_levelestados que RFC 2487 decreta que todos los servidores de correo de referencia pública (es decir, MX) no fuerzan TLS:

De acuerdo con RFC 2487, esto NO DEBE aplicarse en el caso de un servidor SMTP de referencia pública. Por lo tanto, esta opción está desactivada de manera predeterminada.

Entonces: ¿Cuán aplicable / relevante es la documentación (o el RFC de 15 años para el caso), y puedo forzar con seguridad TLS en todas las conexiones SMTP entrantes sin bloquear la mitad de los ISP del mundo?


1
Los estándares son creados por comités cuyos miembros probablemente nunca trabajaron como administradores de sistemas ni siquiera un solo año en su vida, y es bastante visible en prácticamente todas las especificaciones estándar de Internet. En el caso de los RFC, la situación es un poco mejor, pero los RFC no son estándares. Son corrientes de aire ( " r Equest f o c OMENTARIOS"). Y: obtienes tu salario no de un periódico, sino de una empresa.
peterh - Restablece a Mónica el

77
Ese RFC fue obsoleto por RFC 3207 . Y su autor ha estado mucho más tiempo de lo que parece pensar un comentarista aquí.
Michael Hampton

66
Para el correo electrónico saliente , aquí algunas estadísticas de Facebook: El estado actual de la implementación de SMTP STARTTLS
masegaloeh

No estoy seguro de la razón del voto negativo único. Gracias Michel y Peter por sus puntos de vista, muy apreciados.
Craig Watson

Respuestas:


7

Esta es una pregunta muy complicada dado que los proveedores de correo del mundo no proporcionan fácilmente estadísticas sobre sus servidores de correo.

Auto diagnóstico

Para determinar la respuesta a su pregunta en función de sus propios pares de servidor / dominio, puede habilitar el registro SSL:

postconf -e \
    smtpd_tls_loglevel = "1" \
    smtpd_tls_security_level = "may"

postconf
postfix reload

Esto supone que guarda sus mensajes de syslog de correo por un tiempo. Si no, quizás configure una estrategia de archivo de syslog y escriba un script de shell para resumir el uso de TLS en su servidor. Tal vez ya hay script para hacer esto.

Una vez que se sienta cómodo de que todos sus pares son compatibles con TLS y con el cifrado y la fuerza del protocolo que está dispuesto a hacer cumplir, puede tomar una decisión informada. Cada ambiente es diferente. No hay una respuesta única que satisfaga sus necesidades.

Mi propia experiencia personal

Por lo que vale, mi propio servidor de correo personal hace cumplir TLS. Esto tiene un efecto secundario divertido de negar la mayoría de los bots de spam, ya que la mayoría de ellos no son compatibles con TLS. (Hasta ese cambio, confiaba en la metodología S25R regexp)

Actualizar

Ha pasado un año desde que respondí esto y los únicos problemas que tuve al recibir correos electrónicos con TLS forzado fueron desde los servidores web front-end en Blizzard (controles parentales) y el sistema de administración de Linode. Todos los demás con los que interactúo parecen admitir TLS con cifrados fuertes muy bien.

Ambiente corporativo

En un entorno corporativo, le recomiendo encarecidamente que habilite el registro de TLS y lo deje en funcionamiento durante bastante tiempo antes de aplicar TLS. Siempre puede aplicar TLS para nombres de dominio específicos en el archivo tls_policy.

postconf -d smtp_tls_policy_maps

El sitio de postfix tiene una excelente documentación sobre el uso de los mapas de políticas de tls. Al menos puede asegurarse de que los dominios específicos que proporcionan información confidencial estén encriptados incluso si un ISP intenta eliminar el soporte TLS en la conexión inicial del servidor.

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.