Mail Delivery SPAM

[Germán Póo-Caamaño]

On Fri, 2008-05-09 at 15:09 -0400, Aldrin Martoq wrote:
> On Fri, 2008-05-09 at 11:59 -0400, Alvaro Herrera wrote:
> [...]
> Si la casilla no existe, en ambos casos el usuario recibe el rebote de
> "esta casilla no existe": a menos que hagas telnet a cada MX, usualmente
> envias correo a traves de un SMTP "local" y este reenvia al destinatario
> y eventualmente te da un rebote si no pudo enviar el correo.
> 
> Ahora, el tema de rebotar al principio (sin recibir/encolar) o despues
> (con recibir/encolar) es lo que llama el articulo "backscatter". El
> problema no es el rebote que en ambos casos le llega al usuario, sino
> los rebotes "innecesarios" generados por quienes hacen spam.
> 
> 
> 
> > El segundo caso es totalmente aceptable y deseable, y es lo que Germán
> > llama "se debería hacer por diseño".  Dado que el mensaje no fue
> > aceptado (encolado), entonces no hay ningún "innocent bystander" que
> > vaya a recibir backscatter, así que no se produce ningún inconveniente.
> 
> Yo estoy de acuerdo en parar un mensaje lo antes posible (como el
> usuario no existe o algun RBL), pero tambien creo que es muy util
> rebotarlo despues de haber pasado los filtros mas basicos.

Depende de lo que quieras proteger. El usuario externo o tu
servicio/ancho de banda.

Si quieres proteger tu servicio, entonces rechazas cuanto antes;
de lo contrario te quedas con una cola gigante de mensajes de rebote.
Por ejemplo, típicos ataques a Gmail/Hotmail/Aol, en donde te inundan
con correos de esta naturaleza, utilizando tu servidor como reflector.

Si no rechazas el mensaje en el diálogo SMTP, usarás el doble de ancho
de banda (cuando recibes el mensaje y cuando lo rebotas), correrás el
riesgo de ser declarado como spammer, tus colas de correos serán más
grande, ocuparás más recursos de antivirus/antispam.

> > Además, es a este nivel donde funciona lo de responderle al spammer con
> > "esta casilla no existe".
> 
> Si no encolas el mensaje (lo recibes), no puedes analizarlo y saber si
> es SPAM o no, a menos que te bases en la (poquisima) informacion durante
> la conexion.

No, pero si recibes el mensaje y tu servidor luego envía un mensaje de
error, entonces la fuente del SPAM es tu servidor.

Si rechazas el mensaje en el diálogo SMTP, entonces quien deben enviar
el rebote es el servidor que intentó entregarte el mensaje.

Además, el camino de regreso (para el rechazo) no es tan largo.

-- 
Germán Póo-Caamaño
http://www.calcifer.org/