¿Cuál te gusta más: SPF o SenderID? (2 de 2)

*********************************************************************************************
- ¿Cuál te gusta más: SPF o SenderID? (1 de 2)
- ¿Cuál te gusta más: SPF o SenderID? (2 de 2)
*********************************************************************************************

En el caso de Hotmail, la diferencia es sutil con Gmail.com, pero importante. Como podéis ver el mensaje llega también de lacaixa.es pero con una bonita alerta que deja muy claro quién lo ha enviado.


Figura 5: Mensaje en Hotmail.com con identificación de Sender:
Esto quiere decir que el mensaje llega con un mail from desde lacaixa.es pero que ha sido enviado desde un Sender: de sharethis.com. Como podéis imaginaros, esto también puede ser utilizado por los spammers y phishers para engañar a los clientes de La Caixa que no estén muy familiarizados con estos conceptos. La pregunta es ¿podría hacer algo lacaixa.es para evitar esto?

Por supuesto, puede hacer uso de SenderID para fortificar un poco más su dominio. Esta tecnología utiliza un algoritmo para dejar claro quién ha enviado el mensaje que se llama Purpoted Responsible Address. Esto, lo que trata es de averiguar de forma nítica es quién es el Sender del mensaje. El algoritmo está descrito en el RFC 4407 y es éste:

1.- Seleccionar el primer valor no vacío de Resent-Sender: en el mensaje.
->Si no existe ese campo, continuar con el paso 2.
->Si está precedido por un campo no vacío de Resent-form y una o más ocurrencias de campos de Recived: o Return-Path: detrás de Resent-From: y después de Resent-Sender:, continúa con el paso 2.
-> En otro caso ir al paso 5.

2.- Seleccionar el primer valor no vacío de Resent-From: en el mensaje.
-> Si existe ir al paso 5.
-> En otro caso ir al paso 3.

3.- Seleccionar todos los valores no vacíos de Sender: en el mensaje.
-> Si no hay ninguno ir al paso 4.
-> Si hay 1 y nada más que 1 ir al paso 5.
-> En otro caso ir al paso 6.

4.- Seleccionar todos los valores no vacíos de From:.
-> Si hay exactamente 1 valor, continuar con el paso 5.
-> En otro caso ir con el paso 6.

5.- Un paso anterior ha seleccionado un único valor en la cabecera.
-> Si el mensaje está malformado - por ejemplo, contiene múltiples buzones, o el buzón está desesperanzadamente malformado, o el buzón no contiene ningún nombre de dominio, continuar con el paso 6.
-> En otro caso devolver ese valor único de buzón como PRA.

6. El mensaje está manipulado/enfermo y es imposible determinar un valor PRA.

Bien, una vez determinado correctamente el valor de PRA, y saber quién es el que envía el mensaje, se debe elegir una política. Las políticas que puede usar el administrador del dominio son:

- Spf2.0/mfrom -> Mirando si el "sender", que será Sender:, o en su ausencia, From:, está autorizado en el domino del "sender".
- Spf2.0/pra-> Mirando si el valor PRA está autorizado en el dominio del "sender".
- Spf2.0/pra,mfrom o spf2.0/mfrom,pra -> Mirando si el valor de From: y pra están autorizados.

Si miramos la cabecera de Hotmail, vemos que el valor de PRA en este ejemplo está marcado para sharethis.com y el servidor es un sender autorizado en ese dominio. Sin embargo, la política de lacaixa.es es spf1, es decir que solo evita que alguien se identifique como "sender" de lacaixa.es y. no sea de sus servidors. En este caso queda claro que no es un "sender" de lacaixa.es, así que esa política no hace nada, ya que ese "sender" no es de su dominio y está autorizado en sharethis.com.


Figura 6: Mensaje original en Hotmail con cálculo de valor PRA
Para bloquear este tipo de comportamientos, hay que utilizar el registro spf2.0/pra,mfrom o spf2.0/pra,mfrom y, por supuesto, el servidor de correo que reciba este mensaje tiene que implementar SenderID.

Por desgracia, a día de hoy, no todos los servidores implementan este filtro, y muchos siguen aún con el filtro de SPF. Sin embargo, si la implementación SPF trata de evitar el Spoofing debería comprobar los valores de Sender:, X-Sender: o Return-Path:.

Lógicamente, si un servidor de correo entrante implementa SPF y lee en tu dominio un registro spf2.0 lo va a ignorar. Es por ello que la solución pasa por establecer 2 registros SPF y que el servidor de correo entrante decida si aplica spf1 o spf2.0 ya que el estándar de SenderID [RFC4406] contempla esta situación. De esta forma, un pequeño porcentaje de destinatarios tendrá la política más estricta, si así lo desea el dueño del dominio.

La controversia radica en que, los partidarios de SenderID solicitan que cuando sus filtros se encuentren con spf1 les dejen aplicar la política como spf2.0/pra,mfrom, pero a día de hoy, la política que se sigue aplicando es spf2.0/mfrom.

Espero que hayan quedado claras las “sutiles” e importantes diferencias entre SPF y SenderID. Y ahora la pregunta: ¿Cuál te gusta más: SPF o SenderID?

Saludos Malignos!

*********************************************************************************************
- ¿Cuál te gusta más: SPF o SenderID? (1 de 2)
- ¿Cuál te gusta más: SPF o SenderID? (2 de 2)
*********************************************************************************************