Uso de registros MX falsos para combatir el spam

Tengo un cliente que recibe mucho spam. Es el día 15 del mes y el ancho de banda POP3 es de casi 100 GB. Solo hay 7 cuentas de correo electrónico en este dominio. Instalé SpamAssassin, lo configuré en 5 y configuré 10-20 filtros que rechazan la mayor parte de la basura. No veo mucho cambio en el ancho de banda POP3. Corríjame si me equivoco, el servidor aún recibe el mensaje usando ancho de banda para analizar y determinar un puntaje de spam.

Me topé con falsos registros MX, aunque no lo supieran, básicamente estableciste un servidor falso como los registros MX más bajos y más altos con el registro MX del servidor de trabajo en el medio.

Por ejemplo:

fake.example.com    1
realmx.example.com  2
fake2.example.com   3

La teoría es que, dado que la mayoría del correo no deseado se genera a partir de zombis basados ​​en Windows, muchos consultarán el registro MX más alto de correo no deseado, ya que generalmente son servidores de respaldo que no filtran el correo no deseado. El registro MX falso más bajo es para el resto de los spammers ... y, en general, los spammers no vuelven a intentarlo después de fallas.

¿Alguien ha probado esto? ¿Ayuda? ¿Retrasa o causa problemas con la entrega del correo? ¿Alguien más tiene una mejor solución?

Hágase un favor y configúrelos con un servicio de puerta de enlace antispam como Postini. Por unos pocos dólares por buzón por mes, no hay absolutamente ninguna razón para no hacerlo y no solo eliminará el 99% de su correo no deseado, también disfrutará de tener acceso a su servicio de spool (útil para tiempos de inactividad programados o no programados), no para mencione el ahorro de ancho de banda al permitir que otra persona reciba y procese todo ese spam antes de que llegue al borde de su red.

No es un empleado de Postini, solo un usuario feliz que también ha configurado docenas de clientes con él.

He intentado esto, ¡y puedo recomendar encarecidamente que NO LO HAGAS ! Parecía una buena idea en ese momento, pero después de que el correo de varios remitentes comenzó a desaparecer, me di cuenta de que era un error. De lo que no me di cuenta es que hay muchos servidores SMTP terriblemente escritos, que no siguen las especificaciones y son bastante malos para manejar errores, y la gente no sabe ni le importa porque "este otro tipo recibió mi correo electrónico , entonces debes ser tú ".

Secundo algunas de las otras sugerencias para manejar el SPAM. Postini es un gran servicio, e incluso las funciones integradas contra el correo no deseado en las aplicaciones gratuitas de Google no son tan malas. Si desea más control, puede comprar un IronPort u otro dispositivo, o rodar el suyo.

Nunca he oído hablar de este método antes y puedo imaginar que retrasaría el correo electrónico legítimo potencialmente por varias horas. Al final del día, los protocolos SMTP deben entregar su correo electrónico legítimo. Los servidores válidos alcanzarán el falso registro de mx e intentarán entregarlo a ese servidor ... No sé qué podría haber ejecutado allí (si es que hay algo), pero seguirán intentándolo hasta que sea aceptado.

Los servidores adecuados seguirán probando los registros MX hasta que se entregue el correo. Los spammers tienden a ser más inteligentes y si esto funciona para algún software de spam ahora, dudo que funcione por mucho tiempo. No puedo recomendarlo

Mi sugerencia es, en cambio, considerar el uso de un tarpit smtp además de su filtro de spam existente. Hay varios de estos disponibles ahora. Creo que encontrarás que es mucho más efectivo que el método falso de grabación de mx.

Tales lonas vienen con smtpd en BSD. También hay algunas características de tarpitting en sendmail 8.13.

Básicamente, un tarpit funciona al vincular los recursos del servidor de spam. Lo hacen retrasando las respuestas que obtienen. por ejemplo, el servidor de spam se conecta y recibe aproximadamente 1 byte por segundo.
Algunos de los servidores tarpit buscan patrones de spam y pueden reconocer un servidor de spam. Los servidores legítimos estarán preparados para esperar una respuesta lenta. En algunos servidores tarpits, mueven el servidor legítimamente reconocido a una lista blanca automáticamente para que no haya demoras en el futuro.

Google SMTP Tarpit y eche un vistazo.

No lo mencionaste, entonces, ¿hay alguna razón por la que no estás usando un DNSBL ?

Editar: SpamAssassin incluye soporte para algunos de ellos; sin ellos, desperdiciarás muchos ciclos de CPU analizando el spam.

