El 2004-11-27 a las 19:42 +0100, Camaleón escribió:

On Sat, 27 Nov 2004 00:20:12 +0100 (CET), Carlos E. R. wrote:

...

MAIL FROM: <> SIZE=33229, el from del sobre viene en blanco. ¿Que se os ocurre para filtrar esos?

Busca en la cabecera del mensaje algún elemento que pueda identificar Postfix y que se relacione con los autorrespondedores. Si envías la cabecera del correo, mejor.

Si, ya, con headers-checks. Pero... cuando eso actua, el mensaje ya ha empezado a descargarse, y el fetchmail lo descargará entero con el objeto de rebotarlo después. Eso es un fastidio usando modem. Tengo que rechazarlo basándome en la negociación SMTP de comienzo. Lo que creo que me conviene es que el postfix rechace correos cuya dirección de origen sea falsa: y una dirección en blanco es falsa. El rechazo mediante /etc/postfix/access es magnífico, porque: 1) el postfix rechaza recibirlo 2) el fetchmail intenta enviar un rebotarlor, pero tampoco puede, porque la dirección rechazada figura en la dirección, el postfix no acepta tampoco el rebote. No llega ni a descargarse, si mal no recuerdo. Pero en este caso no funciona. ¿Las cabeceras? Pues mira - observa la primera linea, es el "envelope-from": Return-Path: <> X-Original-To: cer@localhost.nimrodel.valinor Delivered-To: cer@localhost.nimrodel.valinor Received: from localhost (localhost [127.0.0.1]) by nimrodel.valinor (Postfix) with ESMTP id 7806120C4E for ; Sat, 27 Nov 2004 00:23:47 +0100 (CET) Received: from nimrodel.valinor ([127.0.0.1]) by localhost (nimrodel [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10206-03-14 for ; Sat, 27 Nov 2004 00:23:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by nimrodel.valinor (Postfix) with ESMTP id F066520C4D for ; Sat, 27 Nov 2004 00:23:23 +0100 (CET) .... Received: from [172.30.8.43] (helo=mx.mixmail.com) by relay.mixmail.com with esmtp id 1CXnY0-0007vU-00 for rob**@tiscali.es; Fri, 26 Nov 2004 22:22:32 +0100 Received: from mta by mx.mixmail.com with local id 1CXnY0-0001VL-00 for rob**@tiscali.es; Fri, 26 Nov 2004 22:22:32 +0100 X-Failed-Recipients: ju*****@mixmail.com Reply-To: postmaster@mixmail.com From: Mail Delivery System To: rob**@tiscali.es Subject: Mail delivery failed : returning message to sender Message-Id: Date: Fri, 26 Nov 2004 22:22:32 +0100 X-Virus-Scanned: by amavisd-new at nimrodel.valinor X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on nimrodel.valinor X-Spam-Level: X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, LARGE_HEX,UPPERCASE_25_50 autolearn=no version=2.64 Content-Length: 31893 Lines: 467 This message was created automatically by mail delivery software. A message that you sent could not be delivered to all of its recipients. The following address(es) failed: j****@mixmail.com This message has been rejected because it has potentially executable content "Toy.cpl" This form of attachment has been used by recent viruses or other malware. If you meant to send this file then please package it up as a zip file and resend it. Este mensaje ha sido rechazado porque es probable que tenga adjunto un fichero ejecutable "Toy.cpl" Este tipo de ficheros es usado por virus para propagarse por la red Si usted quiere enviar este fichero le recomendamos que lo comprima con ZIP y envie de nuevo el email. ------ This is a copy of the message, including all the headers. ------ .... y luego viene el mensaje supuestamente mio con la carga viral. Por eso digo que es un administrador de correo incapaz y $·!$·%&$/&$/%$ - si eres lector de comics sabrás que significa eso ;-) O sea, el sistema detecta que el correo recibido es un ejecutable o posible virus, lo rechaza y lo devuelve, ¡con la carga viral intacta! Eso sabiendo que la dirección de origen en muchos virus es falseada es una solemne cabronada (perdón por la expresión - frs...frsss, me enjabono la boca, o sea, los dedos), porque está enviando el presunto virus a gente totalmente inocente. :-/ Es lo que la documentación del postfix llama "backscattering". -- Saludos Carlos Robinson

El 2004-11-28 a las 01:49 +0100, Camaleón escribió:

...

Received: from localhost (localhost [127.0.0.1]) by nimrodel.valinor (Postfix) with ESMTP id 7806120C4E for ; Sat, 27 Nov 2004 00:23:47 +0100 (CET) Received: from nimrodel.valinor ([127.0.0.1]) by localhost (nimrodel [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10206-03-14 for ;

Humm, ¿detecto cierto gustillo por los libros de fantasía tipo El Señor de los Anillos, Dragonlance, Mundodisco, etc...? Nimrodel y Valinor me resultan familiares... ;-)

Y el otro ordenador es telperion. O:-) Tolkien, "The Silmarillion": "Of the Beginning of Days". Valinor es la que sería la isla más alla de la tierra media donde vivían los altos elfos con los valar... y nimrodel y telperion son los "dos arboles de valinor", telperion tenía sus hojas con envés de color plata, y nimrodel oro. Ambos daban una luz maravillosa, etc, etc. Vale, me callo, es un oftopicazo como una casa ;-)

