spfini.rtf

Introducción al SPF (Sender Policy Framework).
Fecha: 20/09/2004
Autores: Jesús Sanz de las Heras (RedIRIS) y Víctor Fernández Gómez (Universidad Pablo
Olavide)
Revisión: Grupo de Apoyo IRIS-MAIL
Presentación
El objetivo de este documento es ofrecer una visión general de SPF a la Comunidad RedIRIS.
Existe mucha información y documentación acerca de SPF por lo que no se profundizará en
exceso en el tema y se intentará exponer desde el punto de vista de las tipologías comunes
de los Servicios de correo de las instituciones RedIRIS.
Aunque a día de hoy SPF no es todavía un estandar en Internet, RedIRIS lo considera una
iniciativa que se consolidará en su estado actual o evolucionada (Sender-ID). Consideramos
que no se podrá solucionar el problema del spam si previamente no se definen soluciones para
autenticar el dominio emisor, y SPF es la solución mas simple y desarrollada que existe. La
inversión en tiempo necesaria para desplegar SPF en la Comunidad RedIRIS siempre será
positiva independientemente de su futura estandarización ya que es creciente su evolución
internacional. Además SPF, de forma colateral, nos ayudará a reforzar algunos aspectos de la
política del servicio como es el tema de la movilidad de nuestros usuarios.
Por tanto RedIRIS considera una necesidad la implantación de SPF en toda la Comunidad.
La implantación de SPF exclusivamente
dependerá de cada institución pero hemos
considerado que dado la homogeneidad en la tipología de Servicios de Correo Electrónico
podemos ayudarnos entre todos para una mayor eficacia ya que es necesario que cada uno
entendamos correctamente el protocolo, sus implicaciones y diseñemos las fases progresivas
de implantación en nuestra institución.

Las páginas oficiales de spf podréis encontrarlas en:

Para cooodinarnos en RedIRIS sobre los aspectos de SPF podéis utilizar la lista <[email protected]>
http://spf.pobox.com.
Introducción SPF
En pocas palabras, SPF es un mecanismo que proporciona un método para autenticar el
dominio de una dirección de correo. Permite a las estafetas receptoras de correo, comprobar
que la estafeta emisora que desea entregar un mensaje identificado como procedente de un
determinado dominio, está autorizada a hacer dicha entrega.
Supongamos, por ejemplo, que un equipo cualquiera intenta entregar un mensaje al servidor de
Rediris, un mensaje que dice proceder de la dirección <[email protected]> que es una
dirección existente de un dominio correctamente registrado y configurado. Es muy posible que
el servidor de Rediris acepte sin muchas más comprobaciones el mensaje.
Si otro equipo diferente intenta una entrega utilizando la misma dirección origen del mensaje:
<[email protected]>, seguramente el servidor de Rediris también lo acepte.
¿Y desde un nuevo equipo? También lo acepta.
¿Y otro más? Ídem.
Como vemos, lo que se echa de menos es una pequeña comprobación antes de aceptar el
mensaje. Una comprobación que nos confirme que el equipo emisor, es un equipo que los
responsables del dominio centro.es han designado para la entrega.
SPF permite esta comprobación.
Mucho software de spam y de inoculación de virus aprovecha esta característica, esta ausencia
de comprobaciones en la entrega, y usa direcciones falsificadas para entregar correo infectado
y no deseado.
Contra este tipo de software, y para evitar estos esos mensajes sirve SPF. Pero SPF no es un
sistema para erradicar el spam sino para solucionar el problema del uso ilegítimo de las
direcciones de correo y garantizar la legitimidad de nuestro dominio y la imagen de nuestra
institución en el tráfico SMTP saliente. Es un mecanismo que además nos permitirá garantizar
la legitimidad del tráfico de entrada eliminando el falsificado que actualmente es un alto
porcentaje.
SPF no comprueba el contenido del mensaje sino sólo la legitimidad del emisor. Se deja en
manos del
¿Cómo funciona, a grandes rasgos, SPF?
La idea de SPF es mimetizar el mecanismo que se utiliza para la entrega de correo y aplicarlo
también en la recepción.
Recordemos: durante el envío de mensajes, la estafeta emisora comprueba el dominio destino
del mensaje y utiliza el sistema de nombres dominios (DNS) para localizar los servidores que
están designados para la recepción (simplificando: registros MX y registros A). Es lo que se
llama enrutamiento de correo.
SPF es una imagen especular del mecanismo anterior: durante la recepción de mensajes, la
estafeta receptora, comprueba el dominio origen del mensaje y utiliza el sistema de nombres
de dominios (DNS) para localizar los servidores que están designados para el envío (en este
caso: registros TXT con un formato propio, formato spf).
Llegados a este punto, la estafeta receptora puede decidir rechazar el mensaje si el equipo que
ha establecido la conexión no está convenientemente autorizado en los registros spf para la
emisión de mensajes con determinado dominio.
Implementación de SPF.
Implementar SPF no es necesario para que nuestro Servicio de correo funcione. Es una
buena práctica, fácil de implantar y que garantizará al exterior la buena imagen de nuestro dominio.
Para desplegar SPF debemos actuar en dos frentes. Ambas acciones son independientes y no
importa el orden en el que sean implantadas.


