Mail Delivery SPAM

[Alvaro Herrera]

Aldrin Martoq escribió:
> On Fri, 2008-05-09 at 11:59 -0400, Alvaro Herrera wrote:

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

Por supuesto.  Pero te estás poniendo desde un punto de vista distinto
al que me pongo yo.  Yo estoy viéndolo no desde el usuario, sino desde
el servidor SMTP que recibe el correo.  No me da para hacer un mono,
pero la cosa es más o menos así:

usuario ---> SMTP de envío (1) ---> SMTP de recepción (2) ---> destinatario

Pensándolo desde (2), si la cuenta no existe tengo dos alternativas: a)
aceptar el correo, ponerlo en la cola, darme cuenta que la cuenta no
existe, generar un rebote.  Si el usuario es malicioso y me puso en el
"Sender:" o en el "From:" una dirección de una víctima, yo tengo que
generar un rebote que vaya dirigido a la víctima,  Así nosotros dos (el
SMTP (2) y la víctima) perdemos porque estoy generando backscatter.

La otra alternativa b) es que (2) le diga inmediatamente a (1) que la
cuenta no existe, y que se meta el email donde mejor le quepa.  Entonces es
problema de (1) hacerle llegar el rebote al usuario, y aquí no hay
problema de backscatter.  (En caso de haberlo, (1) es un relay abierto y
se merece el castigo por idiota.  Afortunadamente hay muchos menos de
estos hoy en día; el problema de hoy son los zombies, que son el motivo
por el cual algunos ISPs bloquean el port 25).

-- 
Alvaro Herrera                          Developer, http://www.PostgreSQL.org/
"And as an added bonus, now my computer goes to the toilet for me, leaving me
free to spend time on more useful activities! yay slug codefests!" (C. Parker)