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