...

Received: from [172.30.8.43] (helo=mx.mixmail.com)

Bueno, pues esto no me cuadra. Un ping a mx.mixmail.com me devuelve 62.151.8.40, no la que dice ser (172.30.8.43). ¿Es un bloque de red interna o está falseado? Sospechoso.

¡Anda! No lo había mirado, porque como me conecto por modem no pude hacer la prueba cuando lo vi. La orden "host" dice que "not found", pero "whois" da una información muy interesante: cer@nimrodel:~> whois 172.30.8.43 OrgName: Internet Assigned Numbers Authority OrgID: IANA Address: 4676 Admiralty Way, Suite 330 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName: IANA-BBLK-RESERVED NetHandle: NET-172-16-0-0-1 Parent: NET-172-0-0-0-0 NetType: IANA Special Use NameServer: BLACKHOLE-1.IANA.ORG NameServer: BLACKHOLE-2.IANA.ORG Comment: This block is reserved for special purposes. Comment: Please see RFC 1918 for additional information. Comment: Y mirando en /usr/share/doc/rfc/rfc1918.txt.gz veo: | Address Allocation for Private Internets | |... | | |3. Private Address Space | | The Internet Assigned Numbers Authority (IANA) has reserved the | following three blocks of the IP address space for private internets: | | 10.0.0.0 - 10.255.255.255 (10/8 prefix) | 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) | 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) | ¡AHHH! Claro, una IP de rango privado, ¿como no me di cuenta? Supongo porque lo habitual es el 10.*.*.* y el 192.168.*.*, no tengo esa IP memorizada. A ver, miremos las cabeceras de nuevo: Received: from relay.mixmail.com (62.151.8.30) by netmail.tiscali.es (6.7.021.1) id 417E0DD0003A00E4 for ***@tiscali.es; Fri, 26 Nov 2004 22:22:33 +0100 Received: from [172.30.8.43] (helo=mx.mixmail.com) by relay.mixmail.com with esmtp id 1CXnY0-0007vU-00 for ***@tiscali.es; Fri, 26 Nov 2004 22:22:32 +0100 Received: from mta by mx.mixmail.com with local id 1CXnY0-0001VL-00 for robin1.listas@tiscali.es; Fri, 26 Nov 2004 22:22:32 +0100 Ya, ya me doy cuenta de lo que pasa: no tiene importancia. Recuerda que la cabecera "Received" más antigua es la de abajo. Pues entonces lo que se ve es simplemente que el correo es generado en una intranet, se supone que en la intranet de mx.mixmail.com, que lo pasa al servidor con vista al exterior (o tiene dos nics, una interna y otra externa), relay.mixmail.com quien lo pasa a tiscali. La ultima cabecera, la de arriba, es la de tiscali, es fiable, y fijate que dice que recibe la conexión desde 62.151.8.30, que es la que te dió tu ping.

...

Reply-To: postmaster@mixmail.com

Puedes probar a filtrar por "postmaster@mixmail.com"

No, no está en la negociación SMTP inicial.

...

X-Spam-Status: No, hits=-3.9

¿Negativo? Lo debes de tener muy bien entrenado.

Si, se me escapan muy pocos; este no lo he alimentado al sa-learn, porque no quiero filtrar los virus por ese metodo, sino como virus.

...

version=2.64

Actualiza a la 3.0.1

No, me esperaré a actualizar a suse 9.2 y entonces veremos que hago. :-)