Salida correo: publicación de registros SPF para cada dominio de la institución.
Entrada correo: instalación de mecanismos de gestión basados en SPF en las estafetas receptoras
de mensajes (SPF-enabled MTAs).
Aunque independientes, como hemos dicho, ambas operaciones son complementarias y de
poco sirve una sin la otra: que todos los dominios publiquen sus registros SPF no es útil si no
hay estafetas que utilicen estos registros para la gestión de recepción (y eventualmente el
rechazo de mensajes); análogamente, poco eficaces serán aquellas estafetas capaces de
interpretar registros SPF, si el número de dominios que publican estos registros no aumenta.
Los pasos recomendados para implementar SPF es:
1º Tráfico entrante: Publicar en DNS los registros SPF de los dominios bajo nuestra
responsabilidad.
2º Divulgarlo a nuestros usuarios
3º Tráfico entrante. Instalar y configurar los módulos SPF adecuados a su MTA para
analizar el correo entrante y tomar las correspondientes acciones.
Publicación de registros SPF.
Operativamente es la más sencilla de las dos acciones para avanzar hacia la implantación
completa de SPF, pero hay que estar muy seguros de lo que hacemos. Publicar consiste en
declarar, para cada uno de los dominios, las IPs que nuestra institución utiliza para enviar
correo, un registro SPF asociado a dicho dominio en el servicio de nombres responsable. Este
registro designa los servidores que están autorizados para enviar correo desde este dominio.
Básicamente al publicar estos registros en DNS estamos definiendo nuestra política de salida
del correo, y de alguna forma mejora la reputación de nuestro dominio de correo en Internet. Se
deben definir registros SPF para todos nuestros dominios y subdominios de correo no para
nuestros servidores.
Con la publicación en el DNS de los registros SPF estamos describiendo el comportamiento
del servicio de correo de una institución respecto al envío de mensajes y por tanto debería ser
incluido en el Documento de Correo Electrónico Institucional (DOCE) aclarando su significado.
La declaración de registros SPF en muchos casos será transparente a los usuarios locales
pero en otros no; en ambos caso es imprescindible informarlos.
Es importante destacar que, al publicar estos registros, la institución accede de forma explícita
a que sean rechazados (o tratados de forma diferenciada) todos aquellos mensajes que sean
emitidos desde servidores distintos a los descritos por los mismos, aceptando, de alguna
forma, la responsabilidad del rechazo, que no recae, como suele ser habitual, en la estafeta
rechazante. En cierta manera, la estafeta receptora rechazaría un mensaje por “motivos SPF”
porque la institución responsable del dominio así lo solicita en sus registros SPF
Para intentar explicarlo mejor, lo haremos con un ejemplo tipo de registro SPF en un servidor
DNS (tipo Bind) tendría el siguiente aspecto:
centro.es
IN TXT "v=spf1 a mx ptr -alll"
Donde,

