¿Qué es el SPF? (Sender Policy Framework)?
Identifica, a través de los registros de nombres de dominio (DNS), a los servidores de correo SMTP autorizados para el transporte de los mensajes.
Este convenio puede significar el fin de abusos como el spam y otros males del correo electrónico.
Una técnica ya no tan nueva, pero increíblemente poco usada. Es el Sender Policy Framework.
El SPF como le llamaré, busca como objetivo el poder informarle al servidor que recibe un correo si ese correo viene de un destino legítimo o no.
Por ejemplo: Cuántas veces no te ha pasado que te llega un correo de [email protected] pero que en realidad no ha sido hotmail.com quien lo envió?
Esto ocurre mucho, los spammers falsifican el FROM de los correos, envían correos spam desde digamos: China o Guayuaquil, y se hacen pasar por hotmail.com para evitar declarar su verdadera dirección.
Así fue como se concibió el protocolo SMTP, cualquiera podría enviar un correo desde cualquier servidor de SMTP, sea donde fuere que éste servidor estuviere. El objetivo no es burdo, tosco o malintencionado. Es por el bien de la internet. Supongamos lo siguiente:
Antiguamente, los servidores de internet te podían desaparecer por varias horas, incluso días, puesto que no era considerado algo prioritario como ahora. Entonces cómo enviabas tus correos? Pues te conectabas a otro servidor smtp y enviabas el correo con el FROM del servidor que estaba caído. No importa, los correos de respuesta llegarían a su destino (tu) tan pronto ese servidor caído se levantara, pero por lo menos enviabas correos.
Es por eso que el smtp se creó así. Los spammers lo han visto como la oportunidad de su vida para ocultar o dificultar el descubrimiento de quién envió el correo... hasta hoy.
El SPF se está implementando cada día en más dominios y sugiero que lo hagas con tu dominio también.
Veamos el escenario actual:
Desde el punto de vista de un servidor que recibe un correo:
Supongamos que tenemos un servidor smtp sendmail, que está recibiendo un correo desde alguien que clama ser hotmail.com (FROM [email protected]). Supongamos que éste servidor nuestro tiene activado verificaciones SPF.
Lo primero que haría el servidor nuestro es ver si ese dominio (hotmail.com) tiene un record SPF, para eso verifica el record TXT del dominio:
[root@laptop ~]# host -t txt hotmail.com
hotmail.com text "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all"
Oh sí, lo tiene! Dentro de un rato veremos qué es lo que dice ese record. Pero lo tiene.
Si acaso no tuviera el record TXT con el spf (el SPF se define en el record TXT del dominio), entonces se considera un SPF neutro y no hay forma de validar si es o no un spammer.
Como sí lo tenemos, el servidor nuestro procede a verificar si la IP que envía el correo haciéndose pasar por hotmail.com está entre la lista de IPs autorizadas por éste record SPF de hotmail.
Si estuviera entre la lista de IPs autorizadas por el record TXT de hotmail.com, se le puede dejar pasar con confianza. Si no fuera una IP autorizada, se le podría marcar como spam o asignarle algún valor tendiente a considerarlo como spam.
Ahora veamos desde el punto de vista de nosotros, como clientes válidos, que estamos enviando correos a un servidor remoto
Supongamos que estamos enviando un correo a gmail.com desde nuestro dominio: [email protected] (lo escojo porque ya ellos tienen SPF activado).
Supongamos que gmail.com revisa (y en efecto lo hace) los records SPF de los dominios que les envían correos.
Nuestro legítimo servidor de satnet se conectará a gmail, le dirá que tiene un correo desde [email protected] y el servidor de gmail lo que hará será verificar los records TXT de uio.satnet.net que al día de hoy son estos:
[root@laptop ~]# host -t txt uio.satnet.net
uio.satnet.net text "v=spf1 ip4:200.63.212.96/29 -all"
Bien, como satnet tiene SPF declarado, gmail verificará si la IP que envía el correo es la autorizada por satnet. Si lo fuera, no será considerado spam. Si no lo fuera, será catalogado como tal.
Qué sucede si no tenemos records TXT declarados con SPF? Nadie podrá saber si alguien que use tu dominio para enviar un correo es legítimo o no. Podrías por lo tanto estar propenso a ser catalogado como spammer según otras técnicas que pueden equivocarse.
No te has fijado que hotmail.com cataloga mucho correo válido como junk (spam)? Eso es porque no sabe verdaderamente si es o no es, y porque sus filtros parecen no ser muy buenos.
Te comento, eso me pasaba mucho a mi, y desde que implementé SPF, ya mis correos llegan correctamente a hotmail. Porque hotmail sabe que yo soy yo y tiene más confianza.
Por qué usar SPF en tu dominio?
Porque no serás bloqueado por los sistemas de greylisting que soporten SPF. El greylisting acostumbra a dejar pasar a los servidores que tengan SPF declarado, sin demora alguna!
Porque los servidores que reciban tus correos sabrán a ciencia cierta que eres una persona que envía un mail legítimo y tendrás poquísimas opciones de ser catalogado como spammer.
Qué pasaría sí los spammers comienzan a usar spf?
Tendrán que enviar correos desde un FROM que es de ellos, desde un dominio que es de ellos, y no podrán ocultar o disimular el FROM, así que se delatarían mucho mucho más fácilmente y se podría actuar legítimamente contra ellos de una forma más cómoda. Ojalá lo comiencen a usar!
Quién ya implementa SPF?
en el país, conozco de satnet quito y guayaquil , puntonet, ecualinux.com (yo) y así día a día se irán sumando más personas puesto que en verdad ayuda, tanto para que recibas como para que envíes correos. Si conoces de alguien más que tenga SPF no dudes en listarlo.
El spammer comenzaría a retroceder, hemos notado que ya no nos llega mucho spam de satnet o de puntonet (con direcciones email de ellos) esto es porque nuestro sistema detecta que es un correo ilegítimo y lo bloquea.
Por favor cualquier pregunta o sugerencia no dudes en postearla, para así ir aclarando el tema, pero créeme, es bastante bueno este sistema.
Fuentes:http://es.wikipedia.org/wiki/SPF
http://www.ecualug.org/?q=2007/03/30/comos/11_qu_es_el_spf_sender_policy_framework
Interesante el artículo.
ResponderBorrarYo he querido implementar este script en mi servidor de correos Exchange 2003 porque me he encontrado con la barrera de que Hotmail rechaza los mensajes desde mi servidor, pero me he topado con un inconveniente: tengo IP dinámica.
Me gustaría saber si hay alguna alternativa para incorporar el script en el servidor DNS.
Seguramente te preguntarás el cómo tengo un servidor con IP dinámica, pues bien, el caso es que tengo servicios DNS de Internet que fijan mi IP y con un programa de automatización actualizan mi IP al momento de que ésta cambie.
Si puedes ayudarme o tienes alguna idea de cómo solucionar mi problema, te estaría agradecido.
Y si no es mucha la molestia, te pediría que me informaras que tienes una respuesta a mi correo acertijocl@hotma...
O trataré de darme una vuelta por acá en forma periódica.
Saludos y gracias