Implementation of an anti-spam solution with SPF and DomainKeys

Universidad de Deusto Ingeniera en Informtica Proyecto Fin de Carrera

Implementacin de una solucin anti-spam mediante SPF y DomainKeysAnder Elexpuru Ramrez Eneko Len Gonzlez Director: Pablo Garaizar Sagarminaga Septiembre de 2005

ResumenNuestro proyecto consiste en un estudio de las posibles soluciones existentes para combatir el spam, evitando la publicidad no deseada y el fraude en el correo electrnico que tanto abunda hoy en da.

Las dos soluciones que estudiamos con mas profundidad son SPF de Pobox que esta bastante extendida y DomainKeys de Yahoo que ha surgido recientemente. Ambas soluciones se implementan en los servidores de correo, siendo totalmente transparente estos mecanismos para los clientes.

SPF lucha contra la falsificacin del remite en los mensajes de correo electrnico y hace mas fcil evitar el fraude. Los propietarios de los dominios identifican sus servidores de correo saliente en su DNS. Y los receptores de correo verifican la direccin del emisor contra esa informacin y as pueden distinguir mensajes legtimos de fraudes antes de que cualquier mensaje sea transmitido.

DomainKeys es otra tecnologa que dan a los proveedores de correo un mecanismo para verificar tanto el dominio de los emisores de correo como la integridad de los mensajes enviados, es decir, que no sean alterados durante su transmisin. Para hacer esto, DomainKeys se basa en el uso de una clave privada y otra pblica para firmar y verificar los mensajes respectivamente.

Adems del estudio de estas tecnologas, hemos realizado su implantacin en dos servidores diferentes para demostrar su funcionamiento.

DescriptoresSpam SMTP SPF DomainKeys MTA

iii

ndice1. Objetivos .............................................................................................................. 1 1.1 Objetivos del proyecto.................................................................................. 1 1.2 Objetivos personales.................................................................................... 1 2. Planificacin del proyecto .................................................................................... 3 2.1 Tareas principales ........................................................................................ 3 2.1.1 Planificacin........................................................................................... 3 2.1.2 Control ................................................................................................... 3 2.1.3 Desarrollo .............................................................................................. 3 2.2 Tareas de desarrollo .................................................................................... 4 2.2.1 Recopilacin de informacin ................................................................ 4 2.2.2 Contratar los servicios de DNS ............................................................ 4 2.2.3 Instalar el servidor de correo 1 ............................................................. 4 2.2.4 Implantar SPF al servidor de correo 1.................................................. 4 2.2.5 Realizar las pruebas de SPF ................................................................ 4 2.2.6 Instalar el servidor de correo 2 ............................................................. 5 2.2.7 Implantar DomainKeys al servidor de correo 2 .................................... 5 2.2.8 Realizar las pruebas de DomainKeys .................................................. 5 2.2.9 Redactar la memoria ............................................................................ 5 2.2.10 Revisar la memoria............................................................................... 5 2.3 Estimacin de tiempos ................................................................................. 6 2.4 Estimacin de presupuestos ........................................................................ 7

3. El problema ......................................................................................................... 9 3.1 Phishing........................................................................................................ 9 3.2 Spam .......................................................................................................... 10 3.2.1 Historia del Termino............................................................................. 11 3.2.2 Obtencin de direcciones de correo.................................................... 12 3.2.3 Envi de los mensajes......................................................................... 13 3.2.4 Verificacin de la recepcin................................................................. 13 3.2.5 Precauciones para evitar el correo basura.......................................... 13

4. Sender Policy Framework .................................................................................. 17 4.1 Objetivo ...................................................................................................... 17 4.2 Funcionamiento.......................................................................................... 18

v

4.3 Registros SPF ............................................................................................20 4.3.1 Mecanismos .........................................................................................21 4.3.2 Extensin de los mecanismos .............................................................25 4.3.3 Modificadores.......................................................................................26 4.4 Configurar los registros SPF ......................................................................27 4.5 Publicar SPF...............................................................................................27 4.6 Desventajas................................................................................................28 4.6.1 Usar un MTA favorito ...........................................................................28 4.6.2 Los accesos pblicos...........................................................................28 4.6.3 Email forwarding ..................................................................................29 4.6.4 Objetores de conciencia ......................................................................30 4.6.5 Dominios de usar y tirar .......................................................................30 4.7 Detiene realmente el spam? ...................................................................31 5. DomainKeys .......................................................................................................33 5.1. Estandarizacin ..........................................................................................33 5.2. Funcionamiento ..........................................................................................34 5.3. Configurar registros para DomainKeys ......................................................35 5.3.1. Registros de poltica ...........................................................................36 5.3.2. Registros de claves pblicas ..............................................................37 5.4. Ventajas......................................................................................................38 5.5. Inconvenientes ...........................................................................................39 5.6. Otras caractersticas...................................................................................40 5.7. MTAs con soporte para DomainKeys.........................................................41 5.8. Detiene realmente el spam? ...................................................................41 6. Instalacin de un servidor de correo.................................................................43 6.1. Instalacin de Qmail ...................................................................................43 6.1.1. Crear el directorio de Qmail ................................................................43 6.1.2. Usuarios para Qmail ...........................................................................44 6.1.3. Compilar y configurar el directorio de trabajo .....................................45 6.1.4. Especificar el nombre del host............................................................46 6.1.5. Establecer los alias del sistema .......................................................46 6.1.6. Especificar el agente de procesamiento de correo.............................46 6.1.7. Instalar el reemplazo de sendmail ......................................................47 6.1.8. Qmail debe aceptar correo para el dominio........................................47 6.1.9. Instalar los manuales ..........................................................................47 6.2. Instalacin de tcpserver..............................................................................48 6.2.1. Descargar y descomprimir ucspi-tcp ..................................................48

vi

6.2.2. Compilar e instalar tcpserver .............................................................. 49 6.3. Configurar el inicio automtico de Qmail .................................................. 49 6.4. Probando Qmail ........................................................................................ 51 6.4.1. Iniciando Qmail ................................................................................... 51 6.4.2. Probar la recepcin............................................................................. 52 6.5. De Mailbox a Maildir.................................................................................. 52 6.5.1. Mailbox vs Maildir ............................................................................... 52 6.5.2. Configuracin para Maildir.................................................................. 52 6.5.3. Consideraciones de Maildir ................................................................ 54 6.6. Configuracin del POP.............................................................................. 54 6.6.1. Interfaz checkpassword ...................................................................... 54 6.6.2. Instalacin de checkpassword............................................................ 55 6.6.3. Activando el POP................................................................................ 55 6.6.4. Prueba manual sobre POP................................................................. 56 6.6.5. Enviar correo desde las estaciones.................................................... 57 6.7. La arquitectura de Qmail............................................................................ 58 7. Implantacin de SPF sobre Qmail.................................................................... 61 7.1. Configuracin ............................................................................................. 61 7.2. Emails de ejemplo ...................................................................................... 63 7.2.1. Email legitimo ..................................................................................... 63 7.2.2. Email fraudulento con SPF fallido ...................................................... 64 7.2.3. Email fraudulento con SPF neutral..................................................... 66 8. Implantacin de DomainKeys sobre Qmail ...................................................... 67 8.1. Generar las claves ..................................................................................... 68 8.2. Configuracin ............................................................................................. 70 8.3. Emails de ejemplo ...................................................................................... 73 8.3.1. Recepcin de un email legitimo.......................................................... 73 8.3.2. Emisin de un email legitimo .............................................................. 74 8.3.3. Recepcin de un email no firmado ..................................................... 75

9. Conclusiones .................................................................................................... 77 9.1. Objetivos del proyecto................................................................................ 77 9.2. Objetivos personales.................................................................................. 77 9.3. Conclusiones personales ........................................................................... 77 10. Bibliografa ........................................................................................................ 79

vii

Anexo A: Caller ID ...................................................................................................81 A1: Sender ID....................................................................................................82 Anexo B: Otras tecnologas contra el spam ............................................................83 B1: FairUCE ......................................................................................................83 Anexo C: Los sistemas de reputacin.....................................................................85 C1: La acreditacin ...........................................................................................86 C2: Ideas para la lista de dominios buenos......................................................86 C3: Clearinghouse ............................................................................................87 Anexo D: Glosario ...................................................................................................91

Anexo E: Licencia Publica General .........................................................................93

ndice FigurasFigura 2.1 Estimacin de tiempos ..........................................................................6 Figura 2.2 Estimacin de tiempos de desarrollo ....................................................6 Figura 2.3 Diagramas de Gantt ..............................................................................6 Figura 2.4 Diagramas de Gantt II ..........................................................................7 Figura 2.5 Diagramas de Gantt III ..........................................................................7 Figura 3.1 Esquema de phishing por email..........................................................10 Figura 3.2 Lata de spam.......................................................................................11 Figura 4.1 Funcionamiento de SPF......................................................................18 Figura 4.2 Ejemplo de consulta SPF....................................................................20 Figura 5.1 Funcionamiento de DomainKeys ........................................................34 Figura 5.2 Ejemplo de consulta DomainKeys ......................................................35 Figura 6.1 Arquitectura de Qmail ........................................................................59 Figura 8.1 Valores de DKVERIFY ........................................................................71 Figura C.1 Representacin del correo ideal.........................................................85 Figura C.2 Representacin del correo real ..........................................................85 Figura C.3 Representacin de dominios buenos y malos....................................85 Figura C.4 Representacin de un clearinghouse.................................................89

viii

Universidad de Deusto . . . . Facultad de Ingeniera

