Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
¿Cuál te gusta más: SPF o SenderID? (1 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)
*********************************************************************************************
Muchas veces, por falta de tiempo, no me meto en todos los detalles del funcionamiento de SenderID y Sender Policy Framework, es decir, en las pequeñas diferencias que existen entre ellos, pero a raíz de una petición de explicación sobre un caso concreto, he creído que era conveniente pararse un poco sobre ello. El asunto comienza con un mail enviado a Hotmail en el que, aparentemente, el mail llega desde un dominio con una política –all en el registro SPF.
Figura 1: Correo con dirección falsa en la bandeja de entrada de Hotmail.
Para replicar este caso, como habéis visto en la figura 1, he seleccionado el dominio de lacaixa.es que tienen esa política en su registro SPF de tipo Hardfail y el servicio de Enviar a un amgio de una web que re-escribe los campos necesarios para explicar como funcionan los registros.
Figura 2: Registro SPF de lacaixa.es
Sin embargo, enviamos un correo falso a Gmail y a Hotmail y obtenemos que entra en ambos, pero con algunas diferencias, que nos servirán para explicar los sutiles detalles de estas implementaciones. Si observamos, el correo, además de entrar perfectamente en la bandeja de entrada de Hotmail, entra también en la bandeja de Gmail. Como se puede ver, si vemos los detalles del mensaje se están mostrando los campos From: y Reply to: que, como se puede ver, ambos tienen la información es la misma, una dirección de correo de lacaixa.es.
Figura 3: Correo visto en Gmail con detalles mostrados
Sin embargo, si miramos el correo original, vamos a entender porque Gmail lo hace tan rematadamente mal - ¡Alerta: opinión personal! -.
Figura 4: Original del correo mostrado en Gmail.com
Como se puede ver, el cálculo del valor SPF dice que la política es hardfail, y por lo tanto, siguiendo la política del registro SPF de lacaixa.es debería eliminarlo. ¿Esto es así? Vamos a pensar un poco sobre ello.
Si echamos un vistazo al RFC2822 donde se definen los campos de un mensaje, podremos ver que en el apartado 3.6. se definen varios posibles campos para el originario de un mensaje.
Figura 5: Campos de posibles originarios de un mensaje
Para ello, hay que entender una sutil diferencia entre quién se supone que escribe el mensaje y quién se supone que lo envía. Para entender el orden de prioridad de los campos vamos a analizar la diferencia entre From: y Sender:. Tal y como dice el estándar, se supone que mail from es el originario de la carta, el contenido, del mensaje en sí, mientras que sender, es el originario de enviar ese mensaje. Es decir, ¿quién se supone que creo el mensaje? From:. ¿Quién se supone que lo envío? Sender:. Así, este orden de precedencia, a la hora de averigüar quién envía un mensaje, hay que entenderlo para Resent-sender:, Resent-From:, From: y Sender:. Por supuesto, a esto hay que añadir las implicaciones de los campos "X" com X-Sender:, X-Resent-Sender:, etc… ya que los campos "X", implican extensiones al estándar que algunos servidores de correo electrónico implementan de manera distinta. Por spuesto, si no hay ningún valor más, el valor que vale es el de From:.
Bien, dicho esto… ¿debería Gmail bloquear ese mensaje? Mi respuesta es que no, pero que lo hace aún peor que peor - ¡Alerta: Opinión personal!. Vamos por partes.
Si analizamos ese mensaje de correo, podemos ver que tiene tres campos muy significativos con valores, que son Sender:, X-Sender: y Return-Path:. El campo Sender: - y su versión extendida X-Sender: - marcan la dirección del que envió este correo a nuestro servidor, mientras que Return-Path: es un campo de traceo y monitorización que utilizan los servidores de correo para dejar claro que ese mensaje se originó en ellos. Así, Return-Path: lo añade el servidor que genera el primer mensaje de correo, dejando claro dónde se originó.
Conociendo esto, si Gmail aplica la política hardfail con el campo From:, estará impidiendo que ningún Sender:, envíe un correo en su nombre… y entonces se le acabaron las listas de correo a esta dirección de correo. Si jesus@lacaixa.es intentara suscribirse a alguna lista de correo en la que hubiera un reenviador de los correos, sus mensajes nunca llegarían a las direcciones destino de Gmail.
Dicho esto, el siguiente paso es buscar información sobre este caso, pues la cosa se torna muy turbia aquí. Si miramos la Wikipedia [Sender Policy Framework], en la información sobre el filtro SPF dice claramente:
“the owner of the example.com domain can designate which machines are authorized to send e-mail with the sender e-mail address ending in "@example.com"”
Así que hay que mirar quién es el sender y, tal y como dice la Wikipedia y en todas las explicaciones, esto debe ser mirado en los campos From: y Sender:. Lo suyo sería mirarlo en el campo Return-Path:, pero muchas implementaciones decidieron hacerlo con Sender: y From:, porque son los primeros valores que hay que entregar del mensaje y se puede bloquear el correo al principio. Ahora bien, si aparecen los dos… ¿cuál es el que debería utilizarse?
Según el RFC4408 del estándar SPF debería ser solo la dirección en From:, pero si quieres que te funcione el filtro SPF sin cepillarte las listas de correo, lo que deberías hacer es aplicar el valor Sender:, como hacen muchos servidores de correo y From: solo cuando no aparezca Sender:.
Por el contrario, si aplicamos el valor de Sender:, esto implicaría que hay que comprobar el registro SPF del dominio que aparezca en el Sender:, por lo que si el DominioB está enviando un correo en nombre de un usuario del DominioA, entonces se aplicaría la política SPF del DominioB y si ese usuario de Sender: lo hace desde un servidor autorizado por el SFP del DominioB, entonces podría enviar un correo del DominoA.
Como puedes observar Gmail:
PRIMERO: Gmail aplica From: y no Sender:.
SEGUNDO: No elimina el correo aún cuando lee la política del dominio que él ha decidio.
TERCERO: No muestra ninguna alerta al usuario.
Divertido, ¿verdad? Tranquilo, que aún aún hay mucho más, espera a ver la segunda parte para tomar partido.
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)
*********************************************************************************************
- ¿Cuál te gusta más: SPF o SenderID? (1 de 2)
- ¿Cuál te gusta más: SPF o SenderID? (2 de 2)
*********************************************************************************************
Muchas veces, por falta de tiempo, no me meto en todos los detalles del funcionamiento de SenderID y Sender Policy Framework, es decir, en las pequeñas diferencias que existen entre ellos, pero a raíz de una petición de explicación sobre un caso concreto, he creído que era conveniente pararse un poco sobre ello. El asunto comienza con un mail enviado a Hotmail en el que, aparentemente, el mail llega desde un dominio con una política –all en el registro SPF.
Figura 1: Correo con dirección falsa en la bandeja de entrada de Hotmail.
Para replicar este caso, como habéis visto en la figura 1, he seleccionado el dominio de lacaixa.es que tienen esa política en su registro SPF de tipo Hardfail y el servicio de Enviar a un amgio de una web que re-escribe los campos necesarios para explicar como funcionan los registros.
Figura 2: Registro SPF de lacaixa.es
Sin embargo, enviamos un correo falso a Gmail y a Hotmail y obtenemos que entra en ambos, pero con algunas diferencias, que nos servirán para explicar los sutiles detalles de estas implementaciones. Si observamos, el correo, además de entrar perfectamente en la bandeja de entrada de Hotmail, entra también en la bandeja de Gmail. Como se puede ver, si vemos los detalles del mensaje se están mostrando los campos From: y Reply to: que, como se puede ver, ambos tienen la información es la misma, una dirección de correo de lacaixa.es.
Figura 3: Correo visto en Gmail con detalles mostrados
Sin embargo, si miramos el correo original, vamos a entender porque Gmail lo hace tan rematadamente mal - ¡Alerta: opinión personal! -.
Figura 4: Original del correo mostrado en Gmail.com
Como se puede ver, el cálculo del valor SPF dice que la política es hardfail, y por lo tanto, siguiendo la política del registro SPF de lacaixa.es debería eliminarlo. ¿Esto es así? Vamos a pensar un poco sobre ello.
Si echamos un vistazo al RFC2822 donde se definen los campos de un mensaje, podremos ver que en el apartado 3.6. se definen varios posibles campos para el originario de un mensaje.
Figura 5: Campos de posibles originarios de un mensaje
Para ello, hay que entender una sutil diferencia entre quién se supone que escribe el mensaje y quién se supone que lo envía. Para entender el orden de prioridad de los campos vamos a analizar la diferencia entre From: y Sender:. Tal y como dice el estándar, se supone que mail from es el originario de la carta, el contenido, del mensaje en sí, mientras que sender, es el originario de enviar ese mensaje. Es decir, ¿quién se supone que creo el mensaje? From:. ¿Quién se supone que lo envío? Sender:. Así, este orden de precedencia, a la hora de averigüar quién envía un mensaje, hay que entenderlo para Resent-sender:, Resent-From:, From: y Sender:. Por supuesto, a esto hay que añadir las implicaciones de los campos "X" com X-Sender:, X-Resent-Sender:, etc… ya que los campos "X", implican extensiones al estándar que algunos servidores de correo electrónico implementan de manera distinta. Por spuesto, si no hay ningún valor más, el valor que vale es el de From:.
Bien, dicho esto… ¿debería Gmail bloquear ese mensaje? Mi respuesta es que no, pero que lo hace aún peor que peor - ¡Alerta: Opinión personal!. Vamos por partes.
Si analizamos ese mensaje de correo, podemos ver que tiene tres campos muy significativos con valores, que son Sender:, X-Sender: y Return-Path:. El campo Sender: - y su versión extendida X-Sender: - marcan la dirección del que envió este correo a nuestro servidor, mientras que Return-Path: es un campo de traceo y monitorización que utilizan los servidores de correo para dejar claro que ese mensaje se originó en ellos. Así, Return-Path: lo añade el servidor que genera el primer mensaje de correo, dejando claro dónde se originó.
Conociendo esto, si Gmail aplica la política hardfail con el campo From:, estará impidiendo que ningún Sender:, envíe un correo en su nombre… y entonces se le acabaron las listas de correo a esta dirección de correo. Si jesus@lacaixa.es intentara suscribirse a alguna lista de correo en la que hubiera un reenviador de los correos, sus mensajes nunca llegarían a las direcciones destino de Gmail.
Dicho esto, el siguiente paso es buscar información sobre este caso, pues la cosa se torna muy turbia aquí. Si miramos la Wikipedia [Sender Policy Framework], en la información sobre el filtro SPF dice claramente:
“the owner of the example.com domain can designate which machines are authorized to send e-mail with the sender e-mail address ending in "@example.com"”
Así que hay que mirar quién es el sender y, tal y como dice la Wikipedia y en todas las explicaciones, esto debe ser mirado en los campos From: y Sender:. Lo suyo sería mirarlo en el campo Return-Path:, pero muchas implementaciones decidieron hacerlo con Sender: y From:, porque son los primeros valores que hay que entregar del mensaje y se puede bloquear el correo al principio. Ahora bien, si aparecen los dos… ¿cuál es el que debería utilizarse?
Según el RFC4408 del estándar SPF debería ser solo la dirección en From:, pero si quieres que te funcione el filtro SPF sin cepillarte las listas de correo, lo que deberías hacer es aplicar el valor Sender:, como hacen muchos servidores de correo y From: solo cuando no aparezca Sender:.
Por el contrario, si aplicamos el valor de Sender:, esto implicaría que hay que comprobar el registro SPF del dominio que aparezca en el Sender:, por lo que si el DominioB está enviando un correo en nombre de un usuario del DominioA, entonces se aplicaría la política SPF del DominioB y si ese usuario de Sender: lo hace desde un servidor autorizado por el SFP del DominioB, entonces podría enviar un correo del DominoA.
Como puedes observar Gmail:
PRIMERO: Gmail aplica From: y no Sender:.
SEGUNDO: No elimina el correo aún cuando lee la política del dominio que él ha decidio.
TERCERO: No muestra ninguna alerta al usuario.
Divertido, ¿verdad? Tranquilo, que aún aún hay mucho más, espera a ver la segunda parte para tomar partido.
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)
*********************************************************************************************
21 comentarios:
Tu explicación no es lo que dice el estándar.
Si miras la RFC 4408, verás:
En la introducción:
This document defines a protocol by which domain owners may authorize hosts to use their domain name in the "MAIL FROM" or "HELO" identity. Compliant domain holders publish Sender Policy Framework (SPF) records specifying which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the authorization of sending Mail Transfer Agents (MTAs) using a given "HELO" or "MAIL FROM" identity during a mail transaction.
En la definición de "MAIL FROM" identity:
The "MAIL FROM" identity derives from the SMTP MAIL command (see [RFC2821]). This command supplies the "reverse-path" for a message, which generally consists of the sender mailbox, and is the mailbox to which notification messages are to be sent if there are problems delivering the message. [...]
SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the <sender>.
En ningún momento la RFC 4408 nombra los campos "Sender" or "From" de la RFC 2822, sino los comandos "HELO", "EHLO" y "MAIL FROM" de SMTP (RFC 2822 es su última actualización).
Así pues, Gmail no comprueba mal el "sender", sino que tú has malinterpretado el estándar. Lo que hay que comprobar es el valor que se pasa en el campo "MAIL FROM", no la cabecera "Sender" del Internet Message Format.
@anónimo, si Gmail implementara eso según el standar borraría el mensaje.
No he malinterpretado el standar, y me he ido a la wikipedia directamente porque, en el caso del SPF, recoge información de algo que existe en uso desde el año 2003.
En el mismo RFC que enlazas, reconoce lo siguiente:
"SPF has been in development since the summer of 2003 and has seen deployment beyond the developers beginning in December 2003. The design of SPF slowly evolved until the spring of 2004 and has since stabilized. There have been quite a number of forms of SPF, some written up as documents, some submitted as Internet Drafts, and many discussed and debated in development forums"
Y en este ejemplo trato de reflejar la implementación de Gmail y Hotmail. Luego me cuentas al final cuál te gusta más.
Saludos!
Maligno,
no estoy discutiendo el resultado de aplicar el filtro (borrar el correo o no), sino qué campos deben usarse como parámetros.
La RFC es bastante clara en esto: deben usarse los valores obtenidos de los comandos HELO, EHLO y MAIL FROM, no el valor incluido en "Sender", como tú sugieres.
Cualquier implementación que use Sender u otros campos para filtrar, está incumpliendo el estándar.
Si tú crees que una implementación que use Sender es mejor que una que cumpla el estándar descrito en la RFC, cojonudo, pero deja claro que no cumple el estándar.
También había gente a la que las "extensiones" de Internet Explorer les parecían estupendas, y luego ya sabemos qué pasó con eso...
@Anónimo, SenderID tiene su propio estándar.
RFC4406
En el caso de Gmail, al no aplicar la política está incumpliendo el estándar.
He modificado el parrafo del post para dejar claro tu comentario.
Vaya.. precisamente estaba revisando una incidencia relacionada con este tema, nosotros implementamos el spf en nuestro filtro de correo y en mi opinión si debe ser rechazado puesto que se trata de una suplantación de identidad.. por otro lado debemos tener en cuenta que en las conexiones SMTP no se obtienen las cabeceras de un correo hasta que no llega el bloque DATA.. por lo que si queremos rechazar de plano un correo antes de que llegue el contenido nos tenemos que fiar del comando MAILFROM, del HELO y de la IP con la que está efectuando la conexión. Otro problema lo tenemos con las redirecciones de correo.. que ese es otro campo de batalla
Como bien ha dicho antes "Anónimo", la diferencia importante es que el "Sender" y el "From" que comentas, son parte del "data", y no parte del "envelope", que es a lo que se refiere "Anónimo" con el "mail from". Muy pocos (practicamente ninguno) servidores o servicios de correo cotejan si el "mail from:" coincide con el "From:", el "Sender:" u otro campo del remitente el correo.
¿Porque aparecen dos return-path? No entiendo muy bien estas cabeceras smtp.
Return-path etc. no son cabeceras SMTP, pertenecen al estándar IMF (internet message format). No confudas los términos porque de ahí viene la confusión de Chema sobre cómo SPF funciona. Mira las RFC.
@anónimo, no sé porque dices que yo me confundo en cómo funciona el SPF. Creo que está bastante claro como funciona en la implementación de Gmail.
De hecho en la Wikipedia pone que se debería hacer uso de Return-Path (del IMF) para que pudiera servir como anti-spoofing.
Saludos!
Chema,
Ya he dicho que la RFC eslo que debes leer, no la Wikipedia. Pero de cualquier modo, aquí tienes tu enlace de wikipedia.
SPF validates the message envelope (the SMTP bounce address), not the message contents (header and body) – this is the distinction between SMTP (as specified in STD 10 or RFC 5321 ) and Internet Message Format (as specified in STD 11 or RFC 5322 ). It is orthogonalandcomplementaryto DomainKeys Identified Mail (DKIM),whichsigns the contents (including headers).
In brief, SPF validates MAIL FROM vs. its source server; DKIM validates "From:" by cryptographic means.
Ahora, comprueba si los campos que Gmail valida se ajustan o no al estándar.
@Anónimo,
ya te había puesto que miré la wikipedia pq SPF nació en una lista de correo y el Request for Comments (que está en experimental todavía y es un RFC) es posterior. En las implementaciones de la evaluación del registro SPF se ha hablado de usar mail from, from, sender y return-path, tal y como recoge la wikipedia.
En el caso de Gmail, que sigue el RFC de SPF1, no implementa la política de -all así que la respuesta es NO, no lo implementa.
Saludos!
Chema,
eres un melón (por no admitir que has malinterpretado el estándar y la página de la Wikipedia, pese a la evidencia presentada en los comentarios que otras personas y yo hemos hecho) y respondo no con la intención de convencerte, que ya sé que es imposible, sino para que si alguien lee tu artículo no caiga en el mismo error.
Ni la RFC ni la Wikipedia indican que SPF use los campos "From" o "Sender" de IMF. Todo lo contrario. Haz un "grep" sobre la página de la Wikipedia para "Sender" y "From", y verás que no es como dices. Además, otras citas de la misma página:
If the server accepts the sender, and subsequently also accepts the recipient(s) and the body of the message, it should insert a Return-Path header in the message's body in order to save the sender address. While the address in the Return-Path often matches other originator addresses in the mail header like "From:" or "Sender:" this is not necessarily the case, and SPF does not prevent forgeries of these other addresses.
Asimismo, de la RFC:
10.2. SPF-Authorized E-Mail May Contain Other False Identities
The "MAIL FROM" and "HELO" identity authorizations must not be construed to provide more assurance than they do. It is entirely possible for a malicious sender to inject a message using his own domain in the identities used by SPF, to have that domain's SPF record authorize the sending host, and yet the message can easily list other identities in its header. Unless the user or the MUA takes care to note that the authorized identity does not match the other more commonly-presented identities (such as the From: header field), the user may be lulled into a false sense of security.
Por lo tanto, cualquier implementación que utilice otros campos en su lugar no sigue el estándar SPF. Los "ataques" que usan suplantación de identidad en las cabeceras "Sender" y "From" funcionan contra SPF. Es un hecho conocido, acorde a como el protocolo se espera que funcione.
SPF no mira el mensaje, sólo la sesión SMTP (el "envelope"). Mírate la RFC detenidamente, porque me parece que no lo has hecho. Si hay implementaciones que sí los miran, estupendo, pero no es necesario hacerlo para cumplir el estándar (que, de hecho, indica sólo que se mire el "envelope").
Segundo "problema" que indicas: Gmail no rechaza el correo incluso si se indica -all (fail/hard fail). De nuevo, mírate la RFC de SPF:
2.5.4. Fail
A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright.
Es decir, el estándar deja la decisión sobre si rechazar el mensaje o no al servidor que lo recibe. Éste puede bien sólo marcar el mensaje, bien rechazarlo directamente. Gmail sólo lo marca, no lo rechaza porque tiene razones para ello:
It is just not safe to hard-reject spf-hardfail errors. Too many people misconfigure their SPF entries or don't completely educate their users about all the things they can't do with a strict SPF setup (mail forwarding, etc).
From what I know, google uses spf (and dkim) to help assess reputation in their spam filters, but they don't outright reject messages. (The only exception is ebay/paypal messages which are rejected if their dkim signature fails verification.)
Por lo tanto, Gmail cumple el estándar SPF, aunque sólo lo use para marcar los mensajes para su algoritmos anti-spam y nunca rechace mensajes basado en la política SPF.
@anónimo, jaja, gracias por llamarme melón... A ver, el concepto de marcar creo que no lo tenemos aprendido de la misma forma.
Primero de todo, Blogger está marcando tus comentarios como spam, así que eso debe ser un mensaje para tí ;)
A ver, el comentario que has puesto de este señor es muy divertido, ya que está saltandose la política marcada por La Caixa pq cree que no saben crearla, es decir, me salto el estandar porque los demás no lo entienden. Sí, creo que es una buena justificación.
SPF se creo para evitar ataques de engaño a usuarios: Spoofing/Phishing, así que las marcas son para el usuario y deberían ser visibles.
Me quedo sin batería, ya te contestaré el resto más adelante.
Saludos!
Chema,
Ten la vergüenza de admitir que te has equivocado y ya está, te dejo en paz, en serio. Esto no va sobre "a ver quién gana", sino sobre dar informacion veraz.
Tu problema es que estás asumiendo ciertas premisas que son erróneas. Puede que el principio de mínima incertidumbre funcione en muchos casos pero, desde luego, no funciona en la interpretación de los estándares.
Ya te he demostrado que el estándar SPF sólo exige filtrar usando los valores de SMTP, aunque tú asumías que también había que incluir las cabeceras IMF (¡incluso con más prioridad!).
Ya te he demostrado que el estándar no exige que un mensaje afectado por -all sea rechazado, aunque tú pensabas que ésa era exactamente la acción que -all indica.
¿Ahora quieres que te demuestre que el marcado no tiene por qué ser "visible al usuario"? Leete la RFC por favor. Infórmate bien antes de opinar. Verás que en ningún momento se menciona que el marcado del mensaje se haga "de forma visible", o se menciona la interfaz de usuario , etc
De nuevo estás asumiendo falsas premisas, y malinterpretando el estándar.
Gmail incluye una cabecera que marca el resultado de aplicar SPF, de forma que puedes filtrar dichos mensajes si así quieres (pero no filtra automáticamente, que, again, no es requerido por el estándar). ¿Por qué no explicas eso, que es más útil que quejarse de lo mal que Gmail implementa el estándar que tú malinterpretas?
Feliz Navidad.
@anónimo,
primero me has llamado melón y ahora me dices que tenga vergüenza. Antes de nada, te invito a que tengas tú un poco más de educación.
Ahora que tengo un poco más de batería te vuelvo a explicar un poco mi artículo para ver si lo entiendes.
Primero SPF es un RFC experimental y dista todavía un poco de ser un estándar de Internet. No sé si sabes como funciona el ciclo de vida del IETF, pero todavía no es un estándar de Internet. Ni SPF ni Sender ID ni DKIM.
En segundo lugar, como te he dicho ya, desde el 2003 que se empezó a trabajar con el registro SPF, ha habido múltiples implementaciones, basadas en mail from, from, sender y return path.
Por último, lo que dices de Gmail es una completa absurded, pues según cuentas no bloquea los correos con política hardfail porque los administradores "generalmente no tienen claro como funciona" y sin embargo me dices que con marcar en el código se está cumpliendo en el estándar. A ver, SPF intenta evitar el phishing y el spoofing, ataques que se hacen en la capa de usuario y tu me dices que los administradores de correo no saben como funciona el SPF y que sin embargo para los usuarios basta con ver el código fuente del correo y ver la marca SPF en el código original. Eso no lo sostienes ni de coña en ningún sitio. Bajo mi punto de vista, Gmail debería marcarlo en la visualización del correo.
Me reafirmo en que Gmail debería indicar que es un mensaje enviado en nombre de otro.
Por último, te recuerdo que el artículo compara entre SPF y SenderID para que decidas tú que implementación te gusta más.
Saludos!
Chema, no te enfades por lo de melón, que en mi tierra es un sinónimo de cabezota.
Me parece estupendo que pienses que Gmail debería rechazar el correo, y que me cuentes historias del abuelo cebolleta sobre el nacimiento de SPF, pero lo cierto es que la especificación de SPF (RFC 4480, no estándar IETF sino RFC experimental desde 2006 como bien puntualizas) indica:
1. Que debe usarse los datos de la sesión SMTP (no From, ni Sender, etc.)
2. Que el servidor receptor decide si desea rechazar el correo o no cuando el dominio especifica una política -all
3. Que el servidor receptor debe marcar el correo (nada de notificar al usuario, etc.: sólo marcarlo)
Así pues, Gmail se ajusta perfectamente a dicha especificación.
Y si la implementación de Gmail te parece una absurdez, me parece estupendo. Pero que sepas que estás valorando la especificación de SPF, no Gmail.
Y no tengo que sostener nada en ningún sitio: la especificación está ahí y cualquiera puede leerla. Pero la especificación de SPF, eh, no la de "SPF según San Maligno". Ésa creo que sólo está escrita en este blog.
Me resulta curiosísimo que, siendo la de Gmail una implementación tan absurda y sin sentido, sólo tú te hayas dado cuenta de ello y nadie más haya puesto el grito en el cielo por lo rematadamente mala que es. Supongo que éso debería ser un mensaje para ti... pero ya está bien claro que tú sólo rechazas mensajes, sobre todo si no vienen de fuentes autorizadas ;)
@anónimo, es la implementación de Gmail la critico porque ellos han decidido la manera de implementarlo no mostrando ninguna alerta al usuario, cuando es un sistema creado para el usuario.
Esto quiere decir que los servidores de correo están bien, pero Gmail, la paginica web a la que tu te conectas, falla.
Y no, no he sido el único que se ha quejado de esto. De ello, gracias a esto hay hasta herramientas para arreglarlo.
http://free.antivirus.com/email-id/
¿Qué te juegas a que acaban poniendo alertas en Gmail? Es lo que tenemos los "abuelos cebolletas".
Saludos!
Gmail usa SPF como una señal más en su filtrado anti-spam. No es la única, y no es para el usuario: es para el sistema que decide si algo es spam o no.
SPF no es ni mucho menos la solución definitiva. Muchos administradores lo configuran mal, puesto que indican sólo sus servidores MX pero no consideran que tienen usuarios enviando correo desde casa con otros servidores SMTP, etc. En tal caso, si el usuario envía el correo y Gmail lo rechaza o lo marca como spam, el usuario piensa que el problema es con Gmail, lo que es bastante problemático (sobre todo si tienes dominios albergados, como pasa con Google Apps). Habilitar SPF a la ligera no es tan sencillo, ni para el remitente ni para el destinatario. Seguramente por eso Gmail no impone medidas draconianas como rechazar el correo o indicar al usuario que es spam.
Por cierto, la herramienta a la que has enlazado no es sólo para Gmail, es para diversos servicios de webmail. Ponme todos esos enlaces de gente quejándose porque Gmail no hace lo que tú quieres respecto a SPF. Si tan mal está, habrá millones de quejas, ¿no?
Y me juego lo que quieras a que Gmail no lo hace. SPF es una mierda de protocolo que no funciona, que muy pocos dominios tienen implementados y muchos menos lo hacen bien (como ejemplo, tú mismo no has entendido las sutilezas del protocolo, y lo has confundido en parte con SenderID). El dominio tiene que tener unas cualidades muy específicas para que SPF sea efectivo, y no todos los administradores están dispuestos a mantener su dominio así: por eso Gmail sólo indica el origen para Ebay.
@anónimo, poner una alerta, como hace con DKIM (si activas el plug-ing de ponerlo para ebay y paypal) es lo mismo.
Parece que todavía no entiendes la esencia de SPF y sí, debería utilizarlo para detectar el spam... no crees que es "Spam" esto?
http://4.bp.blogspot.com/_Y2uWeGSk9Sw/S4Sxl6Ci72I/AAAAAAAAF5g/mTwkT3LeunI/s1600-h/cuatro.png
Pues aún hay más, he comprobado la IP desde la que se envía el correo y está en un RBL. ¿Venta de viagra, suplantación SPF, link a un URL así, cambio de claves, SPF -all de la compañía bancaria? Sí, creo que no he entendido las "sutilezas" del sistema de Gmail. Deberían publicarnos toda la información.
Me parece muy bien que a tí te guste, yo sigo diciedote que SPF se creo para el usuario, y que una suplantación y un phishing son ataques al usuario y, a parte de que sean muy draconianas las medidas de borrar un correo, Gmail los borra por spam (correo molesto) y esto es suplantación y ataque, mucho más peligroso.
Creo que no has entendido ni las sutilezas de SPF ni la esencia del protocolo, "anónimo".
Por supuesto que la herramienta funciona para muchos otros correos, ¿crees que hay algun perfecto? Si fuera así el correo no se estaría muriendo.
El correo se está muriendo porque la gente usa Facebook, twitter, etc. porque es más "guay", no porque haya spam. De hecho, Facebook, twiter, etc. tienen su propio spam (que a mí me parece mucho más molesto). De cualquier modo, el correo no se está muriendo en absoluto para empresas.
El mensaje que has puesto como ejemplo ha sido escrito manualmente, es un "ataque" dirigido y no es sencillo detectarlo automáticamente (si quieres evitar un alto número de falsos positivos). Los sistemas anti-spam, para evitar esos falsos positivos, se basan en estadísticas a gran escala, y está claro que ese mensaje es único en el mundo. Seguro que, si hubieras enviado miles de estos mensajes, Gmail los hubiera detectado como spam. Estás confundiendo un ataque dirigido de phishing con spam a gran escala: los sistemas anti-spam no te protegen frente a los primeros.
Gmail puede mostrar los mensajes para Ebay/Paypal porque se han puesto de acuerdo con Ebay para asegurarse de que su configuración SPF está bien, que no tienen usuarios enviando correos desde servidores SMTP no listados, remailers, etc. Hacer lo mismo para cada dominio que publique registros SPF simplemente no es viable y no compensa: SPF no es la panacea en absoluto, como bien queda explicado en la RFC.
Me parece bien que no te gusten esas razones, pero la verdad es que implementar correctamente SPF es difícil, y que los usuarios entiendan sus resultados aún más, así pues comprendo que Gmail hace lo posible para su situación. El beneficio potencial es muy pequeño (pocos dominios implementan SPF, menos aún lo hacen bien) y el daño para sus usuarios puede ser importante (mensajes perdidos sin saber por qué, etc.).
Incluir una alerta para cualquier mensaje en Gmail que incumpla la política SPF del dominio es sencillo (ya lo hacen para Ebay). Pregúntate entonces, ¿por qué no lo hacen para el resto de dominios? Ya tienen el código implementado, y si el beneficio fuera tan grande para sus usuarios, ¿por qué no hacerlo? Será que estos de Google son tontos...
Mi opinión es que el correo electrónico se asemeja al correo postal en que cualquiera puede enviar un mensaje suplantando a otra persona. No entiendo por qué la gente lo asume como un hecho normal para el correo postal, pero no lo entiende para el caso del correo electrónico. El protocolo SMTP no se diseñó teniendo en cuenta seguridad y autenticación (y, en parte, por eso triunfó y se hizo popular, al igual que pasó con HTTP, TCP, IP, etc.) y SPF es un mal intento de añadir autenticación a posteriori.
@Anónimo, esto ya está siendo un poco pesado. A ver, Gmail muestra los iconos de autenticado pq usa DKIM, no por SPF, y DKIM es parte del IMF y no garantiza correo falso. DKIM no triunfará tampoco, que ya está Mutual-TLS y da un poco más de seguridad.
Por supuesto que si hay un ataque a gran escala es más fácil de detectar el spam, pero aparte de eso hay heurísticas para los que no son a gran escala, y para detectar el spoofing en ataques dirigidos se pensó en crear SPF.
Lo que quiero demostrarte con eso es que SPF es para el usuario, para evitar ataques de Spoofing dirigido, como he dicho desde el principio, ese era el motu para crearlo.
Pero ya está bien, de verdad, estoy un poco cansado de esta conversación y además es bastante triste hablar con un "anónimo" que no da la cara.
Ya hemos perdido bastante tiempo los dos, a mí me seguirá pareciendo mal la implementación que hace Gmail y punto. Tú sigue con tu Gmail y andando.
Yo no pienso que los de Gmail sean tontos, - al contrario que tú has hecho en tu primer comentario de SenderID - sino que a Gmail no le interesa bloquear correos de ataques dirigidos y que debido a la arquitectura que tienen con las redirecciones de dominio no les resulta fácil usar SPF, por eso su política SPF es la más cutre de todas ?all mientras que el resto de las organizaciones tiene Softfail o Hardfail.
Saludos!
Publicar un comentario