Antecedentes.- Sender Policy FrameWork (SPF) es una técnica empleada para diferenciar el correo legítimo y el proveniente del SPAM. Esta técnica habia sido descrita por NOC en meses pasados, cuando aun era poco conocida.
La estrategia que se utiliza en SPF para diferenciar el correo bueno del malo consiste en dos pasos sencillos:
Verificación del Origen del Correo Electrónico
- Saber desde que computadora se esta enviando dicho correo electrónico.
- Verificar si dicha computadora esta autorizada para enviar correo.
Políticas de Envio y Recepción de Correo
- No permitir el envio de correo a usuarios que no proporcionen su contraseña.
- No permitir la entrada de correo desde direciones que no usen SPF u otro mecanismo válido (p.ej. Sender ID de Microsoft).
Verificación del Origen del Correo Electrónico.- Supongamos que alguien prentende enviarle a usted un correo electrónico. En principio no sabemos si el correo en cuestión es legítimo o se trata de correo basura.
Al momento que una computadora inicia el envío del correo electrónico hacia el servidor de correo donde usted recibe sus mensajes (mejor conocido como nuestro Servidor POP3 o de WebMail y que normalmente usamos para leer nuestro correo), este recoge automáticamente la dirección de la computadora que le esta enviando el mensaje.
Por ejemplo si usted recibe un correo de uno de nuestros usuarios "
Esta dirección de correo electrónico está protegida contra los robots de spam, necesita tener Javascript activado para poder verla
" la direccion de nuestro servidor y que origina el mensaje es la siguiente:
mail.noc.com.mx (direccion 67.18.92.203)
En ese instante el servidor de correo electrónico de usted revisa que dirección o dominio de correo tiene el remitente (o sea el correo electrónico de la persona que se supone está mandando dicho mensaje)., en esta caso es el siguiente:
Correo del Remitente:
Esta dirección de correo electrónico está protegida contra los robots de spam, necesita tener Javascript activado para poder verla
Usuario: pruebas
Nombre del dominio de Correo: noc.com.mx
Con este último dato el servidor de correo electrónico de usted realiza los siguientes pasos referentes al método de SPF:
1.- Se esta recibiendo un correo electronico desde la dirección 67.18.92.203
2.- Este correo dice que proviene de
Esta dirección de correo electrónico está protegida contra los robots de spam, necesita tener Javascript activado para poder verla
3.- Se pregunta al servidor DNS de NOC.COM.MX si la dirección 67.18.92.203 es una computadora autorizada para enviar correos a nombre de *@noc.com.mx.
4.- El DNS de NOC.COM.MX confirma que esa dirección si está autorizada para mandar dichos correos.
5.- Se entrega el correo electrónico para que usted pueda leerlo al revisar su bandeja de entrada.
Políticas de Envio y Recepción de Correo.- Si los servidores de correo electrónico ya tienen la capacidad de identificar el origen del mensaje, entonces la unica parte que se debe cuidar es la del envío.
Las compañías que dan este servicio deberán evitar que cualquier persona pueda enviar correo a traves de sus servidores, a menos que utilice su usuario y su contraseña. De esta forma en caso de que alguien envíe un correo basura a otra persona, quedará registrado en el sistema. De esta forma se puede rastrear el origen del mensaje y tomar medidas que van desde la suspensión del servicio para dicho usuario o incluso medidas legales de acuerdo al país y las leyes que rigan en el area de Telecomunicaciones.
Avances de SPF como estandar para validación de correo
SPF ha ido evolucionando, permitiendo que varios sistemas de correo electrónico puedan hacer uso de esta metodología, pero para convertirse en un estandar requiere la aprobación de organismos como la Internet Engineering Task Force (IETF), para alcanzar una aceptación globalizada. A continuación mostramos el anuncio por parte del equipo de desarrollo con respecto a la validación que se esta llevando a cabo por el organismo antes mencionado y algunos de los problemas que se enfrentan para dicho trámite:
Sender Policy Framework (SPF) News
----------------------------------
by Wayne Schlitt, June 24, 2005
Greetings!
The IETF has accepted the SPF specification for RFC status!
A little over a month ago, we restarted this spf-announce mailing list
with a few updates of what had happened in the last year. Since
then, we have been hard at work on several things, and the first to
bear fruit is the SPF specification.
This SPF specification aims to clearly define the semantics of SPF,
based on the older SPF specifications from late 2003 and early 2004,
taking into account the state of SPF implementations and making
adjustments that have been requested by the IETF. This latest SPF
specification has undergone considerable review, not only by the SPF
community, but also by various IETF groups.
On June 6th, we submitted the completed draft for consideration by the
IETF, and today, the IETF has voted to accept the SPF specification as an
"Experimental" RFC[1]. The SPF specification still needs to go through the
RFC Editor, and this can take weeks or even months to complete.
(There are currently around 300 draft RFCs in the editor queue.)
We had asked for consideration as a "Standards Track" RFC rather than
"Experimental", but the IETF has informed us that they would only
consider "Experimental" status[2]. This was not a big surprise, but we
were surprised at some of the other actions that they took.
The IETF has decided that the SPF specification can not be made into
an RFC until the Sender ID specification is also ready. This appears
to be in order to be 'fair' to Microsoft[3]. Moreover, the IETF has
declared that the last 1.5 years of SPF deployment will not count
toward the two year requirement for experimental testing that they
have set. Again, this is to be 'fair' to Microsoft since their
testing has barely begun.
The Sender ID specifications call for the reuse of SPF version 1
records in incompatible ways in conflict with the SPF specification.[4]
We have made our objections clear to the IETF, but so far, the IETF
appears to be ready to bless this abuse of SPF records.[5] We will
continue to work to try and make SPF as reliable as possible.
[1] https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0
[2] http://thread.gmane.org/gmane.mail.spam.spf.council/312
[3] http://thread.gmane.org/gmane.mail.spam.spf.council/314
[4] http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#anchor6
[5] http://thread.gmane.org/gmane.mail.spam.spf.council/333
|
