El día 8/11/06, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2006-11-08 a las 13:11 +0100, Emiliano Sutil escribió:

[SPF]

...

Alguien lo usa?

Yo no, obviamente, pero no me disgustaría poder comprobarlo en la recepción, por parte del SpamAssassin.

El SPF funciona incluyendo en el DNS información de qué máquinas están autorizadas para enviar correo con remite en tu dominio. La idea es rechazarlo si no viene de ahí.

Tiene muchos contras, en la wiki mencionan algunos y dan enlaces a otras discusiones del tema.

No está la cosa nada clara.

No, la verdad es que no, leyendo detenidamente la doc parece que puede presentar varios problemas, a parte del engorro de configurarlo Lo dejaremos estar de momento (a no ser que alguien nos convenza de que esta bien...) Un saludo Emi - --

Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76

iD8DBQFFUdLDtTMYHG2NR9URAtTTAKCBIsTbNjTxGqqNYhDCb8st6TaFXQCfdSF2 fhuYoEMHlizZe0Yq9vUwZ/A= =+M6T -----END PGP SIGNATURE-----

-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

engorro ?? pero hombre, basta agregar una linea al registro DNS, por ejemplo:

@ IN TXT "v=spf1 a"

con esto, ya configura vuestro SPF para que solamente acepten correos desde la direccion IP del servidor !!!

ahora, se me hablas de configurar el servidor de correo para comprobar el SPF, entonces te creo que puede ser un engedro !!! :-)

Pues no entiendo bien esto. Si solo acepta correos desde la direcion IP como se puede usar ese servidor como smtp, Un supuesto, tengo 2 oficinas cada una con su IP y todos los equipos de ambas oficinas usan el servidor como correo saliente. ¿Podria estar el servidor configurado asi? porque si solo acepta correos desde la direccion IP del servidor no veo como funcionaría. o eso o estoy entendiendo mal el concepto Emi

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-08 a las 16:21 +0100, Emiliano Sutil escribió:

...

engorro ?? pero hombre, basta agregar una linea al registro DNS, por ejemplo:

@ IN TXT "v=spf1 a"

con esto, ya configura vuestro SPF para que solamente acepten correos desde la direccion IP del servidor !!!

Falta explicarlo un poco más. example.org. IN TXT "v=spf1 a mx -all" Donde la "a" y "mx" indican las IPs correspondientes al registro "A" y al "MX" del dns del dominio, y "all" pues a ALL. Como la a y la mx no llevan simbolito, equivalen a "+a +mx", o sea, "PASS". El "-" de "all" es "fail. O sea, los receptores deberían aceptar los correos que vengan de las IPs marcadas con "A" o "MX" y rechazar el resto.

Si solo acepta correos desde la direcion IP como se puede usar ese servidor como smtp,

Debes indicar cual es la unica(s) IP(s) autorizadas para enviar correos desde ese dominio.

Un supuesto, tengo 2 oficinas cada una con su IP y todos los equipos de ambas oficinas usan el servidor como correo saliente.

Si envían por su cuenta, fallarían. Como envían usando el servidor (relay), funcionarían.

¿Podria estar el servidor configurado asi? porque si solo acepta correos desde la direccion IP del servidor no veo como funcionaría.

Si tienen que enviar correos por su cuenta, tienes que listarlas en el campo spf a todas. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFUgNvtTMYHG2NR9URAuidAJ9UpWIqNZ02JWyC5E17ZRdPwRqD4gCfehBq Kq2u759wYz4EdNovO3qnS1A= =ebMb -----END PGP SIGNATURE-----

Buenas, voy adar mi version, sin muchos tecnicismos, para empezar en el tema de las oficinas, tal como creo que ha dicho Carlos, se supone que estas enviarán a través del servidor entonces no hay problema, el que envía es el servidor. De no se así y hacerlo directamente el servidor deberá autorizarles, ya que con SPF se supone que el servidor receptor pregunta al emisor si tiene funcionando SPF, de no se así funciona normalmente, y de tenerlo le responderá si la máquina emisora está autorizada para enviar correos de dicho dominio. En resumen, con SPF tu dices que máquinas pueden mandar correos de tu dominio, y cuando te llega un correo preguntas al servidor del dominio remoto si la máquina que lo mándó estaba autorizada. Bueno, lo dejo que me lio. No se si habré acarado algo, mi opinión personal... sí vale la pena, y sería muchisimo más útil si estuviese más extendido. Saludos, Enrique El Miércoles, 8 de Noviembre de 2006 17:24, Victor Hugo dos Santos escribió:

2006/11/8, Emiliano Sutil :

...

...

engorro ?? pero hombre, basta agregar una linea al registro DNS, por ejemplo:

@ IN TXT "v=spf1 a"

con esto, ya configura vuestro SPF para que solamente acepten correos desde la direccion IP del servidor !!!

ahora, se me hablas de configurar el servidor de correo para comprobar el SPF, entonces te creo que puede ser un engedro !!! :-)

Pues no entiendo bien esto.

Si solo acepta correos desde la direcion IP como se puede usar ese servidor como smtp, Un supuesto, tengo 2 oficinas cada una con su IP y todos los equipos de ambas oficinas usan el servidor como correo saliente.

bueno.. en este caso, todo el correo que envie (de ambas oficinas) pasaran por el SMTP principal de la empresa y despues este lo entregara al SMTP de destino.. caso haya en el SMTP de destino el comprovador de SPF activado, entonces el mirara que el correo viene de vuestro SMTP original !!!!

