Pregunta ¿Es una buena práctica o demasiado draconiana rechazar correos de servidores de correo sin RDNS?


Recientemente dejé de usar SpamAssassin y ahora estoy basando el rechazo de spam en DNSRBL, listas grises y otras pruebas básicas y me pregunto si también debería bloquear los hosts que no tienen un RDNS válido que coincida con EHLO.

Si hago esto, ¿crearé problemas con el correo legítimo y molestaré a mis clientes? He escuchado a personas que afirman que AOL hace esto, lo que me hace pensar que tal vez sea demasiado raro para mí.

También me pregunto si puedo comprometerme al verificar que RDNS está al menos configurado para algo, pero no tratar de hacerlo coincidir con el EHLO. ¿Es esto posible con Postfix (y es útil)?


20
2017-09-20 08:52


origen


Sí, se hace comúnmente, incluso si un número muy pequeño de personas tiene problemas con él. Ver Fighting Spam: ¿Qué puedo hacer como administrador de correo electrónico, propietario de dominio o usuario? para mayor discusión. - Michael Hampton♦
Jon Postel no está de acuerdo :-) - Mathias R. Jessen
Hace muchas lunas, la búsqueda inversa en una instalación nueva de sendmail en Red Hat era la opción predeterminada ... Creo que rDNS, aunque no es un estándar formal para los servidores de correo, es prácticamente el estándar de facto. Atornilla a las personas en direcciones IP dinámicas (es decir, hogares con conexiones ISP de grado de consumidor) pero solía ser, alguna vez, que la mayor parte de esas IP dinámicas con conexiones eran redes de bots ... no sé acerca de hoy en día. - Avery Payne


Respuestas:


He intentado múltiples enfoques con la comprobación de HELO / EHLO con una base de clientes de un tamaño bastante decente de entre 100k-200k usuarios y terminé utilizando una solución que hace lo siguiente:

  • Compruebe que HELO / EHLO contiene un nombre de dominio. - Esto se reduce principalmente a si el nombre tiene un punto. La comprobación del DNS en el nombre llevó a MUCHOS servidores fallidos, ya que no es raro que el servidor presente un nombre interno o algo que no pueda resolver correctamente.
  • Compruebe que la IP tiene un registro DNS inverso. - Nuevamente, este es un ajuste relajado ya que no lo comparamos con el HELO / EHLO. La comprobación contra HELO / EHLO creó tantos tickets que esta configuración no duró ni un solo día.
  • Compruebe que el nombre de dominio de los remitentes es válido. - Esta es una verificación básica para asegurarnos de que si tenemos que enviar el mensaje, habrá al menos alguna forma de encontrar un servidor para él.

Aquí está el bloque Postfix que utilizamos para estas comprobaciones:

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unknown_reverse_client_hostname,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient

10
2017-09-20 21:37



También es un buen enfoque adicional comprobar el nombre de host con la lista de expresiones regulares que coincida con varios nombres asignados dinámicamente por ISP como xxxx.dynamic.yyy.com o 12-34-56-78.dsl.zzz.com. Todos estos hosts deben enviar su correo a través de la retransmisión del ISP y no directamente al MX del destinatario. Principalmente, estos hosts son los nodos de la red de bots y sus mensajes que he usado para aprender mis bayes. - Kondybas
Esto parece que podría ser la solución para mí. ¿Hay una manera de ejecutar SpamAssassin y dejar que sea pasado por alto por todos, excepto por aquellos correos que no cumplieron con HELO con RDNS, entonces solo rebotamos aquellos que están por encima de cierta puntuación? Otros correos siguen omitiendo completamente este paso. - Peter Snow
Con el MTA exim que he hecho de esa manera, secuencialmente: el addr / host del remitente se compara con la lista blanca. Si coincide, se acepta de inmediato, de lo contrario se verifica en la lista negra. Si coincide, la bandera de la variable subió "¡Gotcha!" Y el mensaje también es aceptado. Si el mensaje se ha pasado a través de las listas, se pasa a la SA que actúa como demonio. Si el valor devuelto es suficientemente alto, marca "Gotcha!" Levantado y mensaje también aceptado. Luego el mensaje pasa a los enrutadores. - Kondybas
Si el indicador no está activado, el mensaje se entrega como de costumbre. De lo contrario se produce una copia oculta. El mensaje original se entrega nuevamente como siempre, mientras que BC se pasa al enrutador especial que tiene sa-learn como transporte. Dicho esquema permite dividir el flujo de correo en la rama definitivamente de spam que aprende SA-bayes, y sospechar del resto que verificó SA-bayes. Los mensajes con la bandera levantada también tienen un encabezado adicional que permite clasificarlos en la "basura" - Kondybas


Es extremadamente común bloquear los servidores SMTP que no tienen estos elementos básicos:

  1. El nombre de host en el reenvío de HELO se resuelve en una conexión IP originada desde.
  2. El IP de origen de las conexiones se invierte al nombre de host reclamado en HELO.
  3. Si existen políticas SPF, DKIM o DMARC, verifique.