Objetivos

Proyecto Fin de Carrera

1. ObjetivosPodemos distinguir entre los objetivos que se plantean en el proyecto y los objetivos que pretendemos conseguir a nivel personal.

1.1 Objetivos del proyectoLos objetivos que se plantean conseguir con este proyecto son los siguientes:

Estudio del funcionamiento de SPF. Comprensin de las ventajas e inconvenientes del uso de SPF. Implantacin de un servidor de correo con SPF. Estudio del funcionamiento de DomainKeys. Comprensin de las ventajas e inconvenientes del uso de DomainKeys. Implantacin de un servidor de correo con DomainKeys.

1.2 Objetivos personalesLos objetivos personales que nos gustara conseguir con este proyecto son los siguientes:

Aprender como implantar un servidor de correo electrnico. Conocer mas a fondo el funcionamiento de la transmisin del correo electrnico. Conocer las tcnicas utilizadas por los spammers.

1


Planificacin del proyecto


2. Planificacin del proyecto

2.1. Tareas principales

2.1.1. PlanificacinEn esta fase se distribuir el trabajo en diferentes actividades que se repartirn entre los miembros del grupo. Adems se acordarn las fechas para empezar y terminar cada actividad de las que consta el proyecto.

2.1.2. ControlMientras se ejecuta el proyecto se har un completo seguimiento de la evolucin de este para la deteccin y solucin de problemas.

2.1.3. DesarrolloEl desarrollo constar de tres fases principales. Primeramente, se conseguir toda informacin posible sobre SPF, DomainKeys y otras tecnologas contra el spam en el correo electrnico. Despus se proceder a la instalacin de los servidores necesarios para conseguir los objetivos y se aplicarn sobre estos los conocimientos adquiridos sobre las tecnologas anti-spam anteriormente mencionadas. Finalmente se realizar la documentacin de cada actividad realizada con el fin de realizar un estudio mas completo. En el siguiente punto se explican con mas detalle las tareas que componen estas fases.

3


Implementacin de una solucin anti-spam mediante SPF y DomainKeys


2.2. Tareas de desarrollo

2.2.1. Recopilacin de informacinEn esta tarea se conseguir toda la informacin posible sobre SPF, DomainKeys y otras tecnologas contra el spam en el correo electrnico, procurando tener todo lo que nos pudiera ser necesaria durante las tareas posteriores.

2.2.2. Contratar los servicios de DNSEs necesario encontrar un servicio de nombre de dominio que nos permita registrar un par de dominios con soporte para registros A, MX y TXT. A ser posible gratuito.

2.2.3. Instalar el servidor de correo 1Esta instalacin pretende tener preparado un servidor de correo en un PC para luego aplicarle las funcionalidades de SPF.

2.2.4. Implantar SPF al servidor de correo 1Tras preparar el servidor de correo se aplicarn los conocimientos necesarios sobre este para tener SPF operativo.

2.2.5. Realizar las pruebas de SPFPara acabar con este servidor se realizarn las pruebas y ajustes necesarios hasta que funcione como es debido, es decir, filtrando el spam.

4




2.2.6. Instalar el servidor de correo 2A continuacin se proceder a la instalacin del segundo servidor de correo, como se hizo en el apartado 2.2.3, pero en este caso ser para aplicar sobre l DomainKeys.

2.2.7. Implantar DomainKeys al servidor de correo 2Tras completar la instalacin del servidor se proceder a aplicarle los conocimientos adquiridos sobre DomainKeys.

2.2.8. Realizar las pruebas de DomainKeysSe proceder a la verificacin del correcto funcionamiento del segundo servidor, es decir, que manda y recibe correo con normalidad a la vez que filtra el spam y firma los mensajes con las claves.

2.2.9. Redactar la memoriaEsta tarea consiste en redactar con detalle toda la informacin adquirida y la experiencia realizada durante las instalaciones prcticas, tratando de estructurar todo de la mejor forma posible de forma que la memoria sea clara.

2.2.10. Revisar la memoriaFinalmente, una vez redactada la memoria habr que revisarla minuciosamente para corregir los posibles errores ortogrficos, gramaticales u otros fallos que puedan existir.

5




2.3. Estimacin de Tiempos

Tareas principales Planificacin Control DesarrolloFigura 2.1 Estimacin de tiempos

Das 1 42 42

Tareas de desarrollo Recopilacin de la informacin Contratar los servicios de DNS Instalar el servidor de correo 1 Implantar SPF al servidor 1 Realizar las pruebas de SPF Instalar el servidor de correo 2 Implantar DomainKeys al servidor 2 Realizar las pruebas de DomainKeys Redactar la memoria Revisar la memoriaFigura 2.2 Estimacin de tiempos de desarrollo

Das 9 1 3 3 5 1 4 6 8 2

A continuacin se muestran los diagramas Gantt correspondientes a las tareas de desarrollo del proyecto que muestran con mayor detalle la duracin de cada actividad as como su fecha de comienzo:

Figura 2.3 - Diagramas de Gantt I

6




Figura 2.4 - Diagramas de Gantt II

Figura 2.5 - Diagramas de Gantt III

2.4. Estimacin de presupuestoLas licencias de los productos usados no tiene coste alguno, todos ellos los podemos descargar de sus respectivas pginas web. Podra suponer un coste la infraestructura de equipos necesarios para alojar los servidores de correo si no se dispone de estos. Otra cosa que puede suponer un gasto es el servidor de nombres que darn un nombre a las direcciones IP de nuestros servidores y que adems deben permitir el uso de registros MX y TXT.

7


El problema


3. El problemaHoy en da el correo electrnico es uno de las herramientas mas usadas para comunicarse tanto en el mundo laboral como personal. Por esto muchas compaas e individuos se aprovechan de este uso para beneficiarse, creando un malestar a los usuarios de este servicio adems de deteriorarlo.

Las dos practicas mas habituales de mal uso de este servicio son el phishing y el spam que describimos a continuacin.

3.1. PhishingPhishing es la capacidad de duplicar una pgina web para hacer creer al visitante que se encuentra en la pgina original en lugar de la copiada. Normalmente se utiliza con fines delictivos duplicando pginas web de bancos conocidos y enviando indiscriminadamente correos para que se acceda a esta pgina a actualizar los datos de acceso al banco.

De forma ms general, el nombre phishing tambin se aplica al acto de adquirir, de forma fraudulenta y a travs de engao, informacin personal como contraseas o detalles de una tarjeta de crdito, hacindose pasar por alguien digno de confianza con una necesidad verdadera de tal informacin en un e-mail parecido al oficial, un mensaje instantneo o cualquier otra forma de comunicacin. Es una forma de ataque de la ingeniera social. Puede verse un ejemplo en ingles en http://purl.org/net/tbc/misc/phish001.htm.

El trmino phishing fue creado a mediados de los aos 90 por los crackers que procuraban robar las cuentas de AOL. Un atacante se presentara como empleado de AOL y enviara un mensaje inmediato a una vctima potencial. El mensaje pedira que la vctima revelara su contrasea, con variadas excusas como la verificacin de la cuenta o confirmacin de la informacin de la facturacin. Una vez que la vctima entregara la contrasea, el atacante podra tener acceso a la cuenta de la vctima y utilizarla para cualquier otro propsito, tales como Spamming.

9




Figura 3.1 Esquema de phishing por email

En la figura 3.1 se muestra como un usuario cualquiera (SPAMMER) puede mandar un email a otro ([email protected]) hacindose pasar por la persona que el quiera ([email protected]).

3.2. SpamEl spam es el hecho de enviar mensajes electrnicos (habitualmente de tipo comercial) no solicitados y en cantidades masivas. Aunque se puede hacer por distintas vas, la ms utilizada entre el pblico en general es la basada en el correo electrnico. Otras tecnologas de internet que han sido objeto de spam incluyen mensajes, grupos de noticias usenet, motores de bsqueda y blogs. El spam tambin puede tener como objetivo los telfonos mviles (a travs de mensajes de texto) y los sistemas de mensajera instantnea.

El spam mediante el servicio de correo electrnico naci a partir del da 5 de Marzo de 1994. Ese da una firma de abogados de Canter and Siegel, public en Usenet un mensaje de anuncio de su firma legal, el cual en el primer da despus de la publicacin, factur cerca de 10.000 dlares por casos de sus amigos y lectores de la red. Desde ese entonces, el marketing mediante correo electrnicos ha crecido a niveles impensados desde su creacin

10


El problema


El spam por medio del fax (spam-fax), es otra de las categoras de esta tcnica de marketing directo, y consiste en enviar faxes masivos y no solicitados a travs de sistemas electrnicos automatizados hacia miles de personas o empresas cuya informacin ha sido cargada en bases de datos segmentadas segn diferentes variables.

En Espaa el spam est terminantemente prohibido por la Ley de Servicios de la Sociedad de la Informacin y de Comercio Electrnico (LSSICE), publicada en el BOE del 12 de julio de 2002.

3.2.1. Historia del trmino

El origen de la palabra spam tiene races estadounidenses con unas curiosas derivaciones socio-culturales.

La empresa charcutera estadounidense Hormel Foods lanz en 1937 una carne en lata originalmente llamada Hormel's Spiced Ham. El gran xito del invento lo convirti con el tiempo en una marca genrica, tan conocida que hasta el mismo fabricante le recort el nombre, dejndolo con solo cuatro letras: Spam. El Spam aliment a los soldados soviticos y britnicos en la Segunda Guerra Mundial, y desde 1957 fue comercializado en todo el mundo. En los aos 60 se hizo aun ms popular gracias a su innovadora anilla de apertura automtica, que ahorraba al consumidor el uso del abrelatas.Figura 3.2 Lata de spam