ahora, caso cada una de las oficinas tenga su propio SMTP, entonces debes de configurar el SPF para informar que hay dos direcciones IPs que pueden enviar correos con vuestro dominio, por ejemplo:

"v=spf1 a a:200.200.200.200 a:100.100.100.100"

esto indica que se podra enviar correo desde la que apunta el dominio ($dig vuestro.dominio.com) y ademas las IPs 200.200.200.200 y 100.100.100.100

...

¿Podria estar el servidor configurado asi?

si

salu2

-- -- Victor Hugo dos Santos Linux Counter #224399

2006/11/8, Emiliano Sutil:

Pero sigo viendo que es un poco lio y veo un problema con los road-warriors, vamos el tipico que se conecta con un portatil con una conexión wifi. Ese usuario se conecta con una IP que vete tu a saber cual es y usa el servidor del dominio que esta en internet para enviar y recibir correo.

En ese caso como puedes restringir por IP?

No sé si lo he captado bien, pero creo que el spf se aplica al servidor de correo y a sus ips no a los clientes (al menos eso sería lo más lógico, creo yo) luego no importa la ip de quien conecta sino la ip del servidor de correo si es la misma que la que aparece listada como spf. Saludos, -- Camaleón

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-08 a las 19:00 +0100, Enrique escribió:

origen (autentico), y el destino, por ello mientras no se extienda más no será todo lo efectivo que puede llegar a ser.

Tiene problemas gordos; por ejemplo, tira por tierra los redirectores de correo. Yo tengo una dirección de correo en sourceforge. Pero esta dirección no tiene servidor de correo asociado: ni pop3 ni smtp. Lo que hacen es reenviarme todo el correo a otra cuenta real que yo les diga. Como consecuencia, tengo que enviarlo usando mi propio smtp o el de mi proveedor: jamás coincidirá mi IP con la autorizada, porque no existe. Y también presenta problemas con las listas de correo y las redirecciones y los forwards. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFUiu1tTMYHG2NR9URAiDpAJ4hIwrH02yfhpcfnhrNMpusAcwCQACeOlDZ 91x0iYhJoaNDsdgujTnbfn8= =MLis -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-08 a las 21:10 +0100, Camaleón escribió:

...

Como consecuencia, tengo que enviarlo usando mi propio smtp o el de mi proveedor: jamás coincidirá mi IP con la autorizada, porque no existe.

A ver, que me pierdo. Se supone que tú puedes enviar con la IP que quieras, quien tiene que tener la dirección IP listada en el SPF es el servidor de correo que utilices somo servidor smtp.

Si. Pero el receptor mirará mi return path que será en sourceforge.net, mientras que yo estoy enviando a través de telefonica.net, o sea, que no pueden coincidir jamás. O sea, no se puede aplicar SPF a las direcciones redirigidas. Más. Telefónica puede tener su campo spf definido correctamente, sí, y yo enviar a través de ellos. Pero al ser el campo de retorno de ussers.sourceforge.net (que no tiene servidor smtp para nosotros) lo que se busca es el campo SPF de users.sourceforge.net (que no tiene). telefonica.net. 23850 IN TXT "v=spf1 +a:spf.telefonica.net ?all" pass si está en "spf.telefonica.net" y neutro para el resto. sourceforge.net. 7200 IN TXT "v=spf1 mx a:mail.marblehorse.org a:sshgate.sourceforge.net a:mx-outbound.sourceforge.net a:lists-outbound.sourceforge.net a:sc8-sshgate.sourceforge.net a:smtp.vasoftware.com a:newcastle.devrandom.net -all" El SPF de users.sourceforge.net no existe (no se puede). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFUj51tTMYHG2NR9URAtPrAJsGY0qUFAxKdAqmZA7ekwfKL2X1ZwCeOD1H Cw2tFQk3eBzeF5mi54xkSyI= =Ompv -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-08 a las 22:12 +0100, Camaleón escribió:

El 8/11/06, Carlos E. R. escribió:

...

Si. Pero el receptor mirará mi return path que será en sourceforge.net, mientras que yo estoy enviando a través de telefonica.net, o sea, que no pueden coincidir jamás. O sea, no se puede aplicar SPF a las direcciones redirigidas.

Pero la dirección del "return-path" no es la resuelve el servidor de correo ni con la que se compara, quien se debe tener en cuenta es la del servidor de correo (telefonica.net) y la ip de ese servidor, el resto de datos no deben ser relevantes, de lo contrario no tiene sentido.

...

Más. Telefónica puede tener su campo spf definido correctamente, sí, y yo enviar a través de ellos. Pero al ser el campo de retorno de ussers.sourceforge.net (que no tiene servidor smtp para nosotros) lo que se busca es el campo SPF de users.sourceforge.net (que no tiene).

A ver, lo que se intenta es que el servidor de correo del destinatario de tu mensaje (que permite spf) que has enviado a través de telefonica.net (que tiene activado spf) verifique que telefonica.net efectivamente resuelve en su ip (o rango de ips) que es como efectivamente sale el mensaje.

En este caso no veo qué pinta aquí sourceforge.net, nadie le ha llamado ;-), no se verifica (o no debería), ya que no es el servidor de correo utilizado para conectar con el servidor de correo del destinatario.