Utilizo este MX falso (una variante de la nolisting ) y funciona muy bien.

Utilicé un MX postfix con todos los filtros habituales y después de que algunos robots de spam lograron sobrecargar el servidor 2 o 3 veces, decidí probarlo ... aquí está el resultado:

intenta adivinar cuando he implementado el falso-mx! 8)

El resultado es el mismo que postgrey, pero a diferencia de postgrey, no necesita cambiar su servidor de correo

Los spambots ahora intentarán el MX alto o el MX bajo, liberando al MX real de la carga de intentar filtrar entonces (incluso con DNSBL, la carga era alta) y el correo electrónico real llega con un retraso mínimo.

Pero ten cuidado, hay riesgos:

• Algunos servidores pueden tener tiempos de reintento altos. La mayoría de los servidores volverán a intentar el próximo MX después del primer tiempo de espera, otros lo intentarán en los próximos minutos, pero ya vi servidores que solo vuelven a intentarlo después de una hora o un día. Son muy raros y para los que pude ver fue una mala configuración. hablar con el otro administrador de correo soluciona el problema

• Todos los correos electrónicos tendrán un retraso. En realidad, no veo ningún retraso en absoluto, casi todos los servidores de correo reales volverán a intentar el próximo MX después del primer tiempo de espera, por lo que estamos hablando de un retraso de 30 segundos. Por lo general, prueban al menos 3 MX antes de poner en cola el mensaje por un retraso mayor. pero es posible que tenga contacto con un servidor de correo roto que podría no hacerlo y retrasar cada mensaje por minutos. Entonces, esto es algo que se debe monitorear al implementar esta solución.

• Sitios rotos. Algunos servidores web envían correos electrónicos para contraseñas, notificaciones, etc. y en lugar de entregar un servidor de correo real interno, intentan ser un servidor de correo "falso" y entregar directamente. Como es un servidor web, nunca volverán a intentarlo y se perderá el correo electrónico. Una vez más, es una mala configuración del webmaster / desarrolladores web, ya que solo los servidores de correo electrónico reales deberían enviar correo electrónico. Cada vez que encuentro este problema, hablo con el webmaster sobre el problema y, por lo general, el problema se soluciona.

• No hay registros. Como el falso MX que apunta a IPs desconectadas, no tiene registros de lo que intentó entregarse. solo sabes que algo salió mal cuando alguien se queja. Pero esto también es bueno. Siempre puede afirmar que no ha intentado entregar ningún correo electrónico, por lo que es un problema remoto. El otro lado debe verificar sus registros y resolver el problema. Puedo demostrar que no hay ninguna conexión con mi servidor real, moviendo la presión para resolver el problema al otro lado. Si el otro lado no puede solucionar el problema, no parece confiable ni confiable.

• Sin lista blanca. esto se aplica a todos los servidores a través de dns, por lo que no puede incluir en la lista blanca un servidor ... en realidad es solo la mitad, pero es más difícil. la solución de la lista blanca es que el MX más bajo apunta a una IP donde se está ejecutando un smtp, pero filtrado por firewall para todos. Aquellos servidores que desea incluir en la lista deben estar permitidos en el firewall. De esta manera, todos los servidores serán rechazados por el firewall y la lista blanca podrá entregar al servidor de correo. Funciona, pero solo para la lista blanca de IP, no para la lista blanca de correo electrónico.

A diferencia de postgrey, donde el remitente remoto tiene un registro de una entrega "rechazada" (y puede señalarnos como el problema), el falso MX mostrará que el servidor web ni siquiera pudo conectarse y no volvió a intentarlo, sin excusa para el lado remoto sobre el problema. Un MX defectuoso se acepta mejor que postgrey, ya que siempre podemos reclamar algún "problema de enrutamiento, pero el MX de respaldo funciona bien, recibimos todos los demás correos electrónicos"

Dicho esto, recibo muy pocas quejas (aproximadamente 1 cada 3 meses), por lo que lo considero lo suficientemente seguro (cada filtro de spam tiene riesgos).

Tenga en cuenta que uso una dirección IPv4 válida para todos los MX, pero para los falsos uso una IP que controlo que no está en uso (y por lo tanto da tiempo de espera / host inaccesible en cualquier conexión). estas reglas se aplican incluso si no usa esto. Hay servidores dns y smtp que requieren una configuración dns perfectamente válida para que el correo electrónico funcione. el falso MX también debe ser válido, simplemente no debe ser accesible.