centro.es es el nombre del dominio afectado (por tanto, este registro se aplica a los
mensajes con origen (MAIL FROM) del tipo <[email protected]>. Es importante
resaltar que este registro no se aplica a subdominios debajo del dominio afectado, es
decir no se aplica a mensajes del tipo <[email protected]> que debería
tener su propio registro SPF según politica institucional.

IN TXT, identifica la categoría de registro en el sistema de nombres de dominio (DNS). Se trata de un
registro de tipo "texto" de direcciones Internet.

"v=spf1 a mx -all" es la parte spf del registro DNS es la mas importante. Más
concretamente:
v=spf1 indica que se trata de un registro spf versión 1 (la única hasta el momento)
a y mx
identifican los servidores que podrán enviar mensajes del tipo
[email protected] , en este caso identificados como:
"a" está indicando que podrán hacerlo las IPs asociadas a los registros
de tipo A del dominio centro.es.
"mx" está indicando que podrán hacerlo las IPs asociados a los
registros MX del dominio centro.es
"ptr" está indicando que podrán hacerlo las IPs cuya resolución inversa
pertenezca al dominio .centro.es
-all indica el valor de la información declarada anteriormente con las opciones de este ejemplo:
"a", "mx","ptr". En este caso indica que el valor de lo declarado es alto y por tanto cualquier
chequeo spf deberá dejarlo pasar. El resultado definido en el protocolo SPF por parte del MTA
es "Pass". No es necesario hacer chequeos adicionales al mensaje.
Podríamos poner "~all" en el registros spf con lo que estaríamos declarando que las
IPs indicadas en los registros "a","mx" o "ptr" las estamos dando un valor menor y que
cualquier chequeo spf lo dejará pasar pero avisando que es conveniente hacer otro
tipo de chequeos pues no son de confianza. El resultado definido en el protocolo spf
por parte del MTA es "softail".
"~all" es considerada una opción transitoria y para eso fue definida dentro del protocolo
spf,. Es decir cuando queremos declarar nuestros registros SPF pero no estamos
seguros que algún usuario no vaya a utilizar nuestras IPs para enviar correo como
@centro.es.
Por tanto ¿qué estamos declarando cuando definimos unos registros SPF para el dominio
correo.es ?
centro.es
IN TXT "v=spf1 a mx ptr -alll"
Estamos garantizando
la reputación de la institución asociada al dominio centro.es
certificando que exclusivamente (-all) podrán enviar correo como @centro.es las IPs
correspondientes a:



Registro A del dominio centro.es.
Registros MX del dominio centro.es
Cualquier IP cuya resolución inversa tenga el dominio .centro.es
En definitiva un registro spf tiene dos partes:
1.Parámetros que nos permiten indicar las IPs que declaramos como emisoras de
correo de nuestra institución
2.Parámetro del valor que damos a lo declarado que está asociado a un resultado en el
algoritmo SPF y que por tanto intervendrá en las acciones que tomen los servidores
remotos al entrar el correo.
Acciones o chequeos SPF
Un servidor SMTP con SPF cuando recibe un mensaje de correo se hace la siguiente
pregunta ¿Esta autorizada la IP del cliente SMTP a enviar ese mensaje? Para responder a
esta cuestión se llevan a cabo las siguientes acciones:
1.Extrae el Sender del mensaje que dice estar enviándolo y la rdel cliente SMTP
2.Separa la parte del dominio del Sender, chequea sus registros SPF para comprobar
la IP
3.Al chequear los registros spf se devuelven varios resultados para la toma de decisión:
 Pass. El Sender es bueno y ha declarado que envía correo desde esa IP. EL mensaje
se dejaría pasar.
 Fail. El Sender es malo. El sender ha publicado una listas de Ips desde la que ellos
envían mensajes y la IP cliente no es una de ellas. El mensaje se rechzaría.
 SoftFail. El sender puede ser bueno o malo. El sender ha declarado registros spf
pero en un estado de migración. El mensaje se debería chequear de nuevo.
 Unknow. No se sabe. El Sender no ha declarado ningún registro SPF.
Ejemplos SPF
A continuación damos ejemplos básicos de dos configuraciones típicas en RedIRIS.
Ejemplo 1.



Datos:
Varias direcciones institucionales (@centro.es, @subd.centro.es)
Un sólo punto de encaminamiento de entrada/salida (smtp.centro.es)
Servicio a usuarios móviles institucionalizado
Como se ha comentado previamente es necesario declarar registros SPF para cada una de las
direcciones oficiales de la institución con o sin subdominios. Es necesario declarar las
máquinas que sacan al exterior el correo. Todos los usuarios de esta institución conocen y
disfrutan de los servicios de correo institucionales cuando salen fuera del dominio: en su caso,
congreso etc. Por tanto los registros en este caso serían:
centro.es
subd.centro
text = "v=spf1 mx -all"
text = “v=spf1 mx -all”
Los usuarios no podrán encaminar correo con ninguno de los Sender institucionales a través
de servidores diferentes que los declarados como registros MX. Cualquier servidor que reciba
correo con estos dominios procedente de las IPs de los registros MX deberá aceptarlos (-all
indicado en el registro dice al servidor PASS). El procedente de IPs diferentes que las
declaradas en los registros MX podrá ser rechazado (FAIL), pero recordemos que no lo
rechazan los servidores que chequean el correo sino que es rechazado porque lo indica la
política declarada por la propia institución a través de los registros spf.
Ejemplo 2.



Datos:
Direcciones únicas
Puntos diferentes de encaminamiento de entrada (registros MX) y salida
(relayout.centro.es)
No se ofrece servicio a usuarios móviles y/o no estamos seguros de como
acceden los usuarios al servicio desde el exterior.
Dado que la dirección es única basta con declara un solo registro spf. En este caso el tráfico
de entrada y salida esta desdoblado, es un buena idea pues a veces es necesario aplicar
diferentes políticas, pero en lo que afecta a SPF deberemos definir exclusivamente las
maquinas salientes no las entrantes (registros MX). Por otro lado no se ofrecen servicios de
movilidad a los usuarios o no estamos seguros, por lo tanto debemos declarar unos registros
transitorios (~ all) para evitar que cualquier usuario haga uso del correo desde otras IP y no le
funcione. Transitorio quiere decir temporal, es decir que cuando dispongamos de servicios
móviles estables y estemos seguros que todos nuestros usuarios los conozcan deberemos
modificarlos y definir unos registros garantizados (-all), pero mientras tanto:
centro.es
subd.centro
text = "v=spf1 a:relayout.centro.es ~all"
text = “v=spf1 a:relayout.centro.es ~all”
Con esta definición estamos declarando que el correo enviado como @centro.es y
@subd.centro.es debe de ser emitido por la IP asociada a “relayout.centro.es” pero no
exclusivamente (~all). Los servidores que recogen el correo y chequeen estos registros está
recibiendo el código SOFTFAIL, que les está indicando que se acepte pero con precauciones.
Casos especiales en la Comunidad RedIRIS
Caso 1. SAUCE de RedIRIS (Servicio de Acceso Universal al Correo Electrónico)
SAUCE es un servicio Webmail que permite a cualquier usuario de la Comunidad
RedIRIS a recibir correo de sus servidores institucionales y enviar a través de las máquinas de
RedIRIS. ES decir permite a cualquier usuario enviar correo con el Sender de su Institución a
través de IP que no le pertenecen como son las del Centro de comunicaciones RedIRIS. Este
correo es tratado como falso y sería rechazado por cualquier servidor que haga chequeos SPF,
a no ser que hayan declarado sus registros como ~all. La solución más correcta es definir unos
registros SAUCE siempre que queramos que nuestros usuarios utilicen este Servicio de
RedIRIS en lugar, o además de, del Servicio WebMail institucional . Para ello el registro
adecuado para el Ejemplo 2. anterior sería:
centro.es
subd.centro
text = "v=spf1 mx include:sauce.rediris.es -all"
text = “v=spf1 mx include:sauce.rediris.es -all”
RedIRIS definirá en su zona DNS un registro:
sauce.rediris.es
text = "v=spf1 a:130.206.1.3 -all"
De esta forma nuestra institución está indicando que sea aceptado todo el correo con
direcciones @centro.es y @subd.centro.es que procedan exclusivamente (-all) de las IP
asociadas a los registros MX y de la IP asociada a los registros SPF de “sauce.rediris.es” que
es la 130.206.1.3.
Caso 2. Servicio MailBackup de RedIRIS (pendiente de estudio)
Incorporación de mecanismos de chequeo SPF en las Estafetas
receptoras.
Esta actividad es algo más compleja. Hasta ahora hemos visto que el control de SPF en la
salida de correo depende de la declaración de registros spf en nuestra zona DNS sin necesidad
de llevar a cabo modificación alguna en los programas. Por el contrario el control SPF para el
tráfico entrante implica una serie de cambios en la configuración del software de la Estafeta.
Actualmente sendmail, postfix, exim y qmail disponen de soporte para tratar mensajes según
las directivas spf..
Activar el chequeo SPF en una estafeta puede requerir compilaciones adicionales, ajustes de
configuración y análisis iniciales, pero realmente no tiene implicaciones importantes, más allá de
la anotación de este dato en el Documento de Correo Electrónico (DOCE) o equivalente, es
decir informar a los futuros y actuales usuarios de nuestro Servicio de Correo.
Que la estafeta de nuestra institución trate un mensaje en recepción según se desprende de la
interpretación de los registros SPF es tratarlo según ha establecido el centro responsable
de la estafeta emisora y, por tanto, la responsabilidad recae en la institución titular del dominio
emisor, que es la que sugiere el comportamiento que deben darse a los mensajes que digan
proceder del dominio del que es responsable.
El correo procedente de dominios que no tienen declarados registros spf serán aceptados pero
analizados como sospechosos, debiéndose chequear con otros sistemas: listas negras, filtros
de contenidos etc.
La librería de referencia de implementación de SPF está escrita en Perl: Mail::SPF::Query.
Sendmail conecta con esta librería a través de su interface Milter. Las últimas versiones de
posftix lo hacen utilizando lo que llaman un “policy daemon”. Exim y Qmail incorporan SPF
mediante mecanismos ACL y un parche sobre el fuente original respectivamente.
En todos los casos es posible configurar el conector (plugin) SPF para que, en lugar de
rechazar el mensaje, únicamente se añada una línea de control (Received-SPF: fail) al mensaje
tratado. Es un comportamiento conservador que puede ayudar en las etapas iniciales de
prueba.
Problemas
Si bien SPF es una implementación muy sencilla conlleva algunos efectos colaterales. Como
dice su creador “No es posible hacer una tortilla sin romper el algún huevo” por tanto los
huevos son:

Redirecciones o forwarding
Gusanos, virus y spam falsifican la dirección del Sender con el objeto de esconder su origen
real. ¿A que se llama redirección o forwarding? Al encaminamiento que hace una Estafeta
(MTA-forwarder) hacia otra dirección externa (MTA-destinatario) de un mensaje procedente de
un servidor (MTA-emisor). Es el clásico caso de un usuario que configura su cuenta (.forward)
o indica al postmaster para que todo su correo sea encaminado a otra dirección con
/etc/mail/aliases etc. Es una acción muy común, cuando un profesor se desplaza durante un
periodo largo a otra universidad o cuando un compañero ha dejado de trabajar en nuestro
centro y desea que provisionalmente todo el correo le sea encaminado a otra dirección.
Ejemplo. Supongamos que la dirección del usuario [email protected] (MTA-forwarder) está
reencaminada a [email protected] (MTA-destino). Cuando el usuario [email protected]
(sender) envíe un mensaje a [email protected] (MTA-destino) el MTA-forwarder lo reencaminará
a la dirección destinataria [email protected] del MTA-destino. El Sender emisor del mensaje
no se modifica en todo el trayecto. En un escenario SPF esto ya no será posible ya que el MTAforwarder no podrá ser responsable de los registros SPF del emisor. Por tanto el MTA-destino
hará el correspondiente chequeo SPF y el mensaje podrá ser rechazado ya que la IP de la que
procede no se corresponde con lo declarado en los registros spf del Sender ([email protected]),
es decir lo vería como una falsificación.
[email protected]
SMTP
↓
[email protected]
SMTP
↓ 
[email protected]
dom.es text "v=spf1 a:1.1.1.1 -all"
Mail From: <[email protected]>
centro.es text “v=spf1 a:2.2.2.2 –all”
SMTP
Mail From: <[email protected]>
+
SPF
La IP origen (2.2.2.2) no corresponde a lo declarado en
los registros SPF del dominio (dom.es) de del sender
que dice ser la 1.1.1.1
En un escenario SMTP normal vemos que el campo Mail From: no cambia en ninguna de las
transacciones. En un escenario SPF se necesita que el MTA-forwarder reescriba la dirección
del Sender de tal forma que el mensaje de salida lleve un return-path que haga referencia al
servicio de forwarding e incluya el sender. Este proceso es lo que SPF ha denominado SRS
(Sender Rewriting Scheme) y hay una librería de desarrollo (módulo perl Mail::SRS) para llevar
a cabo esta reescritura, existiendo una amplia variedad de programas SRS que nos ayudaran
en solucionar este problema.
La solución SRS que adopte la institución dependerá de la política de redireccionamiento que
tenga la institución, si es soportado en casos puntuales, si es un servicio que se ofrece a todos
los usuarios, mecanismos utilizados etc
Dispone de mas información sober SRS en http://spf.pobox.com/srs.html

Uso de servidores ajenos
Otro problema que ya se ha comentado previamente es el que puede darse con usuarios de
nuestros centros que, utilizando una dirección origen correcta [email protected] , envíen
mensajes desde un servidor de un dominio ajeno, sin que el mensaje pase por nuestro servicio
de correo. Estos usuarios podrían verse afectados por la definición de registros SPF si alguna
estafeta a la que dirigen sus correos está preparada para tratar estos registros. Para evitar las
quejas de estos usuarios, tendremos que informarles o preparar una solución (SMTP-AUTH,
pop-before-smtp o similar) e invitarlos a que envíen sus mensajes utilizando el servicio de
correo del centro..
Resumen
La ventaja operativa fundamental de SPF es que colaborará en la reducción de correo y virus
no deseados y con ello aliviará la carga de las estafetas de correo, mejorando el uso de los
recursos (cpu, almacenamiento y red) y la calidad del Servicio de correo electrónico.
SPF comienza a modificar el paradigma que hasta ahora impera en el intercambio de correo
electrónico: “se asume la inocencia del emisor hasta que no se demuestre su culpabilidad” por
otro donde “se asume culpabilidad hasta que no se pruebe la inocencia del emisor”.
SPF no es la solución definitiva para eliminar el spam. Es sólo una del abanico de opciones
entre las que elegir para mantenerlo bajo un control razonable. Por si sola, ya sabemos que no
es suficiente. La combinación de varias soluciones de este tipo colabora a mantener el volumen
de spam en unos márgenes aceptables.
El grado de éxito de SPF dependerá del número de dominios registrados. Actualmente es
exponencial su crecimiento. El conjunto de dominios SPF registrados en Internet puede ser
interpretado como una gran lista blanca de dominios en los que podremos confiar. Nada
impedirá que un dominio con registro SPF distribuya correo no deseado basura o spam pero
dispondremos de mas datos para canalizar una denuncia.
RedIRIS fomentará en su Comunidad la implementación de SPF en diferentes etapas:
divulgación, declaración de registros spf y mecanismos de chequeo en los diferentes MTAs
mas habituales: sendmail, postfix y exim.