Pero es que no funciona así. Verás, supón que yo estoy escribiendo un correo con mi dirección "from" de sourceforge. Como ellos no tienen servidor smtp, me obligan a usar el de mi isp, o sea, telefónica. Y, por ultimo, el cliente de correo va a poner como return path el de sourceforge. Vale, pues en esas circuntancias el servidor receptor va a pedir el registro SPF del dominio que figure en el return path - eso es así, no mira ni el from ni a telefónica, eso le importa un bledo. O sea, mira el SPF de users.sourceforge.net, que no existe (lo he mirado). En estas circunstancias si el correo se acepta o no dependerá del receptor: si ha dicho que no acepta correos sin spf válido, pues rechazará el mio porque ni siquiera tiene campo spf. Y si tuviera spf sería el suyo que no coincidiría con las IPs de tesa. Y esto pasa con todos los correos de redirectores (pe, @ieee,org). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFUmJItTMYHG2NR9URAh6/AJsHlV6zmfQNtKaApQnrND4g905DGwCgiJ6s ZZZWZIpyiLNSe9ChLQ442+E= =YFEe -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-09 a las 09:22 +0100, Camaleón escribió:

El 9/11/06, Carlos E. R. escribió:

...

Pero es que no funciona así.

Pues me parece un error. Validar la dirección del "return-path" no lo veo útil, para este caso. Y no lo veo útil porque el servidor smtp no tiene por qué saber nada de esa dirección, no es la importante. La autentificación del servidor smtp es mediante nombre de usuario y contraseña, para nada entra en juego lo que pongas en el return-path.

Si que es util, pero como he mostrado tiene sus problemas gordos. Si, por ejemplo, tu escribes desde gmail usando el servidor smtp de gmail, los receptores pueden comprobar que el correo que les llega de gmail lo hace desde un servidor de envío autorizado por gmail. Si en cambio, tu envías directamente desde tu propio postfix eres una falsificadora y una energúmerna y no tienes derecho a estar en el mundo mundial internetero y se te elimina, ¡¡ZAS!! - nada, no sos nadie, no hables. :-P

...

Vale, pues en esas circuntancias el servidor receptor va a pedir el registro SPF del dominio que figure en el return path - eso es así, no mira ni el from ni a telefónica, eso le importa un bledo. O sea, mira el SPF de users.sourceforge.net, que no existe (lo he mirado).

Que sí, que entiendo lo que dices, pero no debería ser así. Me gusta más cómo lo hace SA: sólo tienes que especificar qué servidores de correo (sus IPs) se encargan de qué dominios y listo. Si el correo viene de una dirección que no se corresponde con el rango de IPs especificado, lo detecta y no le aplica el whitelist. Ni return-path ni gaitas :-)

Lo de porqué se usa el return path y no el from... pues no lo se bien. Pero pensemos. Por ejemplo, los correos que nos llegan de la lista tienen el from puesto al remitente, pero el return path es una dirección única (de un solo uso) en suse; y es suse el servidor que hace el envío precisamente, luego es un caso en que tiene sentido en que se use el return path para el SPF. No es cuestión de gustos, tiene su porqué. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFUwCTtTMYHG2NR9URAos4AKCC40q89IhasmkZgSCPUkNG2kc0owCeLIW7 4wsNlKo1m6GQpWzolvgWC60= =kF0F -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-09 a las 11:39 +0100, Camaleón escribió:

...

Si en cambio, tu envías directamente desde tu propio postfix eres una falsificadora y una energúmerna y no tienes derecho a estar en el mundo mundial internetero y se te elimina, ¡¡ZAS!! - nada, no sos nadie, no hables.

Si yo envío desde mi Postfix soy yo quien se tiene que preocupar de tenerlo bien configurado (con un dominio real, con servidores dns, etc...). Si yo no me quiero preocupar de tener un servidor de correo bien configurado, pues lo mejor es que envíe a través de un servidor de correo que sí lo esté para evitar tener que preocuparme de ese servicio.

Por muy bien configurado que lo tengas, si envías con from de gmail con un "return path" puesto a gmail, como el destinatario compruebe el SPF, no llegas. Independientemente de lo bien que lo tengas configurado, de tus DNSs bien puestos, tu resolución ivnersa, tus políticas de seguridad y honorabilidad, etc, etc. Da igual, no eres gmail, estás mintiendo. Para eso sirve el SPF... Y el return-path tiene que estar a gmail, porque si lo pones a tu dominio, entonces los demás nos enteramos de quien eres realmente y pierdes el "anonimato" de usar una cuenta de gmail.

El SPF no es un requisito, puedes utilizarlo o no, es una medida más de seguridad, de asegurarse el origen de un mensaje.

No es un requisito por tu parte, la que envía, pero el destinatario puede darle la gana exigirlo. Lo mismo que otros exigen SORBS sabiendo lo malo que es.

Si quieres tener un coche tienes que matricularlo y pasar la ITV. Si no, vas en metro o en autobús para no causar daño a nadie :-).

...

Por ejemplo, los correos que nos llegan de la lista tienen el from puesto al remitente, pero el return path es una dirección única (de un solo uso) en suse; y es suse el servidor que hace el envío precisamente, luego es un caso en que tiene sentido en que se use el return path para el SPF.

En el correo que Henne ponía de dónde salen los mensajes:

4. Mails will originate from the new server. If you accepts listmails only from the listserver adopt your setup accordingly. The mails will originate from

DNS: lists4.suse.de IP: 195.135.221.135