Fue entonces cuando los Monty Python empezaron a hacer burla de la carne en lata. Su divertidsima costumbre de gritar la palabra spam en diversos tonos y volmenes se traslad metafricamente al correo electrnico no solicitado, que perturba la comunicacin normal en internet.

En un famoso sketch de 1969 (Flying Circus) los comediantes britnicos representaban a un grupo de hambrientos vikingos atendidos por solcitas camareras que les ofrecan "huevo y panceta; huevo, salchichas y panceta; huevo y spam; huevo, panceta, salchichas y spam;

11




spam, panceta, salchichas y spam; spam, huevo, spam, spam, panceta y spam; salchichas, spam, spam, panceta, spam, tomate y spam, ...". La escena acababa con los vikingos cantando a coro "Spam, spam, spam, spam. Rico spam! Maravilloso spam! Spam, spa-a-a-a-a-am, spaa-a-a-a-am, spam. Rico spam! Rico spam! Rico spam! Rico spam! Rico spam! Spam, spam, spam, spam".

Como la cancin, el spam es una repeticin sin fin de texto de muy poco valor o ninguno, que aplicado a los mensajes electrnicos, se refiere a los mensajes enviados de forma masiva y dirigidos a personas que, en principio, no desean recibirlos.

La mayor parte de los mensajes (ms del 40%) proceden de Estados Unidos (a pesar de que all est prohibido), seguido por Corea del Sur (15%) y China (12%).

3.2.2. Obtencin de direcciones de correoLos spammers (individuos o empresas que envan spam) utilizan diversas tcnicas para conseguir las largas listas de direcciones de correo que necesitan para su actividad, generalmente a travs de robots o programas automticos que recorren internet en busca de direcciones. Algunas de las principales fuentes de direcciones para luego enviar el spam son:

Las propias pginas web, que con frecuencia contienen la direccin de su creador, o de sus visitantes (en foros, weblogs, etc.). Los grupos de noticias de usenet, cuyos mensajes suelen incluir la direccin del remitente. Listas de correo: les basta con apuntarse e ir anotando las direcciones de sus usuarios. Correos electrnicos con chistes, cadenas, etc. que los usuarios de internet suelen reenviar sin ocultar las direcciones, y que pueden llegar a acumular docenas de direcciones en el cuerpo del mensaje. Pginas en las que se solicita tu direccin de correo (o la de "tus amigos") para acceder a un determinado servicio o descarga.

12


El problema


Compra de bases de datos de direcciones de correo a empresas o particulares (ilegal en la mayor parte de los pases). Entrada ilegal en servidores. Por ensayo y error: se generan aleatoriamente direcciones, y se comprueba luego si han llegado los mensajes. Un mtodo habitual es hacer una lista de dominios, y agregarles "prefijos" habituales. Por ejemplo, para el dominio microsoft.com, probar [email protected], [email protected], [email protected], etc.

3.2.3. Envo de los mensajesUna vez tienen una gran cantidad de direcciones de correo vlidas (en el sentido de que existen), los spammers utilizan programas que recorren la lista enviando el mismo mensaje a todas las direcciones. Esto supone un costo mnimo para ellos, pero perjudica al receptor (prdidas econmicas y de tiempo) y en general a internet, por consumirse gran parte del ancho de banda en mensajes basura.

3.2.4. Verificacin de la recepcinAdems, es frecuente que el spammer controle qu direcciones funcionan y cules no por medio de web bugs o pequeas imgenes o similares contenidas en el cdigo HTML del mensaje. De esta forma, cada vez que alguien lee el mensaje, su ordenador solicita la imagen al servidor del spammer, que registra automticamente el hecho. Son una forma ms de spyware. Otro sistema es el de prometer en los mensajes que enviando un mail a una direccin se dejar de recibirlos: cuando alguien contesta, significa no slo que lo ha abierto, sino que lo ha ledo.

3.2.5. Precauciones para evitar el correo basuraSi tienes que poner tu direccin en tu web para que contacten contigo: En vez de poner la direccin como texto, mustrala en una imagen con la direccin de correo. Actualmente no se pueden rastrear automticamente.

13




En vez de poner el enlace a tu cuenta, usa una redireccin (puede ser temporal), y brrala cuando recibas excesivo spam. Modificar la direccin para evitar el rastreo automtico. Por ejemplo, cambiar "[email protected]" por "nombre (ARROBA) dominio (PUNTO) com",

"[email protected] , quita NOSPAM" o "[email protected] (sustituir los ceros por oes)". Una combinacin de las anteriores. Algunos servicios de correo gratuito como Mailinator ofrecen cuentas temporales sin tener que usar contraseas. Los mensajes se borran automticamente al cabo de unas horas. Puede ser til si slo quieres que contacten contigo una vez, por ejemplo para confirmar un pedido.

En los grupos de noticias y listas de correo: No poner el remitente verdadero en los post enviados. Si el archivo de mensajes a la lista es visible desde web, cambiar las direcciones de remite por una imagen, ocultarlas, o escribirlas de forma que sea difcil reconocerla como tal para un programa. Para evitar spam en una lista: o o El foro puede estar moderado, para evitar mensajes inadecuados. Rechazar correos de usuarios no suscritos a la lista.

Otros: No reenviar mensajes parte de una cadena de correo electrnico. No hacer envos a amigos o colaboradores en los que aparezcan muchas direcciones y, si se hace, usar Bcc (o CCO) para que no sean visibles las dems direcciones. Igualmente, si reenvas un correo electrnico que ya contiene alguna direccin en el mensaje, asegrate de borrarla. Al rellenar una inscripcin no dar el correo. Si es necesario dar una direccin correcta (para envo de contraseas, confirmacin de la suscripcin, etc.) utiliza una redireccin

14


El problema


temporal, o una cuenta gratuita "extra" prescindible de las que se ofrecen en la mayora de los portales de internet. No se debe hacer caso de las recomendaciones del tipo "preferiblemente cuenta no Hotmail". Leer los correos de remitentes sospechosos como texto, y no como HTML. No enviar nunca mensajes al spammer, aunque prometan dejar de enviar spam si se les pide. A menudo ofrecen una forma de anular la suscripcin a su boletn de mensajes (lo que en ingls llaman "opt-out", u optar por salir) que suele consistir en mandar un mensaje a una direccin de tipo [email protected] . Si mandas un mensaje a dicha direccin con la esperanza de dejar de recibir correo no solicitado, slo ests confirmando que tu cuenta existe y est activa, por lo que acabars recibiendo ms spam que antes.

Hay formas de bloquear mensajes que tengan ciertas caractersticas, por ejemplo, si en el asunto aparece la palabra "porno". Sin embargo, muchos spammers escriben algunas palabras con faltas intencionadas de ortografa o introducen algn espacio o signo de puntuacin en la palabra ms propensa a ser bloqueada (por ejemplo, escribiran "p0rn0" o "p o r n o"). Por lo que bloquear mensajes no suele ser muy til.

15


Sender Policy Framework


4. Sender Policy FrameworkEl autor de SPF se llama Meng Weng Wong. El concepto de esta tecnologa se cre a finales de los aos noventa. SPF es una versin simplificada de la propuesta RMX de Hadmut Danisch. Y a la vez RMX se basa en el artculo de Paul Vixie, Repudiating Mail-From. El cual fue el resultado de una sugerencia de Jim Miller en 1998.

Cuando se desarrollo SPF, el primer significado de las siglas fue Sender Permitted From, pero el nombre pareci ser confuso para la gente, as que a principios de febrero del 2004 se cambi por un significado mas exacto que fue Sender Policy Framework, que es como ahora se llama.

4.1. Objetivo

SPF no se cre para evitar el spam, esto es un malentendido muy tpico. SPF se diseo para garantizar la autenticidad del usuario, cosa que hace bastante bien. Pensemos en la gran cantidad de emails que recibimos de direcciones de correo procedentes de dominios de los que realmente no pertenecen. Estos emails pueden ser tratados como se desee gracias a SPF.

El objetivo de SPF es bloquear cualquier email que este falsificando su dominio de procedencia. SPF dice que un dominio solo puede enviar correo de tales maquinas. Si cualquier otra maquina manda un email que dice proceder de ese dominio, entonces esta mintiendo, y se sabr.

Por ejemplo, cuando un usuario de Gmail nos enva correo, un servidor de correo que pertenece a Gmail conecta a nuestro servidor de correo para enviarnos el email. Gmail usa SPF para publicar las direcciones de sus servidores de correo, as que cuando recibimos un email, nuestro servidor de correo puede decir si el servidor que enva el mensaje pertenece a Gmail o no.

SPF trata de evitar que los spammers arruinen la reputacin de otra compaas. A si que si quieren hacer spam, tendrn que hacerlo al menos desde su propio dominio, quedndose ellos con su propia reputacin de spammers.

17




Como usuario, SPF puede ayudarnos a clasificar el correo bueno y el malo, desechar correo que no pase el chequeo de SPF, usarlo para ayudar a los filtros de spam a tomar decisiones, y tener la seguridad de que el correo que dice ser de nuestro banco o del gobierno es realmente de quien dice ser.

Si recibimos spam que ha pasado el chequeo SPF, entonces sabemos que el responsable de dicho spam es el dominio del que procede. Entonces se podrn aplicar medidas contra esos dominios si fuera necesario.

