**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************
Hace ya mucho tiempo que escribí un artículo sobre el famoso filtro Sender ID que implementó Spectra a partir de lo que inicialmente iba a ser el Checker ID pero que acabó haciendo uso del registro de Sender Policy Framework (SPF) con el objetivo de intentar añadir una nueva forma de detectar correos con direcciones de remitente falsificadas. No garantiza que el correo sea legitimo, pero intenta detectar cuando es claramente ilegítimo.
El registro original creado para Sender Policy Framework es identificado en los servidores DNS como v=spf1 y se creó para identificar el servidor usado en el comando HELO y el dominio que se utiliza en la dirección configurada en MAIL FROM.
Sender ID utilizar el registro SPF del DNS pero intenta identificar más elementos. Aparecerá en los registros DNS como v=spf2.0, pero con uno de los siguientes modos: spf2.0/mfrom,pra; spf2.0/mfrom o spf2.0/pra. Esto es porque Sender ID intenta validar no sólo el servidor que aparece en HELO y el dominio en MAIL FROM. En este caso se añade también a la comprobación una ecuación llamada PRA (Purported Responsible Address) que se saca de comprobar la dirección que aparece en: MAIL FROM, SENDER, RESENT-FROM, RESENT-SENDER. Si existe la validación spf2.0/pra en el filtro Sender ID, estas cuatro tienen que ser la misma y además deben estar en el registro SPF del servidor DNS. Un filtro v=spf1 será equivalente a un v=spf2.0/mfrom.
El filtro SPF y Sender ID son similares, ambos usan el mismo registro, la misma configuración, pero si se configura Sender ID con la validación spf2.0/pra algunos mails en listas de correo pueden dar problemas al ser tomados como no autenticados.
La idea es que las empresas marquen las IPs por las que sale el correo legítimo de su organización mediante un registro txt en el dns de tipo spf. Así, las empresas receptoras de correos desde esos dominios sólo tienen que consultar al DNS y ver si la IP que le entrega el correo de ese dominio es uno de las válidas siguiendo la política de Sender Policy Framework o la de Sender ID. ¿Y si no la cumple?
Pues si un correo del dominio A viene desde una IP que no está en la lista de direcciones IP legítimas para enviar correo marcadas por la empresa A….¿qué se debería hacer con él? Seguro que la mayoría pensáis que se debería tirar a la basura. La pregunta es… ¿se está usando masivamente?
Yahoo!, por su parte, optó por seguir una estrategia distinta mediante de la firma del correo legítimo y olvidarse de la solución simple del registro SPF en el DNS. En su caso, si el mensaje no va firmado por Yahoo! entonces debe tomarse como un correo ilegítimo. Para eso utiliza el protocolo DKIM (Domain Keys identified Mail) y cualquier servidor que recibe el correo puede comprobar la firma del mismo ya que la clave pública utilizada para firmar el correo se encuentra en el servidor DNS. La idea de Yahoo! es que si el correo no llega firmado por los servidores de Yahoo! entonces puede ser falso.
En el esquema de SPF/Sender ID cabe la posibilidad del falseo de direcciones IP o del DNS Spoofing (que se lo digan a Kamisky). El otro problema que sucede es que un mail puede ser enviado desde una IP falsa pero que aparezca como enviado por alguien legítimo, como si fuera una lista de mails. Para evitar esto los clientes de correo intentan dejar, cada vez más claro, cuando alguien envía el correo en lugar de otro.
En el esquema de autenticación por el que apuesta Yahoo! no cabe estos problemas, o el correo es enviado por un servidor de Yahoo! que lo firma o no. Sin embargo no se ha impuesto masivamente y la mayoría de los servidores no implementan la interpretación de la firma. Sin embargo, el problema del DNS le seguiría afectando.
Ahora, conociendo estas configuraciones, la pregunta es.. ¿cómo se comportará cada uno de ellos ante la recepción de correos con direcciones falseadas o no falseadas?Para hacer estas pruebas primero se comprueba si tienen configurado el registro SPF los dominios de prueba: Gmail.com, Yahoo.com y Hotmail.com. Se puede comprobar con esta URL: Consulta registro SPF
Hotmail.com configura registro SPF v=spf1
Gmail configura el registro SPF en v=spf1
Yahoo! no configura registro SPF
Los resultados son que Gmail y Hotmail configuran sus registros SPF pero Yahoo.com no lo hace, ya que usa DKIM. La pregunta es.... ¿cómo implementan el reconocimiento de correos legítimos o falseados en la práctica?
**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************
Hace ya mucho tiempo que escribí un artículo sobre el famoso filtro Sender ID que implementó Spectra a partir de lo que inicialmente iba a ser el Checker ID pero que acabó haciendo uso del registro de Sender Policy Framework (SPF) con el objetivo de intentar añadir una nueva forma de detectar correos con direcciones de remitente falsificadas. No garantiza que el correo sea legitimo, pero intenta detectar cuando es claramente ilegítimo.
El registro original creado para Sender Policy Framework es identificado en los servidores DNS como v=spf1 y se creó para identificar el servidor usado en el comando HELO y el dominio que se utiliza en la dirección configurada en MAIL FROM.
Sender ID utilizar el registro SPF del DNS pero intenta identificar más elementos. Aparecerá en los registros DNS como v=spf2.0, pero con uno de los siguientes modos: spf2.0/mfrom,pra; spf2.0/mfrom o spf2.0/pra. Esto es porque Sender ID intenta validar no sólo el servidor que aparece en HELO y el dominio en MAIL FROM. En este caso se añade también a la comprobación una ecuación llamada PRA (Purported Responsible Address) que se saca de comprobar la dirección que aparece en: MAIL FROM, SENDER, RESENT-FROM, RESENT-SENDER. Si existe la validación spf2.0/pra en el filtro Sender ID, estas cuatro tienen que ser la misma y además deben estar en el registro SPF del servidor DNS. Un filtro v=spf1 será equivalente a un v=spf2.0/mfrom.
El filtro SPF y Sender ID son similares, ambos usan el mismo registro, la misma configuración, pero si se configura Sender ID con la validación spf2.0/pra algunos mails en listas de correo pueden dar problemas al ser tomados como no autenticados.
La idea es que las empresas marquen las IPs por las que sale el correo legítimo de su organización mediante un registro txt en el dns de tipo spf. Así, las empresas receptoras de correos desde esos dominios sólo tienen que consultar al DNS y ver si la IP que le entrega el correo de ese dominio es uno de las válidas siguiendo la política de Sender Policy Framework o la de Sender ID. ¿Y si no la cumple?
Pues si un correo del dominio A viene desde una IP que no está en la lista de direcciones IP legítimas para enviar correo marcadas por la empresa A….¿qué se debería hacer con él? Seguro que la mayoría pensáis que se debería tirar a la basura. La pregunta es… ¿se está usando masivamente?
Yahoo!, por su parte, optó por seguir una estrategia distinta mediante de la firma del correo legítimo y olvidarse de la solución simple del registro SPF en el DNS. En su caso, si el mensaje no va firmado por Yahoo! entonces debe tomarse como un correo ilegítimo. Para eso utiliza el protocolo DKIM (Domain Keys identified Mail) y cualquier servidor que recibe el correo puede comprobar la firma del mismo ya que la clave pública utilizada para firmar el correo se encuentra en el servidor DNS. La idea de Yahoo! es que si el correo no llega firmado por los servidores de Yahoo! entonces puede ser falso.
En el esquema de SPF/Sender ID cabe la posibilidad del falseo de direcciones IP o del DNS Spoofing (que se lo digan a Kamisky). El otro problema que sucede es que un mail puede ser enviado desde una IP falsa pero que aparezca como enviado por alguien legítimo, como si fuera una lista de mails. Para evitar esto los clientes de correo intentan dejar, cada vez más claro, cuando alguien envía el correo en lugar de otro.
En el esquema de autenticación por el que apuesta Yahoo! no cabe estos problemas, o el correo es enviado por un servidor de Yahoo! que lo firma o no. Sin embargo no se ha impuesto masivamente y la mayoría de los servidores no implementan la interpretación de la firma. Sin embargo, el problema del DNS le seguiría afectando.
Ahora, conociendo estas configuraciones, la pregunta es.. ¿cómo se comportará cada uno de ellos ante la recepción de correos con direcciones falseadas o no falseadas?Para hacer estas pruebas primero se comprueba si tienen configurado el registro SPF los dominios de prueba: Gmail.com, Yahoo.com y Hotmail.com. Se puede comprobar con esta URL: Consulta registro SPF
Hotmail.com configura registro SPF v=spf1
Gmail configura el registro SPF en v=spf1
Yahoo! no configura registro SPF
Los resultados son que Gmail y Hotmail configuran sus registros SPF pero Yahoo.com no lo hace, ya que usa DKIM. La pregunta es.... ¿cómo implementan el reconocimiento de correos legítimos o falseados en la práctica?
**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************
Macho tu no duermes o ke DX. Aqui en Canarias ya son las 2:30 de la mañana.
ResponderEliminarP.S.: Aver si te pasas por el Desktop Summit.
P.S. 2: Interesante articulo.
Anima fuerte a los pandas.
Lástima que tanto hotmail.com como gmail.com tengan un ~all en vez de un -all.
ResponderEliminarvamos a ver cómo lo digo...
ResponderEliminareste tema, me ha puesto palote...
Está en mis peleas diarias
@Ruso, tiene truco, yo estoy en GMT-7 ahora mismo ;)
ResponderEliminar@nico, poner un softfail en lugar de un fail es cuestión de política de spam. Supongo que en este asunto, cuanto más restrictivo eres con el correo, debe ser peor. De todas formas... todo es una gran chapuza.
@Christian Hernandez, espero que no te defraude ;)
Saludos!