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".
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.
En el "return-path" puedes poner lo que quieras. Creo que hace poco te lo comentaba en un mensaje que para poder enviar correos desde Gmail con cuenta de Gmail y para que respondieran a tu cuenta de Telefónica tenías que poner en el return-path la cuenta de telefonica.net. Sigues saliendo por Gmail.
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.
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 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.
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...)
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. Saludos, -- Camaleón