¿Suena fea la palabreja, verdad? Pues si suena fea, peor será. Y es que se trata de un ataque que sufrimos hace unos días en nuestro servidor de correo de Nireblog y contra el que poco se puede hacer. Recibe otros nombres como outscatter, misdirected bounces, blowback o collateral spam. Incluso Juanjo lo bautizó en su día como tormenta de bounces.
¿En qué consiste este spam lateral? Pues simple y llanamente, los señores spammers se dedican a mandar esos mensajes molestos a diestro y siniestro poniendo como emisoras direcciones aleatorias de tu dominio. Es decir, mandan mensajes a direcciones que generan aleatoriamente de hotmail (por poner un ejemplo), diciendo que son pepitoeldelospalotes@nireblog.com (esta dirección también la generan aleatoriamente).
¿Esto se puede hacer? Vaya que si se puede y además de una forma sencilla (SMTP no es que sea un protocolo pensado para la seguridad…). No quiere decir que manden el spam a través de nuestros servidores, sino que simplemente falsean el from.
¿Y qué es lo que sucede entonces? Pues que mandan mensajes a direcciones que ni siquiera existen. Por tanto, el servidor que recibe el mensaje manda un bounce (notificación de que no se ha podido entregar, los famosos undeliverable mail) hacia el emisor del mensaje. Pero como ese emisor se ha falseado y se ha puesto uno de nuestro dominio, nos llega a nosotros como una auténtica tormenta. Si tenemos configurado nuestro servidor de correo para que lea de base de datos las cuentas existentes, podrá afectar a su rendimiento porque estamos hablando de cientos de mensajes por segundo a los que hay que comprobar su destinatario.
¿Y cómo lo descubres? Porque te están llegando un montón de mensajes que no tienen mail from (la mayoría de rebotes llega así). Por cierto, es importante tener un sistema de monitorización del servicio de correo para enterarte rápido de lo que te está sucediendo. Nosotros usamos para ello mailgraph, que es muy sencillo de instalar y configurar.
¿Y qué se puede hacer? Pues como he dicho al inicio, poco o nada. Como mucho cambiar el mensaje de unknown_local_recipient_reject_code de un 450 a un 550. El 450 implica un inténtalo de nuevo más tarde, por lo que el bombardeo durará más puesto que no le decimos desde un inicio que no existe esa dirección en nuestro servidor (lo que sí se consigue con un 550 que es un reject en toda regla).
Pero lo que sí se podría hacer para evitar ser uno de los «cómplices» de los bombardeos de spam lateral es hacer una serie de comprobaciones a los correos antes de rechazarlos con su respectivo bounce. Porque si se trata de mensajes de spam o que contienen virus, lo mejor será descartarlos y no generar más ruido en la Red.
Y es que el mundo del correo electrónico es la jungla 😉
Yo personalmente creo que una buena solución para moverse en esa jungla creo que sería llamar a Tarzán 🙂
Estos últimos meses en mi blog y en general en todo nireblog detecto mucho cloacking. Es señal de que la plataforma está cogiendo mucho nombre, enhorabuena. A mi me suelen tocar los links de hoteles, edreams, etc..que intentan subir su ranking en Google y llevan a dominios falsos…La solución es facil: AUTORESPONSABILIZACIÓN.
Por cierto, ¿todo ésto estará organizado? 🙂 Cuanto le darán al que pone los links en mi blog o en el tuyo??
La siguiente vez, avisa, que no veas cómo somos los de Bilbao. Les ponemos de vuelta y media. Entre Txetxu, Tarzań y cuatro mas… 😉
Sí que se pueden hacer cosillas…VBounce de SpamAssassin es tu amigo 😉 Eso sí…MUCHO cuidado y configurándolo/tuneándolo al dedillo…
Solo dos ingredientes: Napalm + Cerilla. El problema es donde (y a quien) echarlo….
@txetxu: yo soy más de la mona Chita 😉
@ioannes xabier: la pena es que contra eso no podemos hacer nada, porque los comentarios los hacen personas (no robots). De todas formas, si detectas alguno, avisa y mirare su dirección ip. Si se reitera, le denegaremos el acceso
@julen: ya os veo metiendo tortas a los spammers 😀
@álvaro marín: eres mi gurú del correo. ¡Mil gracias Álvaro! Le echaré un ojo si la cosa se vuelve a poner fea
@may: joer… tú no te andas con chiquitas ¡Cómo se nota que eres de Basauri! 😀
Hola Loretahur:
En mi empresa también lo sufrimos, pero suele ser de golpe sobre un único buzón. Es decir, que el spammer utiliza un único remitente de nuestro dominio para enviar miles de mails, que los respectivos dominios se encargan de devolver al supuesto remitente, para su desesperación durante varios días.
La solución que hemos implementado con nuestro proveedor, es detectar envíos de «demasiados» NDR a un único buzón. En ese caso, los ponemos en cuarentena, y al día siguiente le enviamos automáticamente un mail al usuario con una lista de los mismos, para que si eran legítimos solicite su envío nuevamente desde la cuarentena.
Está funcionando bastante bien…
En cuanto a la medida que sugieres para evitar ser complices, comprobando si es spam antes de decir que no es entregable, veo algún problema:
Si detectas que es spam automáticamnte, nunca es 100% seguro, sino solo probable (aunque sea muy probable), con lo que tirarlo a la basura y no decir al remitente que no lo puedes entregar al destinatario no es un mecanismo compatible con el RFC standard.
Nosotros recibimos muuuuchos mails dirigidos a direccines inexistentes. Lo primero que hacemos cuando recibimos el comando «rcpt to:» es buscar el destinatario en nuestra librea de direcciones y rechazar la conexión en ese momento, con la respuesta standard de destinatario desconocido. Con eso no gastamos más ancho de banda al cerrar la conexión, ni capacidad de proceso, aunque tiene el efecto colateral que tu dices, de poder freir al pobre remitente que ha sido «spoofed». No hemos visto otra posibilidad de actuación sin salirnos de los standares… y queremos mantenernos en ellos.
@OceanO: la teoría dice lo siguiente: If you run a mail server you have a responsibility not to send backscatter. Bounces should ideally only be generated by a mail server to a local recipient. Mail servers should not generate bounces to non-local recipients, but should instead reject the mail during the SMTP session, and leave the remote sending server to handle the bounce: if a rejected mail is a legitimate message, the bounce gets generated by the remote sending machine, as expected; if a rejected mail is not a legitimate message, the remote end will probably not generate a bounce, and all is still well.
La solución pasa por usar SPF, pero para ello es necesario que se estandarice y obligue a su utilización. Pero esto suena a utopía (y más teniendo en cuenta que hay gente que ni siquiera tiene resolución inversa para sus servidores de correo…)