...

.... y luego viene el mensaje supuestamente mio con la carga viral. Por eso digo que es un administrador de correo incapaz y $·!$·%&$/&$/%$ - si eres lector de comics sabrás que significa eso ;-)

:-D

A buen entendedor sobran palabras ;-)

...

Es lo que la documentación del postfix llama "backscattering".

Jo, qué palabra tan bonita, no la había oido antes, pero me suena muy bien.

Si, me encantó cuando la vi. Los angloparlantes tienen un idioma muy maleable para estas cosas. Por cierto, lo que he hecho de momento, es en "/etc/postfix/main.cf" hacer este cambio: #smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_sender_restrictions = hash:/etc/postfix/access,reject_non_fqdn_sender Que lo que se supone que hace es: reject_non_fqdn_sender Reject the request when the address in the client MAIL FROM command is not in fully-qualified domain form. The non_fqdn_reject_code specifies the response code to rejected requests (default: 504). La otra posibilidad que he barajado es: reject_unknown_sender_domain Reject the request when the sender mail address has no DNS A or MX record. The unknown_address_reject_code parameter specifies the response code for rejected requests (default: 450). The response is always 450 in case of a temporary DNS error. El sendmail de suse venía precisamente con esta opción activada, que por supuesto enlentece un poco el correo, claro, al tener que disparar una consulta DNS para cada remite nuevo, hasta que se le olvide. Y usando modem se nota, aunque tenga mi propio dns local como caché. Pero el postfix la trae desactivada. Es que hay que fijarse que el correo tiene dos direcciones de retorno: Return-Path: <> From: Mail Delivery System La primera es el "envelope-from", y la segunda el "from" normal. Y el remite del sobre está vacío, y ese es precisamente el que comprueba el postfix con las reglas de access: The smtpd_sender_restrictions parameter restricts what sender addresses this system accepts in MAIL FROM commands. By default, this restriction is applied when the client sends the RCPT TO command. In order to have the restriction take effect as soon as possible, specify smtpd_delay_reject = no in the Postfix main.cf configuration file. Doing so may cause unexpected results with poorly implemented client software. O sea, el postfix hace el chequeo con lo que se ve en esta entrada del log: Nov 26 23:57:25 nimrodel fetchmail[14958]: SMTP> MAIL FROM: <> SIZE=33229 que efectivamente está en blanco. Esperemos que "reject_non_fqdn_sender" la rechace. Ya contaré que pasa. -- Saludos Carlos Robinson

El 2004-11-30 a las 19:49 +0100, Luis escribió:

Resulta raro ver a Carlos generando un hilo, cuando lo habitual es que los termine ;-) (suele ayudar más, que pedir ayuda).

Alguna vez tiene que ser, ¿no? Lo que se no lo saco del aire, de alguien he tenido que aprender ;-)

Y este en concreto ... mola, ya que tenemos a la experta en Postfix de la lista en persona... sigo impaciente el desenlace ... estoy aprendiendo mucho.

Pos yo te voy a "morder" - has respondido a un correo de 10 kilobytes añadiendo un parrafito al final, y sin borrar los 10Ks precedentes... ¡GRRRR! X'-) Bueno, siguiendo con el hilo: He probado, como dije: smtpd_sender_restrictions = hash:/etc/postfix/access,reject_non_fqdn_sender y no funciona, me sigue entrando. He activado este otro, para rechazar los dominios desconocidos: smtpd_sender_restrictions = hash:/etc/postfix/access,reject_non_fqdn_sender,reject_unknown_sender_domain pero tampoco funciona, éste emilio que llega con un "from" en blanco en el sobre sigue entrando :-( Eso si, ahora el postfix me rechaza el correo entrante con dominios falsos: Nov 30 21:25:11 nimrodel fetchmail[9124]: SMTP error: 450 : Sender address rejected: Domain not found pero el fetchmail no me los borra del servidor, los deja: Nov 30 21:25:11 nimrodel fetchmail[9124]: SMTP> RSET Nov 30 21:25:11 nimrodel fetchmail[9124]: SMTP< 250 Ok Nov 30 21:25:11 nimrodel fetchmail[9124]: not flushed Nov 30 21:25:11 nimrodel fetchmail[9124]: POP3> QUIT ¡¡¡Argh!!! :-/ -- Saludos Carlos Robinson