Cualquier persona que se entere de que se bloquee debido a uno de estos debe estar tarada y emplumada.
Las personas que terminen siendo bloqueadas por otras razones, en particular las situaciones que dependen de la conformidad RFC en situaciones "anormales", tendré compasión por ellas. El spam es un problema tal que no hay excusa para faltar a lo básico.


12
2017-09-20 14:44



El nombre de búsqueda inversa no es necesario para que coincida con HELO en absoluto. El host puede operar muchos dominios, mientras que la búsqueda inversa solo devuelve un nombre primario. - Kondybas
Claro, puedes hacer lo que quieras. Su sever estará recibiendo una 511 Your rDNS doesn't match your HELO de mis servidores, y muchos otros también. El spam es un problema importante que los diseñadores de RFC SMTP no tuvieron que enfrentar. Los requisitos realistas son claramente diferentes de los RFC en pequeñas formas. - Chris S
El spam no es un problema cuando el MTA está configurado correctamente. Mi experiencia muestra que (rDNS fallido OR lista corta de expresiones regulares coincidente OR Bayes emparejados) detecta el 99,99% del spam. No hay DNSBLs, ni greylists, ni DKIM, ni SPF. 200k + mensajes entrantes mensuales. 1-2 falso-p, 10-20 falso-n por mes. - Kondybas


Yo esperaría que el envío de MTA tenga un RDNS válido, pero insistir en que coincida con EHLO dependería de quiénes son "los clientes". Puedes encontrar algunas pautas interesantes en RFC5321:

2.3.5.

(...) El nombre de dominio dado en el comando EHLO DEBE ser un   nombre de host primario (un nombre de dominio que se resuelve en una dirección RR) o,   Si el host no tiene nombre, una dirección literal (...)

4.1.4.

(...) Un servidor SMTP PUEDE verificar que el argumento del nombre de dominio en el   El comando EHLO en realidad corresponde a la dirección IP del cliente.   Sin embargo, si la verificación falla, el servidor NO DEBE negarse a   acepta un mensaje sobre esa base.

pero luego en 7.9.

Es un principio bien establecido que un servidor SMTP puede negarse a aceptar correo por cualquier razón operativa o técnica que lo haga.   sentido al sitio que proporciona el servidor. (...)


5
2017-09-20 15:01



Probablemente esto esté prohibido porque la cadena enviada con EHLO, en el mundo real, a menudo no es compatible con RFC. He visto nombres de host internos, localhost, y muchas otras cosas erróneas enviadas aquí, incluso con correo perfectamente legítimo. - Michael Hampton♦


La búsqueda inversa no necesariamente apunta al nombre de host proporcionado en HELO. A veces, varios dominios alojados en el mismo host, y todos ellos tienen la misma dirección IP. Pero cuando intenta realizar la búsqueda inversa, obtendrá el nombre que se ha colocado en el registro PTR. Es obvio que ambos FQDN serán diferentes, y eso es completamente aceptable.

La única circunstancia que permite soltar el mensaje es la búsqueda inversa fallida. Cualquier búsqueda exitosa significa que el host es válido. Los nombres no deben coincidir.


3
2017-09-20 23:55



"Es obvio que ambos FQDN serán diferentes, y eso es completamente aceptable". No. Solo puede configurar un registro PTR y su servidor de correo solo puede anunciar un nombre de host en el HELO. Entonces debería ser obvio que ambos pueden coincidir. - Chris S


Me pregunto si también debería bloquear los hosts que no tengan un RDNS válido que coincida con EHLO.

No, no deberías. Bloquea un correo electrónico completo solo por un criterio, es una mala práctica.

Si hago esto, ¿crearé problemas con el correo legítimo y molestaré a mis clientes?

más probable es que lo haga y perderá el correo legítimo

También me pregunto si puedo comprometerme al verificar que RDNS está al menos configurado para algo, pero no tratar de hacerlo coincidir con el EHLO. ¿Es esto posible con Postfix (y es útil)?

si es posible Puede usar reject_unknown_reverse_client_hostname en lugar de reject_unknown_client_hostname

Desafortunadamente, postfix no tiene opciones flexibles para "decisiones complejas". En exim puede agregar algunos puntos para tales correos, por ej.

Score = 0 
1. The HELO or EHLO hostname is not in fully-qualified domain or address literal form. Score +=10
2. The HELO or EHLO hostname has no DNS A or MX record. Score +=20
3. The HELO or EHLO hostname is listed with the A record "d.d.d.d" under rbl_domain. Score +=20
4. The sender domain has no DNS A or MX record. Score +=10
5. SPF checks return softfail. Score +=10, fail, Score +=20
...

Y así. Después de completar todos los cheques y si tiene un puntaje> 100, puede rechazar el correo. En realidad, usted puede tener este tipo de comportamiento, pero tendría que escribir su propio servicio de política


2
2017-09-24 21:34