Pero ellos se cuidan muy mucho de no usar SPF: cer@nimrodel:~/bin> host -v -t TXT lists4.suse.de | grep -i SPF cer@nimrodel:~/bin>

Y en la cabecera:

Received: from lists.suse.com (lists.suse.de [195.135.221.131])

Esa es la antigua.

by mx.google.com with SMTP id s7si634068uge.2006.11.09.02.19.20; Thu, 09 Nov 2006 02:19:20 -0800 (PST)

Con esa información es suficiente. Si el servidor de la lista tuviera activado spf no se podría falsear porque lists.suse.de efectivamente responde a 195.135.221.131, es decir, que si tú envías un correo intentado hacerte pasar por lists.suse.de el spf diría que no, que tu dirección IP de Telefónica no corresponde con la especificada en el spf.

No se miraría esa IP ni ese nombre. El return path es @suse.com en este momento, luego ese es el que se miraría si tiene SPF (y no lo tiene). El campo SPF diría quien está autorizado a enviar en nombre de suse.com La cuestión no es que se pueda falsear o no, no es eso. La cuestión es que SuSE diga en el DNS que todos sus correos van a venir de cierta IP, y que estamos autorizados a borrar todos los que vengan de una IP distinta. Simplemente eso. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFUxSEtTMYHG2NR9URAlmkAKCQUa6IrHlpDbQNPeWgIT5HU16HlACfek21 81oXEVfkuaTpNP352TxEn5Q= =65+p -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-09 a las 13:08 +0100, Camaleón escribió:

El 9/11/06, Carlos E. R. escribió:

...

Por muy bien configurado que lo tengas, si envías con from de gmail con un "return path" puesto a gmail, como el destinatario compruebe el SPF, no llegas. Independientemente de lo bien que lo tengas configurado, de tus DNSs bien puestos, tu resolución ivnersa, tus políticas de seguridad y honorabilidad, etc, etc. Da igual, no eres gmail, estás mintiendo. Para eso sirve el SPF...

Claro, por eso digo que el spf está mal implementado si mira el campo "return-path".

No, eso está bien hecho así. Si se usara el campo from todos los correos de la lista darían falsos. Es a propósito.

...

No es un requisito por tu parte, la que envía, pero el destinatario puede darle la gana exigirlo. Lo mismo que otros exigen SORBS sabiendo lo malo que es.

Pues eso, que no es de obligado cumplimiento en un servidor de correo. Incluso creo que SA tiene una regla para eso, no hace falta bloquear al usuario directamente, puedes aplicar el sistema de puntos: si no tiene activado spf: +0, si lo tiene activado y no pasa: +1,5, si lo tiene activado y pasa: -2.

Si que la tiene, pero no he conseguido ver si funciona. Acabo de mirar correos recibidos de gmail directos y no veo que el SA diga nada del SPF si o no.

...

Pero ellos se cuidan muy mucho de no usar SPF:

cer@nimrodel:~/bin> host -v -t TXT lists4.suse.de | grep -i SPF cer@nimrodel:~/bin>

Pues porque no querrán, pero no estaría de más, al menos les vendría bien para rechazar algo de spam.

No, a ellos no les beneficia, sería a nosotros. Ellos no pueden rechazar correo con eso. Fíjate que no usan siquiera listas negras, al menos no en el postfix. ¡Afortuandamente!

...

No se miraría esa IP ni ese nombre. El return path es @suse.com en este momento, luego ese es el que se miraría si tiene SPF (y no lo tiene). El campo SPF diría quien está autorizado a enviar en nombre de suse.com

Que sí, que el return-path es el problema, ya lo sabemos ;-) por eso digo que no es una buena implementación, que no sirve esa forma de llevar a cabo la verificación.

No, no es eso el problema. No se puede usar el campo "from". El return path indica cual es el servidor que se responsabiliza del correo, es la dirección del remite del sobre. El "from" está en el interior, no se puede mirar.

...

La cuestión no es que se pueda falsear o no, no es eso.

Esa es precisamente la cuestion. A mi sólo me interesa saber si un servidor de correo que se comunica con el mío dice ser quien realmente es, nada más. Si lo es y me envía un virus o spam, me pongo en contacto con el administrador. Si no es quien dice ser, pues ya veré lo que hago con lo que me manda (rechazarlo, dejarlo en cuarentena, eliminarlo...)

Eso sí que lo sabes con SPF. Si recibes un correo de un dominio determinado sabes de que IP tiene que venir, y si viene de otra, lo rechazas. En teoría. Y si no te gusta, pues también tienes el "DomainKey-Signature". http://en.wikipedia.org/wiki/DomainKey_signature que también tiene sus fallos.

...

La cuestión es que SuSE diga en el DNS que todos sus correos van a venir de cierta IP, y que estamos autorizados a borrar todos los que vengan de una IP distinta.

Lo borras sólo si quieres. Si yo recibo un correo de un equipo con una ip que no es de SuSE pues me hace sospechar algo malo. Para eso sirve, es un aviso.

Si el registro del SPF DNS que aplica viene con el signo menos (-) debes borrarlo: - for FAIL, the mail should be rejected (see below). Si no lo implementas, pues para eso ni te molestas en comprobar SPF. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFUyvntTMYHG2NR9URAmUMAJ4jgtNTQvPtjKYTuuI+O2UQzvhO9QCfWI3T 3GZfSVQV/TDUp5N6WYvwD7o= =wlct -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-09 a las 15:20 +0100, Camaleón escribió:

El 9/11/06, Carlos E. R. escribió:

...

No, eso está bien hecho así. Si se usara el campo from todos los correos de la lista darían falsos. Es a propósito.

El campo "From" tampoco es un dato válido. Lo que importa es la ip y el servidor, nada más. Si ambos datos coinciden, pasa la prueba del psf, lo cual te dice al menos "de dónde viene ese mensaje".

No se puede, piensalo bien. El correo te lo está entregando un servidor que dice ser "alfa" (en el ehlo me parece que es). Miras en el DNS y te dice que debe tener la IP x.x.x.x, y además tiene un SPF que dice que la IP autorizada para el dominio es la x.x.x.x, y el postfix comprueba que la conexión viene, efectivamente, de esa IP, o sea, todo correcto. Luego el correo pasa, es válido, según ese test. Pero resulta que el servidor "alfa" es un nido de spammers. En realidad, el correo dice venir del banco de españa en el campo from. Luego no has conseguido nada, el spam entra y a raudales, le has abierto la puerta de par en par.

...

Si que la tiene, pero no he conseguido ver si funciona. Acabo de mirar correos recibidos de gmail directos y no veo que el SA diga nada del SPF si o no.

Tienes que activar la regla, creo que viene desactivada.

La tengo activada en "/etc/mail/spamassassin/init.pre": loadplugin Mail::SpamAssassin::Plugin::SPF Mira, de un correo tuyo que recibí directo en septiembre pasado: Return-Path: <noelamac en gmail.com> X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on nimrodel.valinor X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 No dice nada de SPF sí o no.

...

No, a ellos no les beneficia, sería a nosotros. Ellos no pueden rechazar correo con eso.

Claro que pueden. Por ejemplo, las cuentas de Gmail. Hay muchos mensajes de spam en los que su From o su return-path son de "gmail.com" cuando realmente esos datos son falsos. Si Gmail tiene configurado spf y el servidor de la lista lo usa, pues todos esos correos quedan fuera.

Son dos cosas distintas. Una, que suse defina campos SPF en su DNS, que no lo ha hecho, lo cual nos impide a nosotros rechazar los falsos usando SPF. Otra es que SuSE emplee filtros basados en SPF en la entrada, y no lo hace, ni siquiera emplea listas negras en el postfix (sí en el spamassassin). Gmail en cambio sí lo tiene en su DNS, pero no tengo ni idea de si usa filtros de entrada y cuales.

...

No, no es eso el problema. No se puede usar el campo "from". El return path indica cual es el servidor que se responsabiliza del correo, es la dirección del remite del sobre. El "from" está en el interior, no se puede mirar.

Yo no he hablado del campo From, Carlos. Ese dato también suele ser falseado.

¿Y entonces cual usarías? Porque el identificador del servidor que llega creo que en EHLO tampoco vale, lo he demostrado arriba.

...

Eso sí que lo sabes con SPF. Si recibes un correo de un dominio determinado sabes de que IP tiene que venir, y si viene de otra, lo rechazas. En teoría.

Pues ya es un paso. Es decir, si un servidor de correo me dice que efectivamente ese mensaje viene de él, puedo relajar las reglas de filtrado para ese correo, por ejemplo. En cambio, un correo tuyo ;-), como viene directamente de una ip y sólo tengo ese dato, pues le aplico todos los filtros posibles, porque el 90% de los casos suele ser un correo de spam.

No te fies mucho, porque te lo puedo envíar a través del relay de tesa, y to'er mundo mudial sabe que telefonica y terra y sus alias son un nido de spammers que te cagas. Hasta hay reglas en el SpamAssassin que hablan de terra... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFU0wutTMYHG2NR9URAk9yAJ4wkGXdH3VcUoTkPbduxIXH9itQLACeNc1Q 1mnjECdDVWaQnZeKN1e/RUY= =E1un -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-09 a las 17:01 +0100, Camaleón escribió:

El 9/11/06, Carlos E. R. escribió:

...

El correo te lo está entregando un servidor que dice ser "alfa" (en el ehlo me parece que es). Miras en el DNS y te dice que debe tener la IP x.x.x.x, y además tiene un SPF que dice que la IP autorizada para el dominio es la x.x.x.x, y el postfix comprueba que la conexión viene, efectivamente, de esa IP, o sea, todo correcto. Luego el correo pasa, es válido, según ese test.

Pero resulta que el servidor "alfa" es un nido de spammers. En realidad, el correo dice venir del banco de españa en el campo from. Luego no has conseguido nada, el spam entra y a raudales, le has abierto la puerta de par en par.

Vale, pero cuando un correo se envía "realmente" a través de un proveedor tipo GMail, Yahoo, etc. si ese correo es spam / virus / phising... puedes contactar con alguien y puedes actuar, porque tienes datos reales de ese correo y de su servidor, de su origen. Eso no garantiza ni que te hagan caso ni que no te vuelvan a enviar más correos de ese tipo pero repito, sabes el origen de ese mensaje, y esa información puede ser útil llegado el caso.

