El protocolo SPF (Sender
Policy Framework) es la última iniciativa para combatir
el spam. Se trata de un protocolo que mediante dos
técnicas intenta averiguar si existe una suplantación de
identidad en los mensajes recibidos, con sólo examinar
sus cabeceras.
Este
protocolo de seguridad abierto compara la dirección de
correo electrónico de un mensaje con una lista de todos
los ordenadores autorizados para enviar mensajes a esa
dirección. Conociendo los resultados, el servidor de
correo con soporte SPF actúa de una forma u otra,
adoptando las medidas correspondientes.
El problema que radica con
este protocolo es que los administradores de sistemas
han oído hablar de él, en mayor o menor medida, pero
pocos saben implementarlo, ya no tanto en sus servidores
de correo, que es la simple activación de una casilla,
sino en la configuración en los servidores de nombres de
dominio, el DNS. Y todo ello es lo que vamos a
esclarecer en este artículo.
Quien más, quien menos, ha
sufrido una suplantación de identidad en el e-mail. Es
muy fácil enviar un mensaje con cabecera georgebush@whitehouse.gov
y el receptor no tiene forma alguna de verificar las
credenciales, salvo si examina las propiedades de la
cabecera u obliga a sus amigos a enviar sus mensajes
cifrados y firmados. Los últimos gusanos de Internet, se
apoderan de la Libreta de direcciones de un usuario
infectado y se reenvían, suplantando la identidad del
origen, de tal manera que los receptores del virus creen
estar recibiendo un mensaje de un conocido cuando se
trata de una clara suplantación de identidad.
Es así como ha nacido SPF, un
protocolo abierto como lo pueda ser SMTP y HTTP. Por su
parte Microsoft está intentando imponer su norma, el
protocolo Caller-ID, muy similar al SPF, salvo en que
usa para el almacenamiento de información en los DNS
código XML. El inconveniente es que Microsoft parece
haberse olvidado que los registros DNS tienen un límite
de 512 bytes en los datos almacenados. Y todos sabemos
que para escribir un simple "Hola mundo" en una página
web XML se requieren bastantes líneas de código,
demasiados caracteres que hacen de este tipo de páginas
algo muy pesado.
Al margen del peso de XML en
HTTP, Microsoft consciente de las limitaciones del DNS
en UDP, propone que las entradas DNS se hagan sobre TCP,
teniendo así un límite de 2.000 bytes para los datos.
Para complicar la balanza de
métodos a adoptar contra el spam, se han propuesto
alternativas como el hash-cash, el cobro por recursos de
microprocesador; las listas grises de Evan Harri,
relaciones de confianza cuyo método de actuación se
puede ver en
http://projects.puremagic.com/greylisting/whitepaper.html;
y DomainKeys, de Yahoo, basado en el uso de claves
asimétricas, lo que obligaría a los servidores de correo
a usar claves muy similares a PGP para validar mensajes.
Por el momento, parece que los
dos frentes más popularizados son SPF y Caller-ID. Pero
como decimos, Caller-ID cuenta con más desventajas,
aparte del propio uso de XML. Por ejemplo, Caller-ID
descarga un mensaje por completo antes de decidir si es
spam. SPF sólo lee la cabecera. Esto se traduce en que
con Caller-ID hay todavía más consumo de ancho de banda
y CPU, muy propio de todos los productos de Microsoft.
Además, el gigante de Redmond asegura que XML es más
adecuado para registrar la información de los DNS.
Teniendo en cuenta que las etiquetas XML ocupan más
espacio que la propia información, es absurdo pensar en
que los registros MX, A, PTR y CNAME deban codificarse a
partir de ahora en XML.
Por si fuera poco, Caller-ID
implica que se han de codificar las rutinas de búsquedas
DNS para la ejecución de múltiples búsquedas recursivas.
O sea, un nuevo gasto inaceptable en velocidad.
Personalmente creo que
Microsoft se empeña en implantar Caller-ID, simplemente
porque contiene XML, directamente relacionado con el uso
de varias patentes de la compañía. Y aunque por el
momento dice que no cobrará a nadie por utilizar Caller-ID,
la desconfianza de los fabricantes es grande. Así que
Microsoft sólo ha implementado Caller-ID en Exchange, y
ha impuesto una fórmula para compatibilizar Caller-ID
con SPF.
Registros SPF
El concepto de SPF se creó a
finales de los años noventa. SPF es una versión
simplificada de la propuesta RMX de Hadmut Danisch. RMX
se basa en el artículo de Paul Vixie, Repudiating Mail-From.
El artículo de Vixie fue el resultado de una sugerencia
de Jim Miller en 1998.
Para trabajar con SPF se
requieren dos cosas. Primera de ellas, que el servidor
de correo desde el que se envía disponga de un registro
TXT en el servidor DNS. Y dos, que tanto el servidor de
correo entrante como el saliente operen con SPF para
saber cómo actuar.
Veamos, un registro TXT en el
servidor DNS:
Y ésta es la explicación para
cada uno de los parámetros de la línea de texto
anterior:
|
v=spf1 |
Es el número de versión.
Hay una. |
|
a, mx, ptr y include
|
Son registros. Pueden
existir uno o más registros. |
|
+ y ~ |
Son prefijos. Los
prefijos preceden a los registros -si no se
especifican + se implica |
|
exp |
Es un modificador. Pueden
ser cero, uno o dos modificadores.
|
|
all |
Todas las IP, locales y
remotas. |
|
include |
Dominios externos
utilizados por los remitentes de e-mails locales,
habituales cuando viajan. |
|
a |
Todas las IP del registro
DNS A. |
|
mx |
Todos los registros A de
cada registro host MX. |
|
ptr |
Todos los registros A de
los registros host PTR. |
|
ip4 |
Uno o más dominios
especificados que utilizan Ip IPv4. |
|
exists |
Uno o más dominios
especificados que se identifican como excepciones de
las definiciones SPF. |
|
+ |
La dirección ha superado
el test. Ejemplo: +all |
|
- |
La dirección ha
suspendido el test. Ejemplo: -all
|
|
~ |
La dirección ha
suspendido el test pero el resultado no es
definitivo. Ejemplo: ~all |
|
? |
La dirección no ha
superado o ha suspendido el test. Ejemplo: ?all
|
Es fácil averiguar si un
servidor de correo usa o no registro SPF en su servidor
DNS. Para ello basta con abrir una ventana DOS y desde
el indicador de comandos teclear:
Veamos un ejemplo con un
fabricante de servidores de correo que ya implementa SPF:
Invito a que se haga la prueba
para comprobar los resultados. Se apreciará una línea
como la de más arriba, la entrecomillada con el registro
TXT de ejemplo. Ahora invito a hacer lo mismo con el
dominio de cada uno. El resultado es probable que no
incluya registro SPF y sí los resultados del SOA, con
tiempos de expiración antes del refresco de registros y
demás.
La segunda parte implica
activar SPF en el servidor de correo. Tomando como
ejemplo al fabricante Alt-N y su servidor de correo
MDaemon, la activación de SPF en uno de sus menús
involucra examinar los encabezados SPF de todos los
mensajes entrantes. Un encabezado típico sería:
Received-SPF: pass (ejemplo.mail:
domain of pepe@altn.com
designates 65.240.66.16 as permitted sender)
x-spf-client=MDaemon.PRO.v7.1.0.R
receiver=ejemplo.net
client-ip=65.240.66.16
envelope-from=<pepe@altn.com>
helo=smtp.altn.com
Este servidor de correo si
obtiene un error 500 bloquea el mensaje para siempre,
cerrando la conexión y colocando al remitente en lista
negra. Además, añade un filtro heurístico de correo
basura, por el cual según provenga de un servidor con
registro SPF en sus DNS o no, o de un servidor de correo
preparado para SPF, adoptará unos condicionales de
puntuación para SpamAssassin (http://www.spamassassin.org/index.html).
Configurando los registros SPF
¿Pero cómo se configura un
registro SPF en el servidor SPF? ¿Cómo debo hacerlo?
Pues es tan sencillo como usar
la tabla de más arriba para generar una entrada TXT.
Previamente, eso sí, hay que conocer las direcciones
listadas en los registros A, las direcciones listadas en
los registros MX, las direcciones listadas en los
registros PTR, direcciones IP públicas desde las que se
envíen correos SMTP, e inclusive las direcciones IP
usadas por la red del servidor de correo.
Un inciso. SPF está muy bien
cuando el servidor de correo es uno siempre, pero
representa un problema añadido para aquellos que usen un
servidor de correo como gateway de otro servidor de
correo, ya que para SPF un gateway es un suplantador de
identidad.
La forma más fácil de generar
esta entrada TXT es utilizar el asistente de este sitio:
Se coloca entonces el nombre
de nuestro dominio y se pulsa sobre Begin (comenzar). Se
introduce entonces la información necesaria sobre
registros A y MX. A medida que se van introduciendo
datos se va comprobando que en la parte inferior se
genera la entrada TXT. En todo momento se puede conocer
lo que estamos haciendo pulsando sobre el botón Explain
(explicar). Al finalizar, la cadena resultante es la que
habrá que introducir como registro IN TXT.
Un problema añadido para la
mayoría es que sus servidores DNS deberán soportar SPF o
estar preparados para introducir un registro TXT. Para
quienes utilicen su propio ISP se encontrarán con que la
entrada de su DNS apunta a un lugar como
Si el ISP no opera con este
tipo de registros todavía o representa un problema la
introducción de los mismos, podemos montar nuestro
propio servidor DNS o si no queremos malgastar una
máquina, contratar los servicios DNS. En este último
caso recomiendo Securityspace (http://www.securityspace.com/dns/index.html).
El registro DNS de un dominio cuesta 10 dólares,
disponiendo de 366 créditos equivalentes a 366 días para
introducir el primer dominio de forma gratuita durante
el primer año. Lo mejor es que sus servidores DNS se
encuentran esparcidos por toda América y Europa.
Una vez creado el dominio, con
sus correspondientes registros A, MX, PTR y otros,
aparte del correspondiente TXT para los valores SPF,
bastará con acceder a la cuenta para tu dominio (póngase
como ejemplo Nominalia, Network Solutions, Directnic, y
otros) y desde allí apuntar el DNS del dominio a:
Hay un total de 7 servidores
DNS en Securityspace, pudiéndose utilizar cualquiera de
ellos como respaldo (normalmente hasta tres).
Propagado el DNS en Internet,
al cabo de 24 horas ya se tiene el dominio configurado
para que los servidores de correo comprueben cabeceras
SPF provenientes de nuestro servidor de correo.
Es más sencillo de lo que
parece. Propongo que se comience cuanto antes para que
los administradores de sistemas pueden ir adaptando sus
sistemas para combatir el spam.