4.2. FuncionamientoLos dominios utilizan registros pblicos, llamados DNS, para dirigir las peticiones de diferentes servicios (web, email, etc.) a las maquinas que los proporcionan. Adems los dominios pueden publicar registros de email (MX) para decir que maquinas reciben correo para ese dominio.

Para el funcionamiento de SPF, los dominios tienen que publicar registros TXT en su servidor de nombres (DNS) para decir que maquinas son las que envan correo perteneciente al dominio. Cuando se recibe un email de un dominio, el receptor puede leer esos registros a travs de una consulta SPF (ver figura 4.1) para comprobar que el email viene de donde debera venir, y que no es un fraude.

Figura 4.1 Funcionamiento de SPF

Por ejemplo, Gmail enva un email a Hotmail. Gmail tiene publicado un registro SPF especificando que maquinas son las que pueden enviar correo del estilo [email protected], es decir, emails con su dominio. El correo puede ser realmente de Gmail o no y Hotmail es el

18




que se tiene que encargar de comprobarlo. A continuacin se ven los ejemplos de ambos casos. Si el mensaje es vlido:

1. Cuando un usuario real de Gmail enva un email, Hotmail recibe el mensaje de un servidor de Gmail. 2. Hotmail lee el registro SPF de Gmail para comprobar si el servidor que le envi el mensaje tiene permiso para enviar correo de Gmail. 3. Como la IP del emisor esta en la lista, Hotmail da el mensaje como bueno.

Y esto ocurrira si el emisor estuviera falsificando la direccin de origen:

1. Cuando un spammer enva correo diciendo que es del dominio de Gmail, Hotmail recibe el mensaje del servidor que haya utilizado el spammer. 2. Hotmail lee el registro SPF de Gmail. 3. Como la IP del servidor que envi el mensaje no esta en la lista, Hotmail da el mensaje como invlido. De esta forma se evitan los costosos chequeos de spam basados en el contenido del correo, ahorrando recursos en el sistema receptor.

Para verlo de otra forma, supongamos que somos el servidor de correo de nuestro buzn electrnico y que hay un spammer que usa una direccin del estilo @gmail.com. El conecta con cualquier servidor de correo que no sea Gmail para enviarnos spam en forma de email.

Cuando recibimos el email vemos la direccin de correo de origen, por ejemplo [email protected] (ver figura 4.2), pero puede que el servidor que nos lo enva no sea de Gamil. As que vamos a pedirle a Gmail la lista de direcciones IP que pueden enviar correo con el dominio gmail. Esta lista la ha publicado en un registro SPF al que se puede acceder libremente.

Si la direccin IP del servidor que nos mand el mensaje esta en la lista del registro SPF, entonces es vlida, el email se aprueba y asumimos que el que envi el mensaje es quien dice ser. Pero si la IP que nos manda el email no esta en la lista del registro SPF, entonces se trata de una falsificacin de la direccin de correo, y podemos pensar que se trata de spam o phising.

19




Figura 4.2 Ejemplo de consulta SPF

Hay que decir que SPF se fija en la cabecera Mail From (solo visible para los MTAs) del sobre del email y no en la cabecera From (que cualquier usuario puede ver) del propio mensaje. Esto hace mas gil la comprobacin ya que no hay que recibir el mensaje entero. As se puede desechar el mensaje si fuera ilegtimo sin descargarlo por completo, ahorrando tiempo y ancho de banda.

4.3. Registros SPFPara trabajar con SPF se requieren dos cosas. Primera de ellas, que el servidor de correo desde el que se enva disponga de un registro TXT en el servidor DNS. Y dos, que el servidor de correo entrante opere con SPF para que lea este registro y saber cmo actuar.

Veamos, un registro TXT en un servidor DNS de ejemplo: "v=spf1 +a +mx +ptr include: ejemplo.net exp=spf-err ~all"

Como podemos ver, el registro consta de varios parmetros llamados mecanismos. A continuacin se describe para que sirven todos ellos.

20




4.3.1. MecanismosEl registro SPF definen cero o mas mecanismo. Los mecanismos se pueden usar para describir un grupo de hosts que son designados como emisores de correo para el dominio. Los mecanismos que se pueden utilizar son: all, a, mx, ptr, ip4, include, exists y otras extensiones. Adems tambin se pueden definir modificadores: redirect y explanation.

Los mecanismos pueden llevar uno de estos cuatro prefijos:

-

fail

Si se utiliza este prefijo se rechazara la IP que coincide con el mecanismo y se desechara el email.

~

softfail

En este caso no se desechara el email pero quedara marcado una cabecera especial para darle posteriormente algn tipo de tratamiento.

+

pass

Este prefijo aprueba la IP y aade una cabecera de tipo Received-SPF: pass.

?

neutral

Este prefijo no dara como bueno el mensaje pero tampoco como malo. Aade una cabecera de tipo Received-SPF: neutral. Se utiliza sobretodo para periodos de prueba. El prefijo por defecto es pass. Los mecanismos se evalan en orden de izquierda a derecha hasta que se encuentra una coincidencia de un mecanismo con la direccin IP del emisor, entonces se usa el valor de su prefijo.

Si un dominio no tiene registro SPF, el valor que toma la comprobacin de SPF es none, es decir el servidor que hace la comprobacin agregara una cabecera al email de tipo Received-SPF: none. Si un dominio tiene un error temporal durante el procesamiento DNS, se devuelve el valor error. Si ocurre algn tipo de error sintctico o de evaluacin (por ejemplo el domino especifica un mecanismo desconocido) el valor es unknown.

A continuacin se muestran los mecanismos que se pueden usar con un ejemplo de utilizacin y seguidos de la descripcin de su uso:

21




all

all Este mecanismo siempre coincide. Se pone al final del registro para que siempre se

sepa que hacer con los emails.

Lo normal sera ponerle el prefijo - para rechazar cualquier IP que no haya coincidido con el resto pero muchos dominios ponen ? por ser SPF algo que todava no se ha estandarizado.

a

a a:domain a:domain/cidr-length a/cidr-length Todos los registros A para el dominio domain se comprueban. Si se encuentra entre

ellos la IP del servidor que envi el email, el mecanismo coincide y se utiliza su prefijo.

Si no se especifica domain, se utiliza su propio dominio para hacer la consulta al registro A.

Los registros A tienen que coincidir con la IP del servidor que enva el mensaje, a menos que se ponga un cidr-lenght, en cuyo caso cada direccin IP devuelta por la consulta al registro ser expandida a su correspondiente subred CIDR, de forma que la IP del servidor ser buscada en esa subred.

Ejemplos:

"v=spf1 a -all"

Se usa su propio dominio para hacer la consulta al registro A. Es decir, si vamos a consultar el registro TXT de ejemplo.com, el registro A que deberamos consultar es el de ejemplo.com, obtendramos la IP y esa sera la nica direccin valida que podra enviar emails con dominio ejemplo.com.

"v=spf1 a:ejemplo.com -all"

En este caso sera lo mismo que en el anterior si su propio dominio fuera ejemplo.com.

22




"v=spf1 a:mailers.ejemplo.com -all"

En este caso ejemplo.com ha decidido listar todos los servidores de correo en el registro A de mailers.ejemplo.com.

"v=spf1 a/24 a:offsite.ejemplo.com/24 -all"

Si ejemplo.com es 192.0.2.1, se buscara la IP del cliente en la red de clase C 192.0.2.0/24. De forma similar para offsite.ejemplo.com. Si se devolviera mas de un registro A, cada uno sera expandido en una subred CIDR.

mx

mx mx:domain mx:domain/cidr-length mx/cidr-length Todos los registros A de los registros MX de domain son comprobados en orden de

prioridad del MX. Si se encuentra la IP del cliente entre ellos entonces el mecanismo coincide.

Si no se especifica domain, se usa su propio dominio.

Los registros A tienen que coincidir con la IP del cliente, a menos que se ponga un cidrlenght, en cuyo caso cada direccin IP devuelta por la consulta al registro A ser expandida a su correspondiente subred CIDR, de forma que la IP del cliente ser buscada en esa subred.

Ejemplos:

"v=spf1 mx mx:deferrals.dominio.com -all" Esto servira en caso de que un domino enve correo a travs de su servidor MX y utilice otro grupo de servidores cuyo trabajo sea reintentar el envo.

"v=spf1 mx/24 mx:offsite.dominio.com/24 -all"

En este caso los servidores de correo de un dominio podran recibir correo en una direccin IP, y enviar correo con una direccin distinta de la misma subred.

23




ptr

ptr ptr:domain El hostname o hostnames para la IP del cliente se consultan usando peticiones PTR.

Los hostnames luego se validan: al menos uno de los registros A para un hostname PTR debe coincidir con la IP original del cliente. Los hostnames invlidos se descartan. Si un hostname valido acaba en domain especificado entonces el mecanismo coincide.

Si no se especifica domain, se usa su propio dominio: "v=spf1 ptr -all"

Un dominio que controla todas sus maquinas (a diferencia de los ISP que ofrecen conexiones a Internet) permite a todos sus servidores enviar correo. Por ejemplo, Hotmail.com o paypal.com podran hacerlo.

"v=spf1 ptr:otrodominio.com -all"

En este caso cualquier servidor cuyo hostname termine en otrodominio.com es designado.

ip4 Cidr-spec es una red IP.

ip4:cidr-spec

"v=spf1 ip4:192.168.0.1/16 -all"

Permite enviar correo a cualquier direccin IP entre 192.168.0.1 y 192.168.255.255.

exists

exists:domain

