¿Quién no recibe hoy en dÃa correo no deseado? creo que hoy por hoy todos recibimos correo no deseado en nuestras cuentas de correo, unos en mayor medida que otros, pero creo que nadie se escapa. El SPAM es el mayor problema que tiene Internet hoy en dÃa, y luchar contra el parece que se está complicando, y no porque no existan herramientas que nos permitan luchar contra él, sino porque todavÃa la mayorÃa de los ISP no se han puesto manos a la obra.
Si nos remitimos al inicio del SPAM, tenemos que volver la vista atrás hasta 1994, cuando se publicó por primera vez en USENET un mensaje de publicidad que dÃas después se convertirÃa en una gran cantidad de ingresos. Desde ese entonces se ha intentado convertir el correo electrónico en una forma de marketing mediante el envÃo de forma indiscriminada de correos electrónicos a gente que no lo habÃa solicitado.
Con el tiempo esto se ha visto agravado, hasta lÃmites insospechados y se han tenido que buscar alternativas, puesto que hoy en dÃa el casi el 80% del tráfico de correo electrónico se debe al SPAM. Es aquà cuando las siglas SPF (Sender Policy Framework) entran en juego; SPF puede ser el futuro en la lucha cotra el SPAM.
Mandar e-mails es realmente sencillo, desde nuestro cliente de correo le damos a nuevo, incluios la dirección del destinatario y empezamos a teclear el texto que deseamos enviar, pero dentro de Internet antes de llegar a su destino este correo electrónico pasa por varios servidores y debe respetar un protocolo.
El protocolo encargado de gestionar el envÃo de correo es el SMTP (Simple Mail Transport Protocol), pero este no se encarga de verificar si la identidad del remitente es quien dice ser, o si ha estado enmascarada. Hacernos pasar por otra persona mediante correo electrónico es realmente sencillo.
Para entender bien a SPF la conversación con el servidor serÃa algo asÃ:
“hola servidor, soy xxxx y quiero enviar un correo electrónico desde el dominio midominio.com, desde el servidor miservidordecorreo.com, que tiene como IP xxx.xxx.xxx.xxx con destino a fulanito@sudominio.com.
Para configurarlo hace falta recurrir a los servidores DNS, que serán los encargados de identificar las máquinas autorizadas para el envÃo de correo para cada dominio. Es decir, cuando enviemos un correo de “midominio.com” el servidor de correo que recibe el e-mail consultará al servidor DNS si la ip desde la que está recibiendo el correo de “fulanito@midominio.com” es un servidor de correo autorizado para enviar correos de ese dominio.
El propietario del nombre dominio, debe añadir en la configuración de la zona DNS del dominio las direcciones IP de las máquinas utilizadas para enviar correo. Esto se consigue utilizando registros DNS de texto. Un ejemplo de registro SPF para DNS serÃa:
<code>
midominio.com. IN TXT "v=spf1 mx ptr ~all"
</code>
Donde los parámetros que se utilizan son los siguientes:
- v= define la versión usada de SPF (versión 1).
- mx autoriza a las máquinas con la IP de los registros MX.
- ptr autoriza a las máquinas bajo el dominio midominio.com.
- ~all desautoriza a las máquinas que no encajen en lo autorizado explÃcitamente.
Si tenemos alguna duda de cómo, modificar nuestro registro de DNS, podemos acudir al asistente de OpenSPF que nos ayudará a la configuración.
Existen otras alternativas para la lucha contra el SPAM creadas por grandes empresas pero propietarias, como pueda ser el “Sender ID” de Microsoft o el “DomainKeys” de Yahoo.
5 comentarios en “SPF: Sender Policy Framework”
Me has pisado un artÃculo que tenÃa previsto, pero te lo has currado
Esta bien, pero deberia legislarse al igual que la LPD.
Deberia estar prohibido recibir mails no deseados, es decir, la empresa anunciante seria responsable de los mails mandados.
Al igual que no se pueden pegar carteles.
SPF está bien, pero hasta que no se extienda su uso no será útil. Yo lo llevo poniendo en práctica desde 2004 porque lo vi en un log de aol.com y tampoco sirve de nada. De momento no puedes ser agresivo y denegar el correo sin registro SPF porque no te entrarÃa nada xD
Por otra parte, me jode tener que llenar el área TXT de mi DNS con cada vez más morralla, porque si usas DomainKeys (que no es propietario y puedes aplicarlo en UNIX mediante dkfilter) también metes ahà una clave cifrada. No creo que TXT fuera diseñado para albergar cada dÃa más basurilla.
Un saludo, hacÃa tiempo que no me pasaba y es obvio que ha sido a raÃz de tu comentario en mi blog, pero es que las últimas veces creo recordar que el dominio estaba caÃdo (o yo lo escribÃa mal).
Buen artÃculo. Hace tiempo que conozco SPF e incluso lo configuré en el dns, pero al igual que coder, hasta que no sea obligatorio, le veo poca utilidad. Por el momento, me ha resultado más útil validar servidores mx por rdns que usar SPF, me he quitado bastante spam de encima, y eso que más del 80% del correo que reciben nuestros servidores sigue siendo basura. Algún dÃa publicaré como tengo configurados los (que no mis) servidores
Saludos.
Ciscoso si te animas, escribe sobre rdns y lo publicamos por aquÃ. Yo estoy ansioso por ver la configuración que le has puesto a tus “servers” seguro que aprendo mucho de tus configuraciones.
Un saludo
alex