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

20

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

Si hago esto, ¿voy a causar problemas por mucho correo legítimo y molestar a mis clientes? He escuchado a la gente que se queja de que AOL hace esto, lo que me hace pensar que tal vez sea demasiado raro para mí.

También me pregunto si puedo comprometerme comprobando que RDNS está configurado al menos en algo, pero no intentar hacer coincidirlo con el EHLO. ¿Es esto posible con Postfix (y es útil)?

— Peter Snow
fuente

44

Sí, se hace comúnmente, incluso si un número muy pequeño de personas tiene problemas con él. Consulte Lucha contra el 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 nueva instalación de sendmail en Red Hat era el valor predeterminado ... Creo que rDNS, aunque no es un estándar formal para servidores de correo, es más o menos el estándar de facto. Atornilla a la gente en las direcciones IP dinámicas (es decir, hogares con conexiones ISP de grado de consumo) pero solía ser, una vez, que la mayor parte de esas IP dinámicas con conexiones eran botnets ... no se sabe hoy en día.

— Avery Payne

10

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

Verifique que HELO / EHLO contenga un nombre de dominio. - Esto se reduce principalmente a si el nombre tiene un punto. Verificar el DNS en el nombre condujo a MUCHOS servidores fallidos, ya que no es raro que el servidor presente un nombre interno o algo que no puede resolver adecuadamente.
Verifique que la IP tenga un registro DNS inverso. - Nuevamente, esta es una configuración laxa ya que no la comprobamos con HELO / EHLO. Al comparar con HELO / EHLO se crearon tantas entradas que esta configuración no duró ni un solo día.
Verifique que el nombre de dominio del remitente sea válido. - Esta es una verificación básica para asegurarnos de que si tenemos que rebotar el mensaje, al menos habrá alguna forma de encontrarle un servidor.

Aquí está el bloque Postfix que usamos 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

— Ed.
fuente

1

También un buen enfoque adicional es verificar el nombre de host con la lista de expresiones regulares que coincide con varios nombres asignados dinámicamente por ISP como xxxx.dynamic.yyy.como 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 botnet y sus mensajes que uso para aprender mis bayes.

— Kondybas

Parece que podría ser la solución para mí. ¿Hay alguna manera de ejecutar SpamAssassin y dejar que todos lo omitan, excepto aquellos correos que no pudieron HELO coincidir con RDNS, entonces solo rebotamos aquellos por encima de un cierto puntaje? Otros correos continúan pasando por alto este paso.

— Peter Snow

Con el exim MTA 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 compara con la lista negra. Si coincide, la bandera variable se alzó "¡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 lo suficientemente alto, marque "Gotcha!" planteado y mensaje también aceptado. Luego, el mensaje pasó a los enrutadores.

— Kondybas

1

Si no se levanta la bandera, el mensaje se entrega como de costumbre. De lo contrario, se produce una copia a ciegas. El mensaje original se entrega nuevamente como de costumbre, mientras que BC se pasa al enrutador especial que tiene sa-learn como transporte. Tal esquema permite dividir el flujo de correo en la rama definitivamente spam que aprende SA-bayes, y sospecha el resto que verificó por SA-bayes. Los mensajes con la bandera en relieve también tienen un encabezado adicional que permite clasificarlos en "Basura"

— Kondybas

Verifiqué esas reglas en mi buzón, y hay correos electrónicos que habrían sido rechazados por HELO que no son de dominio o por la falta de un registro DNS inverso. Es cierto que hay muy pocos (solo unos pocos remitentes en un buzón con 40 000 correos electrónicos), pero hay cosas importantes allí. En particular, si lo hubiera usado reject_unknown_reverse_client_hostname, no habría llegado un correo electrónico con los resultados de mi solicitud de visa a un país particular del sudeste asiático. Aconsejaría no usar reject_invalid_helo_hostnamey reject_unknown_reverse_client_hostname.

— michau

12

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

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

Cualquier persona que trate de bloquearse debido a uno de estos debe ser asfaltada y emplumada.
Tendré simpatía por las personas que terminan siendo bloqueadas por otras razones, particularmente situaciones que dependen de la conformidad RFC en situaciones "anormales". Sin embargo, el spam es un problema que no tiene excusa para perderse lo básico.

— Chris S
fuente

2

El nombre de búsqueda inversa no es necesario para que coincida con HELO. El host puede operar muchos dominios, mientras que la búsqueda inversa solo devuelve un nombre principal.

— Kondybas

1

Claro, puedes hacer lo que quieras. Su servidor recibirá una 511 Your rDNS doesn't match your HELOde mis servidores, y muchos otros también. El spam es un problema importante que los diseñadores de SMTP RFC 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 MTA está configurado correctamente. Mi experiencia muestra que (falló la ORcoincidencia de rDNS con una breve lista local de expresiones regulares OR) detecta el 99,99% del correo no deseado. Sin DNSBL, sin listas grises, sin DKIM, sin SPF. 200k + mensajes entrantes mensuales. 1-2 false-p, 10-20 false-n por mes.

— Kondybas

5

Esperaría que enviar MTA tuviera un RDNS válido, pero insistir en hacer coincidir EHLO dependería de quiénes son los "clientes". Puede 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 resuelva 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 comando EHLO realmente corresponde a la dirección IP del cliente. Sin embargo, si la verificación falla, el servidor NO DEBE negarse a aceptar 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 tenga sentido para el sitio que proporciona el servidor. (...)

— Dusan Bajic
fuente

1

Probablemente esto esté prohibido porque la cadena enviada con EHLO, en el mundo real, a menudo no cumple con RFC. He visto nombres de host internos localhost, y muchas otras cosas incorrectas enviadas aquí, incluso con correo perfectamente legítimo.

— Michael Hampton

3

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 tienen la misma dirección IP. Pero cuando intente hacer 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.

— Kondybas
fuente

1

"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 HELO. Por lo tanto, debería ser obvio que ambos pueden coincidir.

— Chris S

2

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

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

Si hago esto, ¿voy a causar problemas por mucho correo legítimo y molestar a mis clientes?

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

También me pregunto si puedo comprometerme comprobando que RDNS está configurado al menos en algo, pero no intentar hacer coincidirlo con el EHLO. ¿Es esto posible con Postfix (y es útil)?

Si es posible. Puede usar accept_unknown_reverse_client_hostname en lugar de accept_unknown_client_hostname

Desafortunadamente, postfix no tiene opciones flexibles para una "decisión compleja". En exim puede agregar algunos puntos para tales correos, por ejemplo

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 que se completen todas las verificaciones y si tuvo un puntaje> 100, puede rechazar el correo. En realidad, puede obtener ese comportamiento, pero necesitaría escribir su propio servicio de políticas

— ALex_hha
fuente