Realiza una consulta de tipo A sobre domain. Si se encuentra un resultado, entonces se considera una coincidencia. No importa cual sea el resultado de la consulta, podra ser 127.0.0.2.

En el siguiente ejemplo, la IP del cliente es 1.2.3.4 y el dominio que se consulta es ejemplo.com.

24




"v=spf1 exists:ejemplo.net -all"

Si ejemplo.net no se resuelve, el resultado es fallido (fail). Si se resuelve, el resultado del mecanismo sera una coincidencia.

include

include:otherdomain

Se busca que el otherdomain especificado tenga un allow. Si la consulta no devuelve allow, el procesamiento pasa a la siguiente directiva.

En el siguiente ejemplo, la IP del cliente es 1.2.3.4 y el dominio que se consulta es ejemplo.com cuyo registro SPF contiene:

"v=spf1 include:ejemplo.net -all"

Si ejemplo.net no tiene registro SPF, el resultado es fail. Pero vamos a suponer que es el siguiente: "v=spf1 a -all"

Consultamos el registro A de ejemplo.net. Si aparece 1.2.3.4, entonces hay coincidencia. Si no aparece el include, falla en la coincidencia pero no se usa el valor all; sino que se sigue procesando el primer registro.

4.3.2. Extensin de los MecanismosSi la sintaxis de las anteriores directivas no son suficientemente expresivas para describir la poltica de nuestro dominio, es posible definir nuestros propios mecanismos. Sin embargo, hay que darse cuenta de que otros clientes, al hacer la comprobacin SPF, obtendrn un unknown si encuentran mecanismos que no son capaces de reconocer.

Por ejemplo: "v=spf1 habeas -all"

Podra indicar que el correo de un dominio sea enviado con las cabeceras de Habeas.

25




4.3.3. ModificadoresLos modificadores son opcionales. Un modificador puede aparecer solo una vez por grupo de directivas. Los modificadores desconocidos se ignoran.

redirect

redirect=domain

Las directivas SPF de domain reemplazan el set de directivas del presente dominio, es decir, se redirecciona la consulta SPF a otro dominio.

En el siguiente ejemplo, la IP del cliente es 1.2.3.4 y el domino que se consulta es ejemplo.com, cuyo registro SPF contiene:

"v=spf1 redirect=ejemplo.net"

Si ejemplo.net no tiene registro SPF, sera un error y el resultado seria unknown.Pero vamos a suponer que el registro SPF de ejemplo.net es:

"v=spf1 a -all"

Se consulta el registro A de ejemplo.net. Si aparece 1.2.3.4, devuelve allow. Si no hay coincidencia, se usa el valor de all.

exp

exp=domain

Si un receptor de SMTP rechaza un mensaje, puede incluir una explicacin. Alguien que publica SPF puede especificar el string de explicacin que van a ver los emisores. De esta forma, un ISP puede dirigir a los usuarios cuyos emails fueron rechazados, a una pgina que les de mas informacin.

26




4.4. Configurar los registros SPFConfigurar los registros SPF es tan sencillo como generar una entrada TXT en el DNS. 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 pblicas desde las que se enven correos SMTP, e inclusive las direcciones IP usadas por la red del servidor de correo.

Para rellenar el registro TXT podemos ayudarnos de las explicaciones del apartado 4.3 para editar el registro a mano, o tambin podemos usar el asistente de la pgina oficial para hacerlo de una forma mas sencilla y rpida: http://spf.pobox.com/wizard.html Para utilizar el asistente basta con colocar el nombre de nuestro dominio y pulsar sobre Begin (comenzar). Se introduce la informacin 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 botn Explain (explicar). Al finalizar, la cadena resultante es la que habr que introducir como registro TXT.

4.5. Publicar SPFNo es necesario publicar SPF para cada uno de los servidores SMTP de un dominio, tan solo para cada uno de los dominios que se quieren proteger. Si, por ejemplo, nuestro dominio se llama midominio.es y tenemos el subdominio www.midominio.es registrado, entonces deberamos publicar SPF para ambos. Esto es porque cada subdominio es un cliente diferente y cada cliente podra tener diferentes polticas.

As que tendremos que publicar un registro SPF para cada dominio o subdominio que tenga un registro A o MX. Lo sitios con registros A o MX con wildcard tambin deberan tener un registro SPF con wildcard de la forma: * IN TXT "v=spf1 -all"

27




No se pueden usar servidores DNS locales para publicar registros TXT para los dominios pblicos que tengamos en internet. Tendremos que usar el servidor DNS de nuestro dominio para que todo el mundo pueda tener acceso. Es fcil 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:

nslookup -type=txt dominio.com

O si estamos en Linux:

host t txt dominio.com

4.6. DesventajasSPF es tan solo un componente en una estrategia contra el spam. Puede que ayude a algunos, y puede que haga dao a otros. Mucha gente cree que SPF es una gran solucin porque ayuda a muchos mientras hace dao a pocos.

4.6.1. Usar un MTA favoritoUn problema que viene a la cabeza con SPF es que a mucha gente le gusta mantener sus cuentas de Yahoo, Hotmail u otros proveedores de correo, pero para enviar correo usan el servidor de su ISP (para no tener que usar webmail por ejemplo) manteniendo en el From su direccin de correo gratuita. Un email de estos no pasara la prueba de SPF. Sin embargo esto tiene solucin permitiendo al ISP hacer excepciones por cada usuario usando lel mecanismo exists ya mencionado. Los ISPs pueden resolver el problema ofreciendo SASL que lo soportan todos los MTAs y MUAs de hoy en da.

4.6.2. Los accesos pblicosLos cybercafs, los hoteles y los puntos accesos wireless no permiten a los usuarios enviar correo SMTP a travs del puerto 25. La razn es que no quieren tener problemas

28




legales. As que bloquean el puerto o ejecutan proxis transparentes. Esta practica no es para nada mala, de hecho solo los servidores de correo (MTA) deberan de comunicarse con otros a travs del puerto 25. Los usuarios que deseen enviar correo deberan hacerlo a travs del puerto de sumisin (TCP/587) de sus servidores de correo. Cualquier servidor puede actuar como MTA en el 25 y como MSA en el puerto 587 a la vez, y as enviar correo autenticado. De todas formas como SPF cada vez es mas usado, la necesidad de bloquear este tipo de puertos debera bajar.

4.6.3. Email ForwardingEl redireccionamiento es el gran problema de SPF. Mucha gente usa servicios de redireccionamiento tales como pobox.com, los cuales no funcionaran ya que al hacer forwarding, el sobre del emisor se mantiene, el servidor emisor no es realmente del dominio del mensaje, por esto el sistema receptor lo marcara como falso en la verificacin de SPF.

La direccin del emisor que esta en el sobre tambin se conoce como la direccin de remite. Si el mensaje no se puede enviar se devuelve a esta direccin. As que podemos deducir dos cosas de esto:

Primero, si los clientes quieren realmente usar su direccin de Pobox en el From del sobre, entonces tendrn que enviarlo a travs de Pobox.

Segundo, para soportar el forwarding, se propone el siguiente esquema:

[email protected] -> [email protected] -> [email protected]

[email protected] -> [email protected] from = [email protected] rcpt = [email protected]

[email protected] -> [email protected] from = bounce=joe#[email protected] rcpt = [email protected]

Si seas.upenn.edu rechaza el mensaje, el mensaje sera devuelto a pobox.com, que extrae la parte local especialmente formateada y reinyecta un mensaje de devolucin a [email protected] para [email protected] adjuntando la primera devolucin.

29




Si el mensaje es redirigido varias veces, se puede quitar la parte local o extenderla segn convenga. Si hay una capa estndar para redirigir correo, cada capa aade una direccin de correo como se muestra en el siguiente ejemplo:

[email protected] -> [email protected] -> [email protected] -> [email protected]

from = bounce=joe#aol.com=meng1#[email protected] rcpt = [email protected]

Uno de estos estndares que se ha propuesto es SRS (Sender Rewriting Scheme).

4.6.4. Objetores de concienciaPodemos pensar que siempre habr algunos dominios sin principios, malvados o simplemente incompetentes que pondrn todo Internet como su rango vlido de emisores de correo. Los spammers podran usar estos dominios y hacernos todo el spam que quisieran.

Los dominios que rechacen publicar SPF o permitan a cualquier direccin enviar correo no tendrn mas remedio que aceptar que tendrn una reputacin de spam mayor. Podemos rechazar deliberadamente cualquier email de estos dominios que han elegido ir en contra de la tendencia.

Solo porque las cosas han sido siempre de una forma no significa que sean buenas. Si SPF hubiera sido parte de SMTP y DNS desde sus comienzos, la posicin de estos objetores de conciencia sera muy diferente.

4.6.5. Dominios de usar y tirarLos spammers puede registrar un dominio de usar y tirar, publicar SPF y hacer un montn de spam. Luego desechar el dominio y volver a registrar otro. SPF necesita trabajar codo con codo con los sistemas de reputacin. Los dominios de usar y tirar pueden ser listados en listas negras que respondan en tiempo real a mtodos de filtrado automtico.

30




4.7. Detiene realmente el spam?A alto nivel se puede decir que nos estamos moviendo del paradigma de 'asumir que se es inocente hasta que se demuestre lo contrario' a 'asumir que se es culpable hasta que se demuestre lo contrario'.

Podemos pensar que los spammers siempre pueden conseguir dominios desechables, y es cierto, eso es otro tramo en la carrera contra el spam. Pero mientras tanto se pueden usar otras utilidades como listas negras automatizadas con las que podremos hacer varias cosas dependiendo de la situacin en la que se encuentren los emails recibidos:

Si el mensaje viene de un dominio con SPF y es vlido. En este caso si el dominio esta en la lista negra invalidaremos el mensaje, y si no esta en la lista se pasa a travs de mtodos de deteccin de spam y se aade en la lista negra en caso de dar positivo. Si el mensaje viene de un dominio sin SPF podemos pensar de dos formas diferentes. Hasta hace poco la mayora del correo legtimo entrara dentro de este grupo al ser algo totalmente nuevo el uso de SPF y se aplicaran filtros de contenido. Sin embargo a partir de ahora lo mas normal es que los dominios legtimos utilicen SPF, as que queda en manos del administrador la decisin de que hacer con los emails procedentes de dominios sin SPF. Por supuesto si el mensaje viene de un dominio con SPF y no es vlido entonces lo desecharemos automticamente porque es seguro que es falsa la identidad del emisor.

Si el volumen de spam decrece, las medidas legales y administrativas son mas efectivas. Si hay solo 10 spammers en el mundo, la Ley se puede centrar en atraparlos uno a uno. Pero si hay 10000 spammers, la Ley no har nada diciendo que es un problema social y que no hay suficientes recursos para afrontarlo.

Un spammer que registr un dominio y le implant SPF va a pasar las comprobaciones SPF como vlidas. Para detenerle, se puede hacer lo siguiente:

1. Si la empresa que le vendi el dominio coopera, podemos descubrir quien es el spammer y la empresa dejara de aceptarle como cliente. 2. Si la empresa del registro no coopera o si el spammer es el propio encargado del dominio, podemos apuntar en la lista negra todos los dominios de esta empresa.

31




3. Alternativamente, como el spam es ilegal, se puede obligar a la empresa del dominio a dar los datos de la persona que hizo el registro y demandarla directamente. 4. Si el spammer registr el dominio con informacin falsa, siempre se pueden obtener los datos a partir de la tarjeta de crdito. 5. Y si por un casual la tarjeta de crdito fue robada, entonces ya se pueden tomar otras medidas tradicionales contra el crimen.

32


DomainKeys


5. DomainKeysLa falsificacin de la direccin de correo de otra persona o compaa para que los usuarios confen y abran los mensajes es uno de los mas grandes problemas contra los que se enfrentan las comunidades de internet y las tecnologas anti-spam hoy en da. Sin una autenticacin del emisor, verificacin y control de la ruta, es imposible que los proveedores de correo puedan saber seguro si un mensaje es legtimo o una falsificacin.

DomainKeys es una propuesta tecnolgica que puede darnos una gran facilidad en el proceso de decisin de legitimidad de un email dando a los proveedores de correo un mecanismo para verificar el dominio de los emisores de correo y la integridad de los mensajes enviados (que no hayan sido modificados durante su transferencia). Una vez que el dominio pueda ser verificado, se puede comparar con el dominio usado por el emisor en la cabecera From: del email. Si es una falsificacin, entonces se trata de spam o un fraude, y puede ser eliminado sin molestar al usuario. Si no es una falsificacin, entonces el dominio es conocido, y se puede crear un perfil de reputacin para ese dominio.

Para compaas conocidas como bancos, servicios... el beneficio de la verificacin es todava mayor, ya que puede ayudar a proteger a sus usuarios de ataques fraudulentos, como es el hacerse pasar por trabajadores del dominio en el que los usuarios confan para pedir informacin personal (nmeros de tarjetas de crdito, contraseas...). Para estas compaas, proteger a sus usuarios de este tipo de emails significa proteccin de los clientes, satisfaccin de estos, costes reducidos del cuidado de los clientes y proteccin del nombre de la compaa.

Para los clientes, el soporte de la industria por las tecnologas de autenticacin de usuario significar que puedan volver a confiar en el correo electrnico, as este recuperara su imagen de ser una las mas poderosas herramientas de comunicacin.

5.1. EstandarizacinYahoo confa en hacer que DomainKeys se convierta en un estndar abierto en Internet, por eso ha enviado su propuesta a la IETF (Internet Engineering Task Force). Mientras tanto Yahoo ha establecido la licencia que se aplica a DomainKeys, la cual tambin ha sido enviada a la IETF.

33




5.2. FuncionamientoVamos a ver los cinco principales pasos en el funcionamiento de DomainKeys:

1) Instalacin. El dueo del dominio genera un par de claves, una pblica y una privada (se pueden utilizar mltiples pares). La clave pblica se publica en el DNS (A), y la clave privada se deja a disposicin nicamente de los servidores de correo saliente.

2) Firma. Cuando se enva un email, el sistema automticamente utiliza la clave privada para genera una firma digital del mensaje. Esta firma se agrega como cabecera al email, y ste se enva al destino (B).

3) Preparacin. El sistema receptor extrae de las cabeceras del mensaje la firma y el dominio del campo From. Y despus recoge la clave pblica del DNS del dominio extrado (C).

4) Verificacin. Luego la clave pblica del DNS se usa para verificar que la firma fue generada con la clave privada del mismo dominio. Esto demuestra que el mensaje fue realmente enviado por el dominio del campo From y que el mensaje no fue modificado durante su transferencia.Figura 5.1 Funcionamiento de DomainKeys

5) Entrega. El sistema de recepcin de correo aplica polticas locales basadas en los resultados obtenidos en el test de la firma. Si el dominio se verifica correctamente y otros tests anti-spam no lo identifican como malo, entonces el email se puede entregar al buzn del usuario receptor. Pero si el dominio no pasa la verificacin o simplemente no hay firma que verificar porque el emisor no utiliza DomainKeys, entonces el mensaje puede ser eliminado, marcado o puesto en cuarentena (D).

En general, Yahoo espera que DomainKeys sea verificado por los servidores de correo entrante. Sin embargo, los programas cliente de los usuarios finales tambin podran ser modificados para verificar las firmas y tomar las acciones que el propio usuario desee.

34


DomainKeys


En la figura 5.2 podemos ver mejor el funcionamiento de DomainKeys. Podemos ver como un usuario legtimo manda un mensaje a travs de Gmail, el MTA firma el mensaje con su clave privada y se lo manda al MTA destinatario. Este obtiene la clave pblica de Gmail a travs de su DNS y verifica con la clave que el mensaje fue firmado con la clave privada y solo esa, por lo que el mensaje es realmente de Gmail.

Si un spammer si mandar mensajes diciendo que proceden de Gmail, estos no seran firmados o como mucho los firmarian con cualquier firma. El destinatario hara lo mismo, obtendra la clave pblica de Gmail y al hacer la verificacin lo rechazara al no tener clave o demostrar que el mensaje no fue firmado con la clave privada.

Figura 5.2 Ejemplo de consulta de DomainKeys

5.3. Configurar los registros para DomainKeysDomainKeys utiliza registros TXT del DNS para definir la poltica de DomainKeys y las claves publicas para un dominio.

35




Hay dos tipos de registros DNS usados por DomainKeys, los registros de polticas y los registros donde se almacenan las claves publicas.

5.3.1 Registros de polticaUn nombre de dominio que usa DomainKeys debera tener un nico registro de poltica configurado. Este registro DNS es de tipo TXT y tiene _domainkey como prefijo del nombre de dominio. Por ejemplo _domainkey.ejemplo.com.

Estas son las posibles etiquetas que se pueden usar y su significado: Poltica de firmado de correo saliente o o=- significa que el dominio firma todos los mensajes. o=~ significa que el dominio firma solo algunos mensajes con DomainKeys, es la opcin por defecto. Direccin de correo para informes r Si esta presente, define la direccin de correo donde se enviarn los resultados de verificaciones invlidas. La intencin de esta etiqueta es usarla nicamente cuando se este probando la implementacin de DomainKeys. El contenido y la frecuencia de los informes ser definida en un documento por separado. Modo test t t=y significa que el dominio esta probando DomainKeys as que el correo que no este firmado o que no se pueda verificar se debe tratar igual que el correo verificado. Los sistemas destinatarios puede que quieran seguir los resultados del modo test para ayudar al emisor.

El modo test no se puede desactivar con la etiqueta t en el registro de polticas. La poltica no puede revertir el estado del modo test de un Selector. Notas que pueden ser de inters para las personas n Ningn programa interpreta esta etiqueta.

36


DomainKeys


Los servidores de correo receptores comprueban este registro de polticas para buscar que etiquetas esta utilizando el nombre de dominio emisor. En funcin de ello el servidor de correo que recibe el correo puede rechazar o marcar los mensajes no firmados de dicho nombre de dominio.

Para obtener el registro de poltica de un dominio se puede usar el comando dig de Unix: # dig _domainkey.yahoo.com TXT

Esta es la respuesta de Yahoo a la consulta: _domainkey.yahoo.com. 7200 IN TXT "t=y; o=~; n=http://antispam.yahoo.com/domainkeys"

5.3.2. Registros de claves pblicasSolo se puede configurar un registro de poltica por dominio, pero se pueden configurar mltiples registros de selector. El registro de selector guarda la clave pblica. Se pueden configurar mltiples selectores para usarlos en diferentes servidores, o se puede usar un nico selector para todos los mensajes salientes. Tambin se puede crear un selector que funcione nicamente con una direccin de correo concreta. Para cada selector debemos configurar un registro TXT diferente en el DNS. Este es un ejemplo del registro de selector:

miselector._domainkey IN TXT "k=rsa; p=AIGf ... AQAB"

