Mailinglist Archive: opensuse-es (2177 mails)

["Carlos E. R." <robin1.listas@xxxxxxxxxx>]

El 2004-10-17 a las 12:19 +0200, Camaleón escribió:

> Carlos E. R. wrote:
> 
> > Si un usuario está en la lista blanca, aunque sea un spammer, entra
> > directamente, sin más.
> 
> Claro, por eso ese parámetro no me sirve.
> 
> > Si está en la de whitelist_from_rcvd, sólo lo considerá como "blanco" si
> > ha llegado a través del relay del servidor correspondiente a su dominio.
> > Si no coincide, no lo considerará blanco, y le aplicará el resto de
> > reglas.
> 
> Ese es el objetivo. Pero mis correos tienen 3 cabeceras "Received from:":
> 
> La de fetchmail (local) --> trusted
> La del servidor remoto POP3 de donde bajo el correo --> trusted
> La del usuario que envía el correo --> no trusted
> 
> Si tengo:
> 
> whitelist_from_rcvd *@terra.es terra.es
> 
> trusted_networks 192.168/16 << rango de red interna
> trusted_networks 213.4.129.130 << ip del mx de terra
> 
> Si el correo dice que viene de "From: usuario@xxxxxxxx"...
> 
> ¿Cómo distingue SA qué cabecera from es la que tiene que hacer coincidir con
> la IP de "trusted_networks"?

       whitelist_from_rcvd addr@xxxxxxxxxxxxxxxxxxxxx sourceforge.net
           Use this to supplement the whitelist_from addresses with a
           check against the Received headers. The first parameter is the
           address to whitelist, and the second is a string to match the
           relay's rDNS.

"el segundo parámetro es un string que debe encajar con la resolución
inversa del nombre del relay.

Esto aplica al servidor en el que entra el correo - que se supone que es
el tuyo, no el de tu isp que provee internet, no el del pop3. No valdrá en
ese caso.

Me explico.

Tomo como ejemplo un correo rebote de un basura (backscatter) para sacarle
unas cabeceras.

From: MAILER-DAEMON_at_eyou.com

Received: from pop.tiscali.es [212.166.64.66]
    by localhost with POP3 (fetchmail-5.9.0 polling pop.tiscali.es account ****)
    for cer@localhost (single-drop); Wed, 06 Oct 2004 01:24:25 +0200 (CEST)
Received: from eyou.com (61.136.62.74) by netmail.tiscali.es (6.7.021.1)
        id 4124C82500507F01 for ****@tiscali.es; Wed, 6 Oct 2004 01:05:28 +0200


	Inciso. En "netmail.tiscali.es (6.7.021.1)" ahí arriba el número
	no es la ip, sino la versión del smtp o del sistema; por ejemplo, 
	aquí se ve mejor:

	Received: from localhost (localhost [127.0.0.1])
	    by telperion.valinor (Postfix on SuSE Linux) with ESMTP id 62B984DE

	Además, la he buscado y es del DoD. ;-)


La primera cabecera es una que inserta el fetchmail cuando se usa con 
la clave "tracepolls" (no el postfix). La cabecera que nos interesa
es la segunda, donde se ve el "eyou.com". El "From" también era de
"eyou.com". Ya tenemos un encaje, valdría, en principio. Y...  ¿porqué esa
linea? Pues porque tienes que haber citado la ip de tiscali, 212.166.64.74
como "trusted".

	¿Porque esa IP? Por esto:

	cer@nimrodel:~> host netmail.tiscali.es
	netmail.tiscali.es has address 212.166.64.74
	cer@nimrodel:~> host 212.166.64.74
	74.64.166.212.in-addr.arpa domain name pointer netmail.tiscalinet.es.
	74.64.166.212.in-addr.arpa domain name pointer netmail.tiscali.es.


	

Vale. Pero resulta que el SA, en el received no mira el string "eyou.com"  
(que es el nombre que el relay dice de si mismo, y puede ser falso), sino
la IP "61.136.62.74", que es en cambio conseguida por el servidor smtp que
recibe, en este caso, de tiscali, y del cual nos fiamos. A esa IP se le
calcula el rDNS, o sea, el resultado de la orden "host" sobre esa IP. Eso
te dará un nombre (que puede ser o no "eyou.com"), que digamos será "XXX".


	En este caso tendríamos un problema grave, porque esa IP de 
	nuestro amigo del "from" no tiene resolución inversa:

	cer@nimrodel:~> host 61.136.62.74
	Host 74.62.136.61.in-addr.arpa not found: 3(NXDOMAIN)

	Y la directa no da esa IP, aunque en realidad ambas le pertenecen:

	cer@nimrodel:~> host eyou.com
	eyou.com has address 61.136.62.73


La configuración del SA sería entonces, si XXXX fuera la resolución 
inversa de marras:

  whitelist_from_rcvd   eyou.com  XXXX
  trusted_networks 6.7.021.1

Problema: 
  ¿Es realmente confiable esa red? 
  ¿Tiene otros efectos? 
  ¿Varía la IP alguna vez?

Ten en cuenta que no es "nuestra"...

Mas problemas:
  Que el remitente no tenga rDNS, o mejor dicho, su proveedor - que como 
acabas de ver en este caso, ocurre.



> > Vale, pero si me pones en la lista de "whitelist_from_rcvd", es como si no
> > hicieras nada. Probablemente pase, pero la regla en si no hace nada conmigo.
> > Es decir, estoy en la lista blanca, pero no coincide el received: dirá que
> > lo he falseado.
> 
> Si lo has falseado pueden pasar dos cosas:
> 
> 1) Que el contenido de tu correo no sea spam, y aunque a tu correo le afecten
> las reglas bayesianas no será considerado como spam. También está la
> puntuación de AWL (autowhitelist) si eres un habitual, lo que puede hacer
> bajar la puntuación. El correo pasa el filtro.
> 
> 2) Que el contenido de tu correo sea spam y se le asigne una puntuación alta
> (BAY_99), por lo que será rechazado.

Pero la regla "whitelist_from_rcvd" para los mios no actúa, es lo que
trato de decirte. Tendrías que poner "whitelist_from" a secas, en cuyo
caso te arriesgas a que alguno que se haga pasar por mi te entre. o 
confiar en el resto de reglas.

O dicho de otra forma, ponerme en "whitelist_from_rcvd" es como no hacer 
nada, por la sencilla razón que no uso el relay de tiscali (ni de otro).

-- 
Saludos
       Carlos Robinson