-----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-----