Si vale. Pero lo que quiero decir es que el propósito principal del SPF que es autentificar la procedencia del correo no se puede hacer si el SPF se usara con otro campo del que usan. En ese ejemplo me viene un correo como del banco de España enviado por un servidor autentificado como "alfa" - que no es el del banco de España. Por eso decidieron usar el campo del return path, eso tiene que estar muy pensado por gente mu'sabia. Por contra presenta el problema de que, si se implementa estrictamente, no puedes enviar correo fuera de unos estrictos cauces, bloqueando correos perfectamente legítimos (caso de redirectores de correo, aka alias). En cuanto a poder identificar al verdadero remitente, eso se puede hacer. En España al menos es posible identificar siempre al remitente, siempre y cuando se obligue a los ISPs a identificarlo, para lo que te hace falta una orden judicial, supongo. La agencia de protección de datos lo hace. Fíjate que, aunque ellos falseen los campos "received", al menos uno, el de arriba, es cierto. Es decir, te puedes fiar de lo que pone el received que escribió tu proveedor cuando recibió el correo, y ahí figura la IP de donde vino. La IP en España es trazable; aunque sea dinámica, se identifica el número de teléfono y la persona del contrato telefónico.

...

La tengo activada en "/etc/mail/spamassassin/init.pre":

loadplugin Mail::SpamAssassin::Plugin::SPF

Parece que funciona como "suplemento vitamínico" a las listas blancas:

http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Plugin_SPF.h...

No es tan duro como pensaba...

Pero esta frase confunde: The headers checked for whitelist_from_spf addresses are the same headers used for SPF checks (Envelope-From, Return-Path, X-Envelope-From, etc). Parece indicar que hay más. Es que... es que la documentación del SA es una ca... castaña, una castaña, no digamos tacos :-/

...

Son dos cosas distintas. Una, que suse defina campos SPF en su DNS, que no lo ha hecho, lo cual nos impide a nosotros rechazar los falsos usando SPF.

Otra es que SuSE emplee filtros basados en SPF en la entrada, y no lo hace, ni siquiera emplea listas negras en el postfix (sí en el spamassassin).

El uso del spf no es tan radical como lo son las listas negras en el mismo Postfix (por ejemplo), en un campo más a verificar para validar un correo y verificar su origen, nada más.

Si, si puede ser tan radical: depende de la política definida por el propietario del dominio remitente, y de si el receptor ha definido un uso estricto. Por ejemplo, si han puesto "+mx -all" significa que, por lo que a ellos respecta, el correo de su dominio sólo se emitirá desde los servidores de correo del dominio, y el resto debes descartarlo sin contemplaciones como falso. Lo que pasa es que como nadie se fia, pues hacen un "~", por "softfail".

...

Gmail en cambio sí lo tiene en su DNS, pero no tengo ni idea de si usa filtros de entrada y cuales.

Le sirve para evitar que suplanten su dirección, vamos, para que el resto de servidores sepan cuándo un correo sale realmente de sus servidores y cuáles no. Los servidores de correo que realmente quieren evitar el spam utilizan este tipo de servicio. Como nota curiosa, no recibo correos de spam de cuentas (reales) de GMail, por ejemplo, pero sí de Telefónica.

¿Quieres decir que no recibes correo de spam realmente enviado desde gmail? Mmmm... Yo si, acabo de encontrar uno. Bueno, lo he buscado a propósito... bueno, espera, dice venir del servidor de gmail, pero no viene de ahí. Este lo hubiera podido bloquear el SA, pero no lo hizo por esa razón, lo hizo por otras cuantas. A ver... Bueno, tengo otro de una cuenta de gmail posteado en suse-es de googlegroups.com [GUSE]. Fué enviado realmente desde euskaltel, no entró por gmail. No se, tendría que mirarmelos todos (tengo unos 37), puede que tengas razón. Pero no es tan dificil que se cuele uno: das de alta una dirección, lanzas el bombardeo, y te vas. Es lo que han hecho muchas veces con terra, como es tan facil conseguir una cuenta...

...

¿Y entonces cual usarías? Porque el identificador del servidor que llega creo que en EHLO tampoco vale, lo he demostrado arriba.

La idea no es rechazar el correo directamente, Carlos, es tener más información sobre el origen del mensaje. Tomas el correo y lo analizas. Luego decides qué hacer con esa información.

Vale. Pero en ese caso el SPF es lo que es y está bien, con sus problemas, aunque no como medida decisoria, y a utilizar en conjunto con otra serie de medidas. Y sería mejor otro sistema que no tuviera esos problemas.

...

No te fies mucho, porque te lo puedo envíar a través del relay de tesa, y to'er mundo mudial sabe que telefonica y terra y sus alias son un nido de spammers que te cagas. Hasta hay reglas en el SpamAssassin que hablan de terra...

Claro, por eso decía que a tus correos les aplico todos los filtros disponibles... ;-)

Tú esperate ahora que sois Auna la que os puede caer encima :-P - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFU4BdtTMYHG2NR9URAvC+AJwLtNDtUe/EuM3XmwaV5PNwnelgBgCfUEFf LyNundDeuTs1hxutKvOeu+w= =+yii -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-09 a las 21:05 +0100, Camaleón escribió:

El 9/11/06, Carlos E. R. escribió:

...

Pero lo que quiero decir es que el propósito principal del SPF que es autentificar la procedencia del correo no se puede hacer si el SPF se usara con otro campo del que usan.

Parece que lo están solucionando:

http://new.openspf.org/FAQ/Forwarding