No utilice IP privadas o IP que no controle para el MX falso (si agrega una dirección IPv6, TAMBIÉN agregue una IPv4). Esto evita problemas con DNS y servidores de correo rotos y sorpresas de que otros reciban su correo electrónico (instalando un servidor smtp en la IP que no controla). Además, CNAME está prohibido para MX, así que no lo use también, solo un registro A simple

Finalmente, se debe enviar un reinicio tcp para el MX falso, para mejorar el rendimiento (host o puerto inalcanzable) en lugar de un tiempo de espera simple (al soltar el paquete), por lo que se recomienda agregarlo a su firewall.

de todos modos, no solo lo sigo usando, ya que recomiendo a todos que lo usen

En lo que respecta al filtrado de correo, he estado muy contento con la combinación de Spamassasin y policyd-weight , que verifica el nombre de host del remitente y las listas de bloqueo durante la conexión SMTP. Eso es una gran cosa por dos razones:

1. no tiene que procesar el correo electrónico rechazado con spamassasin, que le ahorra recursos del sistema (el análisis bayesiano lleva algo de tiempo) y el ancho de banda
2. los hosts del remitente son rechazados, por lo que en el improbable caso de bloquear el correo electrónico legítimo, el remitente recibe una notificación de falla de entrega

Estoy usando la configuración en Postfix, pero supuestamente hay una manera de instalar policyd-weight con Exim .

No entendí completamente la idea, sinceramente.

Ok, estoy diciendo que mi servidor de correo primario es falso. ¿Entonces? ¿No existe en absoluto o qué? (Supongamos que, por fin, elimine parte de los SPAMers de cualquier manera). Los "sobrevivientes" usarían la secundaria, no hay problema. Pero, ¿por qué hay un tercer servidor en esta configuración?

Como se supone que esta es mi respuesta, no una pregunta, concluiría que sí: está enferma y es una pálida sombra de Greylisting. Si quieres ver un efecto real, intenta usar Greylisting, hombre .

Dejo caer la mayor parte de mi correo no deseado al retrasar las conexiones a los hosts que figuran en la lista zen de Spamhaus. A los robots de spam no les gusta el retraso. La detección de falsificaciones obvias del servidor en el comando HELO también elimina una gran cantidad de correo no deseado. Las condiciones que he encontrado para indicar falsificaciones del servidor incluyen.

• Usando mi nombre de host o dirección IP.
• Usando un nombre de host no calificado.
• Usando un literal de dominio ([192.0.2.15]) en lugar de un FQDN. (Sí, los RFC lo requieren, pero en la actualidad no lo usan los servidores de correo de Internet).
• SPF que falla para el nombre HELO no Mail (bloqueo en caso de error, softfail y neutral).

Si valora el correo automatizado o de marketing, verifique el comando HELO que no funciona, incluido. Mi experiencia es que todos los demás correos pasan estas condiciones.

• Usar un nombre de dominio de segundo nivel en lugar de un FQDN para el host.
• Requerir el nombre de IP o HELO para verificar rDNS.
• Requerir un dominio de segundo nivel válido para el FQDN. (local no es un dominio válido ni lo es localdomain).

Firmar su ruta de regreso le permite bloquear algunos correos no deseados. Aunque estoy viendo muchos menos rebotes falsos recientemente.

Desafortunadamente, encuentro que un alto porcentaje de correo legítimo automatizado o de marketing falsifica su camino de regreso. Estos hosts a menudo tampoco tienen una dirección válida de administrador de correo. Sí encuentro que requerir un dominio válido en la ruta de retorno es viable. Recibo mucha más respuesta de falla SPF en correo electrónico legítimo que spam.

Recientemente publiqué mis experiencias con el bloqueo de spam con Exim

Además de los correos electrónicos perdidos de personas legítimas con puertas de enlace rotas, se ha intentado hace mucho tiempo (como hace 15 años +/-) y los spammers se adaptaron a él casi de inmediato. Sospecho que será una pérdida neta para la confiabilidad de su correo electrónico y tendrá poco o ningún impacto en el correo no deseado. Sin embargo, si lo intenta, envíenos los resultados.

Desafortunadamente, hay ciertos operadores que no le enviarán correo si no se puede acceder al primer registro MX. Recientemente escribí mis experiencias con esto en una entrada de blog, así que no lo repetiré aquí. Sin embargo, el resumen es que mi primer registro MX fue en realidad un registro MX solo IPv6 ya que supuse que los spammers no usan IPv6 (todavía). Desafortunadamente, esto causó problemas y al final tuve que agregar una dirección IPv4 al primer registro MX en mi zona.