Estas son las posibles etiquetas que se pueden utilizar: Granularidad de la clave g Si es un valor distinto de cero, este debe coincidir con la parte local de la direccin de destino. Esta etiqueta es opcional. La intencin de esta etiqueta es restringir que direcciones de correo pueden usar legtimamente este selector. Una email con una direccin de correo que no coincide con el valor de esta etiqueta dara negativo en la verificacin. Tipo de clave (por defecto es rsa) k Todos los servidores tanto los que firman como los que verifican soportan el tipo rsa.

37




Notas que pueden ser de inters para las personas n Ningn programa interpreta esta etiqueta. Es opcional. Clave publica p Codificada como un string en Base64. Un valor vaco significa que la clave ha sido anulada. Esta etiqueta es obligatoria. Modo test t t=y significa que el dominio esta probando DomainKeys y por lo tanto el correo sin verificar se debe tratar como el correo verificado. Esta etiqueta es opcional.

Un correo firmado con DomainKeys incluye una cabecera DomainKey Signature que contiene la firma criptogrfica y otra serie de campos como puede ser el selector (s). Por ejemplo:

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=pfc.datatrax.org; b=M2XYlSQIbeL3EoD9Jl0WGFhTs4vmXTEHI4mKarF10FLlGv9XIhfrD5NzKlnW/2qtVnKC029ud7y t5Wm6SedeKw== ;

Para que los servidores de correo receptores puedan verificar la firma primero tienen que obtener la clave publica para el selector correspondiente. En el ejemplo de arriba, esta almacenada en el registro TXT del DNS llamado beta._domainkey.pfc.datatrax.org. Este valor se obtiene al concatenar el valor del selector (s) con _domainkey y ste a su vez con el nombre de dominio (d), todos ellos separados por puntos.

5.4. VentajasDomainKeys es el arma de Yahoo contra el correo no solicitado, y la mas novedosa de entre este tipo de tecnologas. sta, adems de comprobar que el emisor quien dice ser es realmente quien es, garantiza que contenido del mensaje no ha sido alterado durante su transmisin. Para hacer esto, cada servidor de correo emisor firma los mensajes usando un certificado digital. Los receptores podran rechazar los mensajes que no coincidieran con un valor almacenado en un registro publico del dominio.

38


DomainKeys


Para conocer mejor la propuesta de Yahoo, vamos a explicar mas a fondo sus ventajas:

Autenticacin real El emisor original del correo es autenticado, en lugar del ultimo servidor que toc el mensaje. Con Sender ID lo que se comprobaba era la direccin IP del servidor de correo que manda el mensaje. Con DomainKeys debe coincidir la firma digital del mensaje recibido.

El redireccionamiento (email forwarding) funciona El redireccionamiento de correo es algo que siempre se ha hecho con gran frecuencia y se piensa que cualquier especificacin de autenticacin que se implante como estndar debe permitir que se siga utilizando lo que se ha utilizado hasta ahora. A diferencia de SPF y Sender ID que tienen algunos problemas con el correo redireccionado de un dominio a otro, DomainKeys no crea ninguna interferencia con esto. Por este motivo, DomainKeys tiene una gran aceptacin.

La reputacin Comprobando que un mensaje viene de una direccin IP conocida no eliminar el spam o el fraude. Los spammers pueden comprar dominios que sean asequibles y enviar spam que realmente viene de ese dominio. An muchos consumidores podran ser engaados con correo fraudulento. La autenticacin de la fuente de los mensajes de correo se debe combinar con un sistema de reputacin que obtenga puntos positivos para emisores legtimos y puntos negativos para spammers. Yahoo lleva mas de dos aos usando un servicio de este estilo llamado SpamGuard que segn dicen es un buen sistema para filtrar los emisores malos.

5.5. InconvenientesAlgo que ha sido criticado en DomainKeys es que la firma digital que hacen los servidores de correo saliente requiere mucho mas tiempo de CPU que el simple hecho de enviar mensajes sin firmar.

Los testadores de Sendmail establecieron que el hecho de firmar mensajes de tamao medio reducira el potencial de un servidor de correo en un 11,5%. Sin embargo la aplicacin

39




de DomainKeys podra fcilmente devolver el potencial consumido, mas un extra, gracias a la eliminacin del volumen de spam que los servidores de una compaa tienen que analizar a diario. Por este motivo, Sendmail asegura que DomainKeys demostrar ser mucho mas eficiente que los actuales mtodos de filtrado y evaluado de correo.

5.6. Otras caractersticasDomainKeys no cifra los mensajes, tan solo aade una cabecera con una firma digital de los mensajes.

DomainKeys firma el mensaje entero para permitir al servidor que lo recibe verificar que el mensaje no ha sido alterado durante su transmisin. Firmando las cabeceras y el cuerpo, DomainKeys imposibilita el hecho de reusar partes de un mensaje de una fuente segura para engaar a los usuarios hacindoles creer que el email es de esa fuente. Por ejemplo, una persona que quiere engaar a los clientes de un banco podra usar las cabeceras de los mensajes de este banco (incluida la firma de DomainKeys) y aadir al cuerpo del mensaje lo que a l le interese. Afortunadamente, el servidor de correo que reciba tales mensajes, los marcar como fraudulentos al no coincidir la firma de DomainKeys con el contenido del mensaje, ya que la firma se realiz antes de ser modificado.

La tecnologa utilizada para generar las claves es RSA. La longitud de estas la decide el dueo del dominio, pudiendo ser estas de 512, 768, 1024,1536 y 2048. El valor recomendado es el de 1024 bits.

Adems DomainKeys no necesita una Autoridad de Certificacin (CA). Como DomainKeys utiliza DNS como sistema de distribucin de la clave pblica, y como solo el dueo del dominio puede publicar algo en su DNS, los usuarios externos saben que la clave pblica expuesta es realmente de ese dominio. No se necesitan CA para verificar el dueo de la clave, su presencia en el DNS del dominio es la verificacin.

Sin embargo, es posible que las CA lleguen a ser un aadido de gran valor a la solucin de DomainKeys para agregar un nivel superior de seguridad.

DomainKeys permite publicar mltiples claves a la vez en el DNS. Esto permite a las compaas usar diferentes pares de claves para los distintos servidores de correo que tengan y

40


DomainKeys


adems anular o reemplazar claves segn convenga. De hecho, el dueo de un dominio puede anular una clave pblica y pasar a usar un nuevo par de claves al mismo tiempo.

Antes de borrar una clave del DNS, se debe poner una nueva en el registro DNS y el MTA debera empezar a usarla. Despus de que todos los MTAs han dejado de usar la clave vieja, entonces sta se puede borrar de los registros DNS. No obstante, se recomienda dejarla un mnimo de 4 das (aunque no se este usando) por si hay mensajes en transito que deban ser verificados.

Las listas de correo que no cambien el contenido de los mensajes, ni reorganicen ni aadan cabeceras, sern totalmente compatibles con DomainKeys sin necesidad de hacer ningn cambio. Las listas de correo que realicen cambios deberan re-firmar los mensajes con su propia clave privada.

5.7. MTAs con soporte para DomainKeysSendmail ha sacado una implementacin de DomainKeys para las dos versiones de su MTA: la comercial y la gratuita. Existen un par de parches para Qmail, una versin de Exim y un plugin para qpsmtpd. CERN, los creadores de la WWW han sacado una librera de C# para MX Exchange 2003. Tambin tienen versiones para DomainKeys PowerMTA, acSMTP, XMServer, Ecelerity, StrongMail y MDaemon MTA. Recientemente tambin ha sido creado un filtro DomainKeys para Postfix. Finalmente, Yahoo ha puesto a disposicin de todo el mundo una referencia de la implementacin en cdigo abierto de DomainKeys que puede ser usada con otros MTAs.

5.8. Detiene realmente el spam?Hay varias formas para detener el spam. Primero, DomainKeys permite borrar o poner en cuarentena los emails recibidos sin firmar que vienen de dominios que se sabe que siempre firman sus emails. En segundo lugar, la habilidad para verificar el dominio del emisor permitir a los proveedores de servicios de correo empezar a construir bases de datos de reputacin que pueden ser compartidas con la comunidad y tambin aplicadas a las polticas anti-spam. Por ejemplo, un ISP podra compartir su ratio de spam/correo legtimo para el dominio

41




www.ejemplo.com con otros ISPs que

tal vez no hayan construido informacin sobre la

credibilidad del correo procedente de www.ejemplo.com. Por ltimo, eliminando el correo con procedencia de direcciones falsificadas, podemos devolver a los servidores de correo electrnico la capacidad de seguir la ruta de los mensajes. Y como a los spammers no les gusta ser localizados, sern forzados a hacer spam nicamente a compaas que no usen soluciones anti-spam.

Los dominios que sean susceptibles de ser falsificados, pueden firmar todos sus emails y decir a todo el mundo su poltica de forma que los proveedores de servicios de correo puedan borrar cualquier mensaje que diga ser procedente de ese dominio y no este firmado. Por ejemplo, si la compaa www.ejemplo.com firma todos sus mensajes con DomainKeys, Yahoo puede aadir un filtro en su sistema SpamGuard que elimine cualquier mensaje no firmado o firmado incorrectamente que diga ser del dominio www.ejemplo.com, protegiendo as a todos los clientes de esa compaa de los ataques de fraude.

Si los spammers llegasen a firmar su correo, facilitaran a la comunidad de Internet las tareas contra el spam. En este caso tendran sentido los sistemas de reputacin. Eliminando la duda de si un mensaje proviene realmente de un dominio facilita mucho las soluciones antispam como ya se ha dicho en el tema de SPF.