El 2004-11-30 a las 21:31 +0100, Camaleón escribió:

On Sun, 28 Nov 2004 03:12:41 +0100 (CET), Carlos E. R. wrote:

...

O sea, el postfix hace el chequeo con lo que se ve en esta entrada del log:

Nov 26 23:57:25 nimrodel fetchmail[14958]: SMTP> MAIL FROM: <> SIZE=33229

que efectivamente está en blanco. Esperemos que "reject_non_fqdn_sender" la rechace. Ya contaré que pasa.

Creo que se trata más bien de un problema de "concepto" más que de "ejecución", es decir, si realmente quieres rechazar un correo que contenga una cabecera con el campo "return path" vacío. Con "header_checks" puedes hacerlo fácilmente y filtrar / rechazar por lo que quieras (¿una expresión regular para valores null?), pero habría que ver si no afecta a otro tipo de correos legítimos pero mal configurados. Este es el típico correo "complejo", que pertenece a la categoría de los denominados "legales" pero que nadie quiere recibir.

:-)

La solución pasa por algunas de las opciones de Posfix:

http://www.postfix.org/uce.html

Ya, ya. Ya se que con headers_check se puede. Me bastaría con algo como: /^From:.*\@microsoft\.net/ REJECT Pero yo lo quiero hacer antes de llegar ahí, y normalmente lo consigo. Es únicamente en este caso concreto que no lo consigo. Durante la negociación del SMTP se le dice al servidor que tenemos un correo de fulano para setano - antes de enviar nada del correo, ni cabeceras ni nada. Es con ese "from", llamado "envelope_from", con el que yo quiero rechazarlo. Eso se hace con esto: smtpd_sender_restrictions = hash:/etc/postfix/access y basta con poner lineas como esta en el access: Mailer-Daemon@host29.ipowerweb.com REJECT Blocking backscatter mail from virus scanners y ese remite no entra en mi casa, es que ni miro cabeceras ni nada, le rechazo la conexión. En cambio, esta otra linea igual, salvo en el dominio: mailer-daemon@mx.mixmail.com REJECT Blocking backscatter mail from virus scanners no funciona. Y no funciona porque ese servidor se identifica en blanco (el "<>" no contiene nada dentro): SMTP> MAIL FROM: <> SIZE=33229 Y no consigo rechazar ese correo. Entiendo que no es un nombre completamente cualificado de dominio (FQDN), puesto que está en blanco, y tampoco es un nombre existente, puesto que está en blanco. ¡Es que no es un nombre! Entonces, ¿como es posible que, sin embargo, el postfix lo acepte? No lo entiendo. Pero así es, la regla: smtpd_sender_restrictions = hash:/etc/postfix/access,reject_non_fqdn_sender,reject_unknown_sender_domain no rechaza ese correo con el "envelope_from" en blanco. Ese es el problema. -- Saludos Carlos Robinson

On Wed, 1 Dec 2004 10:29:29 +0100, Camaleón wrote:

Porque está permitido (al menos eso creo), por eso Postfix no lo rechaza. Las reglas que comentas están en el apartado de UCE y están dirigidas a poner el freno a los correos "falsos", pero falsos de verdad. Este pobre correo con valores "null" no es falso, es auténtico, por eso Postfix lo acepta.

Estaba pensando que quizá Fetchmail te pueda ayudar en ésto: http://catb.org/~esr/fetchmail/fetchmail-man.html#23 Saludos, -- Camaleón

El 2004-12-01 a las 12:12 +0100, Camaleón escribió:

Y también Google te puede dar alguna pista...

http://www.google.com/search?hl=en&lr=&q=reject+empty+Return-Path%3A

Si, aquí da una explicación: debian-isp lists.debian.org From: Michael Loftis Re: Postfix doesn't reject empty senders It is an RFC requirement to accept <> as a valid MAIL FROM -- almost all bounce messages use this as well as certain other circumstances, to indicate they do not wish to receive a bounce message in the event of a delivery error. I don't even think that postfix allows it to be turned off at all. Franz Georg Ko:hle You must not reject messages with an empty envelope-from since those are delivery status notifications (aka "error messages"). Hay que fastidiarse :-/ O sea, que suelen ser rebotes (cierto, lo es), pero es que el puñetero rebote es un virus de 32 kilobytes que no me interesa perder el tiempo en descargar, y manda demasiados. -- Saludos Carlos Robinson