[postfix-es] Como evitar backscatter?

[Jesus Salvador Anton]

Hola

Lo normal es que postfix rechace la conexion, en ningun momento deberia
enviar un correo cuando un usuario no existe.
El correo que se recibe normalmente cuando hay un fallo al enviar, lo
autogenera el propio servidor de origen.

Este es un ejemplo de mi servidor:

May 30 20:57:00 server postfix/smtpd[32474]: NOQUEUE: reject: RCPT from
unknown[000.000.000.000]: 550 5.1.1 <info en dominio.com>: Recipient address
rejected: User unknown in virtual mailbox table; from=<ralf.prass en xxxxxx.de>
to=<info en dominio.com> proto=ESMTP helo=<[......]>

Un saludo

2011/5/26 BhEaN <listas en bhean.com>

> Hola a todos,
>
> Me gustaría saber cómo puedo evitar que Postfix reenvie el correo original
> al remitente en aquellos casos en los que no pueda enviar el mensaje al
> destinatario?
> Por ejemplo, si el usuario A envia un email al usuario C, pero el usuario C
> no existe, se le reenvia el mensaje de nuevo a A con el típico "Undelivered
> Mail Returned"....
>
> El problema es que algunos spammers envian mensajes a direcciones que NO
> existen, pero usando como remitente la dirección de las personas a las que
> quieren enviar el mensaje, lo que hace que al no poder entregar el mensaje
> el servidor destino (porque la dirección NO existe), lo reenvia al
> remitente, diciendo que no ha podido entregar el mensaje.... pero junto a
> ese aviso de error, llega el mensaje original tambien, luego al usuario le
> llega igualmente el spam...
>
> Como podría hacer para que Postfix siguiera comportandose igual, pero que
> NO reenvie el mensaje original en los "Undelivered Mail Returned"??
>
> Muchas gracias por adelantado,
>
>
> _______________________________________________
> List de correo postfix-es para tratar temas del MTA postfix en español
> postfix-es en lists.wl0.org
> http://lists.wl0.org/mailman/listinfo/postfix-es
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.wl0.org/pipermail/postfix-es/attachments/20110530/e7da56b5/attachment.html>