42


Instalacin de un servidor de correo


6. Instalacin de un servidor de correoEn este tema vamos a mostrar como instalar un servidor de correo en Linux, concretamente Qmail porque tiene soporte tanto para SPF como DomainKeys, adems de ser uno de los servidores mas potentes y populares.

6.1. Instalacin de QmailEste proceso es algo extenso, pero en general involucra tareas muy sencillas que difcilmente podran fallar si se realizan con cuidado.

El primer paso es ir a la pagina de Qmail [www.qmail.org] y descargar el cdigo fuente de la ultima versin de Qmail. En el momento de escribir esta gua la ultima versin era la 1.03 [http://cr.yp.to/software/qmail-1.03.tar.gz].

Una vez descargado procederemos a su descompresin y nos situaremos dentro del directorio generado:

# tar xzvf qmail-1.03.tar.gz # cd qmail-1.03

6.1.1. Crear el directorio de qmailLo siguiente que debemos hacer es crear el directorio de trabajo para qmail. La sugerencia de los creadores es el directorio /var/qmail (hay pocos motivos para cambiarlo.) As que el administrador ejecutar algo como:

# mkdir /var/qmail

Si se desea emplear otra ubicacin, esta se debe registrar en el archivo conf-qmail que se encuentra dentro de la carpeta qmail-1.03 que descomprimimos anteriormente. En lo que sigue, asumiremos la ruta arriba indicada.

43




Contenido de conf-qmail:

/var/qmail This is the qmail home directory. It must be a local directory, not shared among machines. This is where qmail queues all mail messages. The queue (except for bounce message contents) is crashproof, if the filesystem guarantees that single-byte writes are atomic and that directory operations are synchronous. These guarantees are provided by fixed-block filesystems such as UFS and by journaling filesystems. Under Linux, make sure that all mail-handling filesystems are mounted with synchronous metadata.

6.1.2. Usuarios para qmailQmail requiere la creacin de diversos usuarios para su correcta ejecucin. Estos son: alias, qmaild, qmaill, qmailp, qmailq, qmailr, y qmails. Si por algn motivo no se puede emplear estos pseudo-usuarios (por ejemplo, si algn usuario real coincide con los mencionados), entonces se deber especificar los nuevos valores en el archivo conf-users. Igualmente se requiere de la creacin de dos grupos (especificados en el archivo conf-groups.)

Para crear los usuarios y grupos usar: # groupadd nofiles # useradd -g nofiles -d /var/qmail/alias alias # useradd -g nofiles -d /var/qmail qmaild # useradd -g nofiles -d /var/qmail qmaill # useradd -g nofiles -d /var/qmail qmailp # groupadd qmail # useradd -g qmail -d /var/qmail qmailq # useradd -g qmail -d /var/qmail qmailr # useradd -g qmail -d /var/qmail qmails

44




Contenido de conf-users: Alias qmaild qmaill root qmailp qmailq qmailr qmails The qmail system is heavily partitioned for security; it does almost nothing as root. The first eight lines of this file are the alias user, the daemon user, the log user, the owner of miscellaneous files such as binaries, the passwd user, the queue user, the remote user, and the send user.

Contenido de conf-groups: qmail nofiles These are the qmail groups. The second group should not have access to any files, but it must be usable for processes; this requirement excludes the ``nogroup'' and ``nobody'' groups on many systems.

6.1.3. Compilar y configurar el directorio de trabajoEn este paso se generan los ejecutables de qmail y se prepara el directorio de trabajo de qmail:

# make setup check

45




6.1.4. Especificar el nombre del hostLuego se deber especificar el nombre de nuestro host (incluyendo el dominio completo) mediante el comando config-fast del siguiente modo:

# ./config-fast PFC-Correo.pfc.datatrax.org

6.1.5. Establecer los "alias" del sistemaEn qmail, el correo para los usuarios especiales postmaster, MAILER-DAEMON y root, es redirigido hacia el pseudo-usuario alias. Esto requiere de la existencia de ciertos archivos en el "home directory" del pseudo-usuario alias:

# (cd ~alias; touch .qmail-postmaster \ .qmail-mailer-daemon .qmail-root) # chmod 644 ~alias/.qmail*

6.1.6. Especificar el agente de procesamiento de correoEl correo dirigido a los usuarios locales debe ser almacenado en algn archivo o directorio (el mailbox.) Esto normalmente NO lo realiza el MTA, sino que lo delega a un programa auxiliar. Sendmail normalmente emplea a procmail para este fin. A fin de realizar una rpida puesta a punto, mantendremos el uso de procmail (luego veremos el agente alternativo que proporciona qmail llamado qmail-local.) Para esto tan slo es necesario efectuar el siguiente comando: # cp /var/qmail/boot/proc /var/qmail/rc

Sin embargo, procmail en este caso ser ejecutado mediante un usuario no privilegiado, por lo que es menester cambiar los permisos del directorio de los mailbox (que se mantendr en /var/spool/mail.). Para ello debemos ejecutar: # chmod 1777 /var/spool/mail

46




6.1.7. Instalar el "reemplazo" de sendmailDiversos programas asumen la existencia de sendmail y lo invocan ciegamente. Por esto, qmail proporciona un "reemplazo" bsico para sendmail, a fin de mantener operativas a las aplicaciones mencionadas.

# ln -s /var/qmail/bin/sendmail /usr/lib/sendmail # ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail

6.1.8. Qmail debe aceptar correo para el dominioCuando se instala qmail, ste asume que slo debe aceptar mensajes destinados a su propio host; en nuestro caso, mensajes de la forma "[email protected]". Como las direcciones ahora son diferentes (queremos que sean de la forma

[email protected]), hay que configurar qmail para que las acepte. Para esto slo se debe aadir "pfc.datatrax.org" (la parte de "host" de las direcciones electrnicas) a los archivos /var/qmail/control/rcpthosts y /var/qmail/control/locals:

PFC-Correo.pfc.datatrax.org pfc.datatrax.org

El archivo rcpthosts permite que qmail-smtp acepte los mensajes con el host especificado, en tanto locals permite que qmail-send efecte el reparto a un usuario local (en su mailbox.)

6.1.9. Instalar los manualesQmail proporciona pginas de manual para diversas utilidades. Estas se instalan en /var/qmail/man. Sin embargo, el sistema "man" debe ser configurado para acceder a ste.

Para esto, aada el directorio de los manuales mediante el la directiva MANPATH en el archivo /etc/manpath.config (este archivo puede variar en funcin de la distribucin que utilicemos):

47




... MANDATORY_MANPATH MANDATORY_MANPATH MANDATORY_MANPATH MANDATORY_MANPATH /usr/man /usr/share/man /usr/X11R6/man /usr/local/man

#aadido para qmail MANDATORY_MANPATH ... Para probar su correcto funcionamiento ejecutar man qmail-send por ejemplo. /var/qmail/man

6.2. Instalacin de tcpserverQmail necesita de un mecanismo que lance el demonio qmail-smtpd cada vez que llega un intento de conexin SMTP del exterior del mailserver. Esto se puede hacer de diversas maneras; sin embargo, los creadores recomiendan el uso del programa tcpserver que est disponible como parte del paquete ucspi-tcp de D.J. Bernstein. Es posible configurar inetd para este fin e incluso xinetd. Nosotros utilizaremos tcpserver porque no requiere mucho trabajo hacerlo funcionar y se obtiene un rendimiento superior.

6.2.1. Descargar y descomprimir ucspi-tcpDescargar la ultima versin del paquete de la web de ucspi-tcp que se encuentra en http://cr.yp.to/ucspi-tcp.html. Este viene en un archivo TAR comprimido. En mi caso, ucspi-tcp-0.88.tar.gz.

Despus deberemos descomprimirlo donde nos parezca (despus lo podr eliminar) mediante un comando como: # tar xvzf ucspi-tcp-0.88.tar.gz .... se crea el directorio ucspi-tcp-0.88 .....

48




6.2.2. Compilar e instalar tcpserverProcederemos ahora a compilar los programas del paquete. Para esto ejecutamos:

# cd ucspi-tcp-0.88 # make Y tras unos momentos tendremos una serie de ejecutables en el mismo directorio. Procedemos a copiar los ejecutables tcpserver y tcprules a un directorio en el PATH, como /usr/sbin o /usr/local/bin:

# cp tcpserver tcprules /usr/sbin Slo estos dos ejecutables sern necesarios, por lo que puede eliminar el directorio de ucspi-tcp-0.88.

6.3. Configurar el inicio automtico de QmailAhora vamos a configurar el sistema para que siempre se ejecute qmail al reiniciarse el computador. Para ello deberemos averiguar el UID y el GID del usuario "qmaild" y del grupo "nofiles" respectivamente: # id qmaild uid=1001(qmaild) gid=101(nofiles) groups=101(nofiles) El nmero 1001 es el UID del usuario "qmaild", y el nmero asociado al grupo "nofiles" es 101. Estos valores son distintos segn el sistema.

Una vez obtenidos estos datos crearemos un script para que se ejecute de inicio. En mi caso uso Debian, en otras distribuciones puede que vare un poco. Lo primero que hago es obtener el runlevel actual: # runlevel N 2

49




En este caso el runlevel es el 2, por lo que colocare mi script de inicio en /etc/rc2.d/ y le dar el nombre S20qmail. El numero 20 representa la prioridad,

Implementation of an anti-spam solution with SPF and DomainKeys

Documents

Transcript of Implementation of an anti-spam solution with SPF and DomainKeys