Para nada. Te dicen que simplemente no podrás hacer forward, y que te aguantes, que eso es lo que hay, que hagas reenvíos, poniendo tu propio "return-path" en vez del original, o sea, que responsabilices tú del correo. Su manera de solucionarlo es decirle al resto del mundo que cambien ellos, no en mejorar o inventar otra cosa que no sea el SPF.

Digamos que el spf me permite "denunciar" con datos a un isp que permite el spam desde sus servidores, por eso te decía que los que lo tienen implementado no pasan ni una (Gmail).

No del todo. A ver, el que un spammer use el smtp de gmail para enviar una hornada de spam es independiente de que gmail tenga SPF o no. Si están usando el smtp de gmail entonces se han autentificado frente a gmail, y las cabeceras contendrán un registro "DomainKey-Signature" que permite autentificarlo por completo. Encima, si el que recibe el correo (¡no gmail!) tiene implementado SPF entonces puede verificar que efectivamente se lo entrega gmail y que es aunténtico. Lo que impide que la gente envíe correos con from de gmail pasando por el smtp de gmail no es simplemente que estén autentificados, sino que gmail se lo toma en serio, tiene medios para identificar y trazar los correos, y a la primera denuncia se los quita de encima. Eso lo podría hacer telefónica si quisiera (es decir, contratando curritos como yo) sin necesidad de SPF, no afecta.

...

¿Quieres decir que no recibes correo de spam realmente enviado desde gmail? Mmmm...

No, verifica, verás como no tienes ninguno... o uno al cabo de un año :-). Un servidor que implementa spf da "confianza".

No es por el SPF. El SPF impide que yo pueda falsificar correos de gmail facilmente, pues los demás los pueden identificar y eliminar - lo cual plantea otros problemas (1). Pero no impide en absoluto que yo envie mil correos de spam usando el servidor de gmail. Me pillarían, si quieren, pero estarían enviados y recibidos con total confianza. (1) Uno de los problemas que plantea es que yo envíe correos con from de gmail a través del servidor de telefónica - lo cual es una práctica totalmente legal y correcta. Ha de hacerse poniendo el return path a telefónica. Por lo menos si todo el mundo forzara SPF.

Sí, cierto, pero ya te digo que son muy pocos.

...

Y sería mejor otro sistema que no tuviera esos problemas.

Que ya lo cambian, verás como dentro de poco ya tienes tu "forwader" funcionando con spf... :-D

Ni de coña. Exigen que cambiemos nosotros.

...

Tú esperate ahora que sois Auna la que os puede caer encima :-P

¿Somos? :-? Yo con Auna no tengo ninguna relación... son malos, malos, malos de verdad.

¿No tenías tu ONO? Son los mismos ahora. O me confundo con Cesar :-? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFU6xJtTMYHG2NR9URAmRnAKCQWb0Qsgo0PzyFAMr8PmtBlQZxJwCfesTO UorUf/PJnm0RSSe6I06s5jk= =Hk5u -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-10 a las 00:01 +0100, Camaleón escribió:

...

Te dicen que simplemente no podrás hacer forward, y que te aguantes, que eso es lo que hay, que hagas reenvíos, poniendo tu propio "return-path" en vez del original, o sea, que responsabilices tú del correo.

Hombre, al menos son conscientes y aportan soluciones:

But don't worry, we're working on providing SRS patches for the four major opensource MTAs, so that when you upgrade to an SPF-aware version, this problem will be solved also.

Pse... Tendría que leerme que es lo que dicen la gente del postfix al respecto. No quiero parches suministrados por terceros.

SPF "breaks" email forwarding. This is how to fix it. http://www.openspf.org/srs.html

...

Su manera de solucionarlo es decirle al resto del mundo que cambien ellos, no en mejorar o inventar otra cosa que no sea el SPF.

Que se podría mejorar, seguro, pero la idea no me parece mala. Me gusta hacer responsables a los proveedores de sus equipos y sus servidores.

No es el caso.

...

Lo que impide que la gente envíe correos con from de gmail pasando por el smtp de gmail no es simplemente que estén autentificados, sino que gmail se lo toma en serio, tiene medios para identificar y trazar los correos, y a la primera denuncia se los quita de encima. Eso lo podría hacer telefónica si quisiera (es decir, contratando curritos como yo) sin necesidad de SPF, no afecta.

No, pero ayuda. Verás como Telefónica no lo pone, no le conviene.

Tampoco SuSE lo ha puesto, y procesan miles de correos. Y Novell tampoco. Microsoft si, y eso debe ser malo, por definición :-P Es que no estoy seguro que sea conveniente. ¿Quien lo dice?

Es una herramienta más, que ayuda a determinar la procedencia de los correos. La utilidad que le veas a eso depende de cada uno. En mi caso, me ayudaría en un alto porcentaje a evitar el spam que recibo a diario (ojo, que no lo tengo puesto ni lo valido), pero me parece una buena idea.

No estoy seguro. No mientras no se solucionen todos los problemas que presenta. Yo no puedo enviar correos con mi alias de sourceforge cumpliendo con las reglas del SPF, es imposible.

...

No es por el SPF.

Bueno, eso no lo sabes :-). Lo que hace es que un servidor de correos pueda verificar que los correos de Gmail vienen de los servidores de Google. Para mi es un paso positivo, mejor eso que nada.

Es perfectamente legal y correcto enviar los correos de google desde cualquier otro servidor.

...

El SPF impide que yo pueda falsificar correos de gmail facilmente, pues los demás los pueden identificar y eliminar - lo cual plantea otros problemas (1).

