Mail Delivery SPAM

[Aldrin Martoq]

On Fri, 2008-05-09 at 11:59 -0400, Alvaro Herrera wrote:
> Aldrin Martoq escribió:
> > On Thu, 2008-05-08 at 17:04 -0400, Ricardo Utreras Estrella wrote:
> > > Germán Póo-Caamaño escribió:
> > > > On Thu, 2008-05-08 at 09:45 -0400, Ricardo Utreras Estrella wrote:
> > > >> Exactamente! Ese fue uno de los motivos por los cuales migre de
> > > Qmail a 
> > > >> Postfix en una empresa.
> > > >> Qmail tiene la mala costumbre de por defecto "indicar amablemente cuando 
> > > >> una casilla no existe", lo cual no se deberia hacer.
> > > > Al contrario, es lo que debería hacer por diseño.
> > > Quizas hace 20 años uno podia llegar y enviar dicho aviso, pero ahora 
> > > hay que tener cuidado a quien se le responde.
> > 
> > Responder que no existe una casilla me parece de lo mas adecuado, no veo
> > el escenario donde esto sea "malo". De hecho, hay gente que responde
> > contra el spam asi: si alguien te envia un correo no deseado, devuelves
> > un error de "esta casilla no existe". Asi, el spammer piensa que la
> > casilla ya no existe y eventualmente te borra [no siempre! ;)].
> 
> Hay que separar dos tipos de aviso de no envío: una es recibir el mail y
> posteriormente enviar un mail de "destinatario no existe" al remitente.
> Otra es responder en la misma sesion SMTP con un mensaje de error
> "destinatario no existe", _sin_ encolar el mensaje localmente.
> 
> Tipicamente el primer caso sucede cuando tienes un MX de backup que no
> sabe cuales son los usuarios validos en el sistema.  Tambien sucede en
> Qmail porque el proceso que recibe el correo no tiene acceso a la lista
> de usuarios validos del sistema.  Esto es terrible porque genera el
> backscatter.  Idealmente esto se deberia evitar todo lo posible.

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.


> 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.


-- 
Aldrin Martoq <amartoq en dcc.uchile.cl>
http://aldrinvideopodcast.podshow.com/