Es que entre eso y nada, Carlos, me quedo con spf. Como usuario particular no le veo mucha utilidad, para la empresa, sí, porque los mensajes derivados de ese servidor tienen un "responsable" detrás (supongamos que Google en este caso). En cambio, de la otra forma, sólo tienes una IP que identifica al emisor, seguramente un equipo zombie que ha utilizado para enviar el correo, es decir, nada :-).

No, tiene poca utlidad porque no lo puedo implementar de lleno. Bloqueo correos válidos que no lo pueden usar.

...

Pero no impide en absoluto que yo envie mil correos de spam usando el servidor de gmail. Me pillarían, si quieren, pero estarían enviados y recibidos con total confianza.

Estamos de acuerdo.

...

(1) Uno de los problemas que plantea es que yo envíe correos con from de gmail a través del servidor de telefónica - lo cual es una práctica totalmente legal y correcta. Ha de hacerse poniendo el return path a telefónica. Por lo menos si todo el mundo forzara SPF.

Creo que se podría mejorar la forma de implentar el spf, pero el concepto es bueno.

No mientras no solucione todo, y no pueden. Tienen que inventar otra cosa mejor.

...

¿No tenías tu ONO? Son los mismos ahora.

O me confundo con Cesar :-?

Pues seguramente. Yo tengo Telefónica ¿quién si no? ;-)

Poz zi, porque los de ono no quisieron instalarme el teléfono. En cambio a tesa todavía le obliga la ley a ponerlo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFU8pPtTMYHG2NR9URAtZoAJ9OZ685ucc+a7Bug3D5SNG71d9DOwCfXAWZ 7djADLW5DLyUuN9VUThW8XM= =tUDo -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-10 a las 09:02 +0100, Camaleón escribió:

...

Tendría que leerme que es lo que dicen la gente del postfix al respecto. No quiero parches suministrados por terceros.

Vale, lo dejo "on hold" porque está un "poco verde". Pero le voy a seguir la pista, por si lo mejoran.

Eso si, desde luego.

...

Microsoft si, y eso debe ser malo, por definición :-P

Pensaba que usaban Sender ID:

http://en.wikipedia.org/wiki/Sender_ID

Bueno, que tengan definido el campo spf en el dns no quiere decir que lo estén usando en _su_ entrada. Sólo quiere decir que nosotros podemos usarlo en la nuestra para sus correos. Y gmail también usa domain keys, y otras historias. Lo han activado en salida, pero tengo mis dudas respecto a la entrada. Jolin, que yo mando a gmail con mi IP dinámica.

...

Es perfectamente legal y correcto enviar los correos de google desde cualquier otro servidor.

No he dicho lo contrario ;-)

El spf lo dificulta.

...

No, tiene poca utlidad porque no lo puedo implementar de lleno. Bloqueo correos válidos que no lo pueden usar.

Después de todo este hilo creo que le veo más utilidad a esto del spf en servidores corporativos más que a los proveedores como Gmail o Yahoo porque hay mayor control de las cuentas de correo electrónico, vamos, que raramente es el usuario el que da de alta su cuenta.

Exacto. Aunque supone problemas para los que se conectan desde fuera de la empresa con diversos proveedores. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFVGO+tTMYHG2NR9URArfpAJ9KgJX4PxBAEQrIY2oBrWEBghBKwgCeP3jk Wfxs2ROgzNl4Spo7K9u5StQ= =MZaY -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-09 a las 13:16 -0300, Victor Hugo dos Santos escribió:

pienso el mismo !!! yo tengo entendido que la idea es evitar la falsificacion de las indentidades.. y se me llega un correo de por ejemplo:

from: billgates@microsof.com return-path: victor@midominio.com

y lo envio desde mi servidor de correo, entonces vuestra explicacion el servidor de destino lo aceptaria !!!! y al usuario llegaria un correo de BillGates !!! :-)

Se trata de un mal empleo del campo return-path. Pero no te escapas. Llegaría un correo de midominio.com - que existe, por cierto (en Guayaquil), aunque no tiene registro SPF. Supongamos que lo tiene. El destinatario, suponiendo que verifique los campos SPF, le llega un correo autentificado como que viene de tu dominio, y del cual su administrador será responsable puesto que ha autorizado a tu IP a enviar en su nombre. Por tanto, en cuanto el usuario a quien le llega el correo falso de Guillermo Puertas se da cuenta le montan el pollo a tu admistrador y él a tí. Estás localizado y empapelado. Luego funciona. Ahora bien, de hecho el correo no llegaría, porque midominio.com no ha definido un servidor de correo válido, y el receptor debería rechazarlo por ese motivo.

mmmm. concuerdo con camaleon, sentido no hay en revisar el return-path !!!

Me remito a las explicaciones que mandé antes. El SPF no se puede hacer de otro modo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFU4UytTMYHG2NR9URAj9mAKCKBQLoxT3SPP7g9mTZvUuzUopRAACgloUI zU8+QncAip/dVWVyLsCjVXI= =I2Gp -----END PGP SIGNATURE-----

Lo dejaremos estar de momento (a no ser que alguien nos convenza de que esta bien...)

A mi me convecerán los "spammers". Llevo semanas recibiendo cada día centenares de mensajes de "mailers-daemon" devolviéndome correos teoricamente enviados por usuarios inexistentes. :-( -- Salutacions - Saludos, Josep M. Queralt