TEG - cicore - Universidad Central de Venezuela

Universidad Central de Venezuela
Facultad de Ciencias
Escuela de Computación
Laboratorio de Comunicación y Redes
Implementación de un sistema
para el manejo de correo
electrónico con autenticación
centralizada basada en
servicios de directorio
Trabajo Especial de Grado
presentado ante la ilustre
Universidad Central de Venezuela
por el Bachiller
Alejandro Enrique Brito Monedero
para optar al título de
Licenciado en Computación
Prof. Eric Gamess
Caracas, Noviembre / 2007
3
Universidad Central de Venezuela
Facultad de Ciencias
Escuela de Computación
ACTA DEL VEREDICTO
Quienes suscriben, Miembros del Jurado designados por el Consejo de Escuela
de Computación, para examinar el Trabajo Especial de Grado, presentado por el
Bachiller Alejandro Enrique Brito Monedero, C.I. 16.672.505, con el título
“Implementación de un sistema para el manejo de correo electrónico con
autenticación centralizada basada en servicios de directorio”, a los fines de
cumplir con el requisito legal para optar al título de Licenciado en Computación,
dejan constancia de lo siguiente:
Leído como fue dicho trabajo por cada uno de los Miembros del Jurado, éstos
fijaron el día 2 de noviembre de 2007, para que su autor lo defendiera en forma
pública, lo cual éste realizó, mediante una exposición oral de su contenido, y luego
respondió satisfactoriamente a las preguntas que le fueron formuladas por el
Jurado, todo ello conforme a lo dispuesto en la Ley de Universidades y demás
normativas vigentes de la Universidad Central de Venezuela.
Finalizada la defensa pública del Trabajo Especial de Grado, el jurado decidió
APROBARLO.
Firmas del Tutor y Jurados Examinadores:
Prof. Eric Gamess
(Tutor)
Prof. Claudia Fuenmayor
(Jurado Principal)
Prof. Néstor Dávila
(Jurado Principal)
5
DEDICATORIA
A Dios, a mis abuelos María de los Angeles y Pedro, a mi madre, a mi prima
Cathy, a mis tías Isabel y Conchita, a mi hermano Gabo, a mis primos Daniel,
Silvia y Fabi y al resto de mi familia, a mis amigos Zaire, Paul, Fernando, Gabriel,
Hans y a las personas que me han apoyado, y a mi persona.
7
AGRADECIMIENTOS
A Dios por la capacidad que me dio para resolver los problemas con los que me
he encontrado y las oportunidades que me ha dado en la vida.
A mi mamá y a toda mi familia por todo el apoyo brindado para realizar y culminar
éste y muchos otros proyectos.
A mis amigos por la ayuda y apoyo que me dieron.
A mi tutor, Prof. Eric Gamess, por proporcionarme herramientas para
desempeñarme mejor como profesional y todo el apoyo que me dio en la carrera.
A los profesores que tuve a lo largo de mis estudios, en particular a los profesores
Ana Morales y David Pérez por la ayuda que me prestaron.
A la UCV, por darme la oportunidad de formarme como persona y profesional en
sus instalaciones.
Al IGVSB, por darme la oportunidad de realizar este trabajo en sus instalaciones y
la confianza que depositaron en mí en los momentos difíciles. En particular al
Coordinador de Tecnología y Sistemas Ing. Amador Medina, al personal de redes
y muy especialmente a Zaire Hernández por todo su apoyo.
9
UNIVERSIDAD CENTRAL DE VENEZUELA
FACULTAD DE CIENCIAS
ESCUELA DE COMPUTACIÓN
Implementación de un sistema para el manejo de correo
electrónico con autenticación centralizada basada en servicios de
directorio
Autor: Alejandro Enrique Brito Monedero
Tutor: Prof. Eric Gamess
RESUMEN
El presente Trabajo Especial de Grado está enfocado hacia la implementación de
un sistema para el manejo de correo electrónico en ambientes empresariales y su
aplicación, utilizando programas con licencias libres. El objetivo del trabajo es
proponer una solución que permita a cualquier organismo, tener un sistema de
correo electrónico acorde con sus necesidades, tomando en cuenta criterios como
el fácil acceso desde lugares remotos, la seguridad, el control centralizado de los
usuarios, y el filtrado de mensajes no deseados.
El proyecto está compuesto por un proceso de investigación sobre los
componentes necesarios para implementar un sistema para el manejo de correo
electrónico y el método a seguir para la implementación del mismo en un
organismo. Como caso de estudio, se seleccionó al Instituto Geográfico de
Venezuela Simón Bolívar (IGVSB). El sistema instanciado en dicho Instituto quedó
conformado por el servidor de correo de código abierto (Postfix) que cumple con
los requerimientos del IGVSB en los aspectos de seguridad y eficiencia. Se utilizó
el programa Dovecot y se configuró como un servidor IMAP, para permitir a los
usuarios acceder a sus correos. Así mismo, para mantener un control centralizado
de los usuarios y la libreta de direcciones del Instituto, se implementó un servidor
de directorio LDAP, utilizando el programa OpenLDAP. Todos estos sistemas se
integraron para proporcionar un servicio de correo acorde a las necesidades y
propósitos del IGVSB y en concordancia con los lineamientos del Decreto Nº
3.390.
En el caso del IGVSB, se logró obtener una solución que proporciona beneficios
adicionales, como son: control de los buzones mediante cuotas, control sobre el
personal que puede enviar y recibir correos electrónicos de sitios externos al
Instituto, mensajería instantánea interna y groupware.
Palabras claves: E-mail, Software Libre, Servicios de Directorios, SMTP, IMAP,
LDAP.
TABLA DE CONTENIDO
1
INTRODUCCIÓN ................................................................................................................. 15
1.1
Planteamiento del Problema ....................................................................................... 16
1.2
Objetivos de la Investigación ....................................................................................... 16
1.2.1
1.2.2
Objetivo general .................................................................................................................... 16
Objetivos específicos ............................................................................................................. 16
1.3
Justificación ................................................................................................................. 17
1.4
Alcance ........................................................................................................................ 17
1.5
Distribución del Documento ........................................................................................ 17
2
MARCO TEÓRICO .............................................................................................................. 19
2.1
Correo Electrónico ....................................................................................................... 19
2.1.1
2.1.2
2.2
2.3
2.3.1
3
3.2
3.2.1
3.2.2
3.2.3
3.2.4
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.5
4.5.1
4.5.2
Correo Spam ......................................................................................................................... 43
Métodos utilizados por el spam ............................................................................................. 44
Métodos para enviar correo spam ......................................................................................... 44
Técnicas para engañar a los filtros de correo ....................................................................... 45
Técnicas Anti-Spam .............................................................................................................. 45
Fases del método ........................................................................................................ 47
Recopilación de requerimientos ............................................................................................ 47
Definición de los roles ........................................................................................................... 48
Criterios para la selección del software ................................................................................. 48
Procedimiento para la implementación ................................................................................. 50
Unidad de almacenamiento para los buzones de los usuarios ............................................. 56
Servidor de correo e IMAP .................................................................................................... 56
Servidor de directorio ............................................................................................................ 57
Programas que Integran el Sistema ............................................................................ 58
Sistema operativo .................................................................................................................. 58
Sistema de archivos .............................................................................................................. 60
Servidor SMTP ...................................................................................................................... 63
Servidor IMAP ....................................................................................................................... 65
Servicio de directorio ............................................................................................................. 67
Implementación ........................................................................................................... 68
Configuración del servidor de directorio ................................................................................ 68
Configuración del servidor de correo ..................................................................................... 71
PRUEBAS ........................................................................................................................... 79
5.1
Escenario .................................................................................................................... 79
5.1.1
5.2
5.2.1
5.2.2
5.3
5.3.1
5.3.2
6
LDAP ..................................................................................................................................... 36
CASO DE ESTUDIO ............................................................................................................ 53
4.1
Instituto Geográfico de Venezuela Simón Bolívar (IGVSB) ........................................ 53
4.2
Requerimientos ........................................................................................................... 55
4.3
Equipos de Hardware que Integraran el Sistema ........................................................ 56
4.3.1
4.3.2
4.3.3
5
Funcionamiento de la Infraestructura de Correo Electrónico ...................................... 32
Servicio de Directorio .................................................................................................. 33
MÉTODO PARA IMPLEMENTAR EL SISTEMA ................................................................. 43
3.1
Definiciones ................................................................................................................. 43
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
4
Elementos .............................................................................................................................. 19
Protocolos .............................................................................................................................. 23
Configuración de los clientes de correo electrónico .............................................................. 79
Medición del Desempeño del Servidor de Correo y Directorio ................................... 80
Servidor de correo electrónico ............................................................................................... 81
Servidor de directorio ............................................................................................................ 83
Interpretación de los Resultados ................................................................................. 83
Servidor de correo electrónico ............................................................................................... 83
Servidor de directorio ............................................................................................................ 84
CONCLUSIONES ................................................................................................................ 85
6.1
Recomendaciones ....................................................................................................... 85
7
BIBLIOGRAFÍA ................................................................................................................... 87
ÍNDICE DE TABLAS
Tabla 2.1: Los 5 servidores de correo más populares para agosto de 2007 .................................... 21
Tabla 2.2: Órdenes básicas del protocolo SMTP ............................................................................. 25
Tabla 2.3: Códigos de respuesta en el protocolo SMTP .................................................................. 25
Tabla 2.4: Comandos del protocolo POP3 ....................................................................................... 28
Tabla 4.1: Comparación de costos en la puesta en marcha inicial de Windows vs. Linux ............... 59
Tabla 4.2: Comparación de varios servidores SMTP que son software libre ................................... 63
Tabla 4.3: Comparación de varios servidores IMAP que son software libre .................................... 66
ÍNDICE DE FIGURAS
Figura 2.1 Ejemplos de direcciones de correo electrónico ............................................................... 20
Figura 2.2: Mozilla Thunderbird ........................................................................................................ 22
Figura 2.3: SquirrelMail ..................................................................................................................... 23
Figura 2.4: Ejemplo de una conexión SMTP .................................................................................... 26
Figura 2.5: Ejemplo de una conexión POP3 ..................................................................................... 29
Figura 2.6: Proceso para enviar un correo electrónico ..................................................................... 33
Figura 2.7: Entrada en formato LDIF ................................................................................................ 39
Figura 2.8: Definición del objectClass País ...................................................................................... 40
Figura 2.9: Ejemplo de la estructura de nombres que puede tener un directorio LDAP en una
organización ...................................................................................................................................... 41
Figura 3.1: Sistema de manejo de correos electrónicos con servicio de autenticación.................... 43
Figura 4.1: Unidad Promise Vtrak. 15110 ......................................................................................... 56
Figura 4.2: HP Proliant DL360 G3 .................................................................................................... 57
Figura 4.3: IBM xSeries 336 ............................................................................................................. 57
Figura 4.4: Arquitectura de Postfix para recibir correos electrónicos ............................................... 65
Figura 4.5: Arquitectura de Postfix para reenviar / entregar correos electrónicos ............................ 65
Figura 4.6: Distribución del Sistema en el IGVSB ............................................................................ 68
Figura 4.7: Estructura del árbol de directorio implementada ............................................................ 69
Figura 4.8: Pasos para instalar y configurar el servidor LDAP ......................................................... 69
Figura 4.9: Configuración hecha con debconf para slapd ................................................................ 69
Figura 4.10: Configuración para el servidor de LDAP ...................................................................... 70
Figura 4.11: Ejemplo de archivo LDIF utilizado para cargar los datos ............................................. 71
Figura 4.12: Comandos para configurar el servidor de correo ......................................................... 72
Figura 4.13: Configuración para el manejo de cuotas y el sistema de archivos ............................... 73
Figura 4.14: Configuración de Postfix con debconf .......................................................................... 73
Figura 4.15: Cambios en el archivo de configuración /etc/postfix/main.cf ........................................ 74
Figura 4.16: Parámetros de búsqueda para obtener la lista de usuarios locales mediante LDAP ... 75
Figura 4.17: Lista de control del envío de correos electrónicos ........................................................ 75
Figura 4.18: Cambios para realizar autenticación mediante LDAP .................................................. 76
Figura 4.19: Configuración del servidor IMAP .................................................................................. 77
Figura 5.1: Configuración del cliente de correo especificando el servidor SMTP e IMAP ................ 79
Figura 5.2: Configuración del cliente de correo electrónico para utilizar IMAP sobre SSL ............... 80
Figura 5.3: Salida del comando df ejecutado en el servidor de correo ............................................. 81
Figura 5.4: Salida del comando repquota en el servidor de correo .................................................. 81
Figura 5.5: Salida del comando vmstat ejecutado en el servidor de correo ..................................... 82
Figura 5.6: Salida del comando uptime en el servidor de correo ...................................................... 82
Figura 5.7: Parte del archivo mail.log ............................................................................................... 82
Figura 5.8: Salida del comando vmstat en el servidor de directorio ................................................. 83
Figura 5.9: Salida del comando uptime en el servidor de directorio ................................................. 83
Capítulo 1: Introducción
15
1 INTRODUCCIÓN
La invención del correo electrónico ha tenido un impacto grande en el mundo y ha
logrado que el Internet sea, hoy en día, un medio de comunicación sumamente
importante para nuestra sociedad. Su influencia se ha hecho sentir en el área
empresarial y, es por ello que en los organismos, el correo electrónico se ha
convertido en un medio de comunicación ampliamente utilizado, transformando
profundamente la forma como se realizan las comunicaciones, tanto interna como
externamente. Todo esto, gracias a su facilidad de uso, a su parecido con los
métodos de comunicación tradicional, como la correspondencia, y, a las ventajas
que ofrece a los usuarios, tales como: permitir comunicaciones casi instantáneas
sin importar las ubicaciones geográficas y aliviar problemas de logística en la
planificación de reuniones.
El crecimiento masivo en la utilización del correo electrónico ha sido posible, en
parte, gracias al desarrollo de protocolos de comunicación que definen las reglas
para ello. Entre los protocolos desarrollados para este fin, están: SMTP (Simple
Mail Transfer Protocol) [1], IMAP (Internet Message Access Protocol) [2] y POP3
(Post Office Protocol Version 3) [3], los cuales permiten el manejo de los correos
electrónicos, tanto en las etapas de envío como en la recepción de los mismos, sin
importar los sistemas utilizados. La flexibilidad de estos protocolos ha permitido la
evolución del poder del correo electrónico, pasando desde enviar simples
mensajes de texto, hasta la capacidad de enviar imágenes y archivos adjuntos.
Ahora bien, para cubrir las necesidades de los organismos que deseaban tener
una infraestructura que les permitiera el manejo de los correos electrónicos,
compañías como IBM [4] y Microsoft [5] desarrollaron un conjunto de aplicaciones
que cumplían con este objetivo; pero, estas soluciones presentan la desventaja de
ser muy costosas para dichos organismos.
Por otro lado, por la masificación en el uso de los correos electrónicos y al auge
del software libre de una excelente calidad; los organismos, comenzaron a tomarlo
en cuenta para implementar sus infraestructuras de manejo de correos
electrónicos.
Es por ello y dado que muchos organismos carecen de dicha infraestructura, nace
la necesidad de crear un método para implementar un sistema que sea software
libre; no solamente para satisfacer sus propósitos, sino también para suplir sus
necesidades y carencias.
En función de lo antes expuesto, surge el planteamiento de utilizar sistemas en
software libre, para implementar una infraestructura de manejo de correos
electrónicos en los organismos.
Capítulo 1: Introducción
16
1.1 Planteamiento del Problema
El correo electrónico es una de las herramientas de comunicación más
importantes con la que cuentan los organismos en la actualidad. Pero, por cuanto
este mercado ha sido dominado principalmente por compañías privadas, las
cuales comercializan su mercancía a un costo muy elevado y además hay que
obtener los componentes que sean compatibles con dicho sistema, esto ha
imposibilitado que los organismos adquieran su producto, a pesar de ser de una
excelente calidad.
Ahora bien, dado que en la actualidad existen numerosos programas en software
libre que permiten implementar una infraestructura para el manejo de correos
electrónicos, surge la siguiente interrogante: ¿Es posible implementar un
sistema para el manejo de correo electrónico integrado con un servicio de
directorio que utilice tecnologías abiertas y permita la interoperabilidad con
distintos programas utilizando protocolos estándares?
Con base a lo anteriormente expuesto, se plantea la implementación de una
estructura para el manejo de correos electrónicos que estén conformados por un
servidor SMTP, un servidor IMAP y un servidor LDAP (Lightweight Directory
Access Protocol) [6], que sea segura y fácil de administrar.
1.2 Objetivos de la Investigación
1.2.1 Objetivo general
Diseñar e implementar un sistema para el manejo de correo electrónico que utilice
los protocolos de SMTP, IMAP y LDAP, basada en software libre.
1.2.2 Objetivos específicos
Ø Seleccionar y configurar un servidor SMTP, que permita el envío de correos
electrónicos y cumpla con los requisitos de robustez y seguridad exigidos.
Ø Seleccionar y configurar un servidor IMAP, que permita que los usuarios
puedan acceder a sus correos, cumpliendo con el requisito de que los
correos estén almacenados en el servidor.
Capítulo 1: Introducción
17
Ø Implementar un servicio de directorio LDAP, que permita manejar de
manera centralizada la autenticación de los usuarios y la libreta de
direcciones de los organismos.
1.3 Justificación
El Trabajo Especial de Grado planteado viene a suplir una necesidad que se
presenta en organismos del Estado, aunado al hecho de que éstos deben dar
cumplimiento al Decreto Nº 3.390 [7], que establece la obligatoriedad o prioridad
de utilizar software libre. De esta manera, un organismo podrá contar con una
plataforma para el manejo de los correos electrónicos basada en software libre y
estándares abiertos, que le permitirá alcanzar la meta de proveer un servicio de
correo electrónico estable y eficiente para el personal que labora en el mismo.
Igualmente, con el esquema planteado, también se dará cumplimiento al Decreto
N° 3.390, que establece que los organismos públicos deben darle prioridad al
empleo de software libre.
Otros de los beneficios al implementar esta infraestructura es que también se
podrá utilizar cualquier tipo de aplicación que emplee los protocolos SMTP, IMAP
y LDAP.
1.4 Alcance
Para la realización de este Trabajo Especial de Grado se propone el diseño, el
desarrollo y la implementación de una infraestructura para el manejo de correos
basado en protocolos estándares (SMTP, IMAP o LDAP) y tecnologías abiertas
(Debian GNU/Linux1, Postfix2, Dovecot3 y OpenLDAP4).
1.5 Distribución del Documento
En el presente Trabajo Especial de Grado se describen los aspectos más
importantes para la implementación de una infraestructura para el manejo de
correos electrónicos. El resto del documento está estructurado de la siguiente
manera:
1
http://www.debian.org
http://www.postfix.org
3
http://www.dovecot.org
4
http://www.openldap.org
2
Capítulo 1: Introducción
18
Capítulo 2: Marco Teórico: Contiene documentación esencial sobre la
infraestructura para el manejo de correos electrónicos, así como el protocolo de
directorio LDAP.
Capítulo 3: Método para implementar el sistema: Estudia el método a seguir
para implementar los sistemas para manejo de correos electrónicos y su
integración con el servicio de directorio.
Capítulo 4: Caso de Estudio: Expone los requerimientos que tenía el IGVSB en
su infraestructura para el manejo de correos electrónicos, los programas que se
utilizaron para cumplir estos requerimientos y su configuración.
Capítulo 5: Pruebas: Describe como se realizaron las pruebas para probar el
correcto funcionamiento de todo el sistema.
Capítulo 6: Conclusiones y Recomendaciones: Ofrece una visión de la
importancia del sistema implementado, recomendaciones para trabajos futuros y
las limitaciones presentes de la infraestructura.
Capítulo 2. Marco Teórico
19
2 MARCO TEÓRICO
La siguiente investigación abarca dos temas: él de la infraestructura necesaria
para manejar correos electrónicos en ambientes empresariales, utilizando
protocolos abiertos como SMTP e IMAP y, él de la utilización de un servicio de
directorio basado en LDAP. Se ofrecerá una descripción de estos temas,
mostrando su estructura y funcionamiento. El objetivo principal de este capítulo es
ofrecer una base teórica sólida para el entendimiento de los elementos que
conformarán la infraestructura a implementar.
2.1 Correo Electrónico
El correo electrónico es un servicio de red que permite a los usuarios enviar y
recibir mensajes rápidamente mediante sistemas de comunicación electrónicos.
Se usa este nombre, para denominar al sistema que provee este servicio en
Internet y redes IP, mediante el protocolo SMTP, aunque por extensión también
puede verse aplicado a sistemas análogos que usen otras tecnologías. Por medio
de mensajes de correo electrónico se pueden enviar, no solamente textos, sino
todo tipo de documentos. Su eficiencia, conveniencia y bajo costo están logrando
que el correo electrónico desplace al correo normal para muchos usos habituales
en las empresas [8].
2.1.1 Elementos
Para que se puedan enviar y recibir correos electrónicos, es necesario poseer los
siguientes componentes:
Ø Una dirección de correo electrónico: Esta dirección tiene que estar
soportada por un registro DNS.
Ø Un servidor que maneje el protocolo SMTP (Mail Transfer Agent).
Ø Un cliente de correo electrónico: El mismo puede ser una aplicación que
funcione en la máquina del cliente o utilizando un cliente Web (Mail User
Agent).
Dirección de correo
Una dirección de correo electrónico es un conjunto de palabras que identifican una
persona que puede enviar y recibir correos. Cada dirección es única y pertenece
siempre a la misma persona.
Capítulo 2: Marco Teórico
20
Un ejemplo es [email protected], que se lee persona arroba servicio punto
com. El signo @ (llamado arroba) siempre está en cada dirección de correo, y la
divide en dos partes: el nombre de usuario o alias de correo (a la izquierda de la
arroba; en este caso, persona), y el dominio en el que está (a la derecha de la
arroba; en este caso, servicio.com). La arroba también se puede leer "en", ya que
[email protected] identifica al usuario que está en el servidor servicio.com
(indica una relación de pertenencia).
Lo que hay a la derecha de la arroba es el nombre del proveedor que da el correo,
y por lo tanto, es algo que el usuario no puede cambiar. Por otro lado, lo que hay a
la izquierda es un identificador cualquiera, que puede tener letras, números y
algunos signos.
Las letras que integran la dirección pueden ser indiferentemente en mayúsculas o
minúsculas.
Por
ejemplo,
[email protected]
es
igual
a
[email protected]. En la Figura 2.1 se muestran ejemplos de direcciones de
correo electrónico.
Figura 2.1 Ejemplos de direcciones de correo electrónico
Servidor de Correo o MTA (Mail Transfer Agent)
Un servidor de correo o MTA, también conocido como un MX en el contexto de los
registros DNS, es un programa que transfiere los mensajes de correo electrónico
de una computadora a otra [9].
Capítulo 2: Marco Teórico
21
El envió de los mensajes se hace utilizando el protocolo SMTP. El MTA recibe los
mensajes de otro MTA o directamente de un MUA. El MTA trabaja detrás de
escenas, mientras los usuarios interactúan con el MUA.
La entrega de los correos se hace mediante los MDA (Mail Delivery Agent).
Muchos MTAs tienen esta funcionalidad incorporada, aunque existen MDA como
Procmail que permiten mayor sofisticación.
De acuerdo a varios estudios realizados, los servidores de correo más populares
son Sendmail, Postfix, Microsoft Exchange Server, etc. En la Tabla 2.1 se muestra
los 5 servidores de correo más populares para el primero de agosto de 2007 de
una consulta 1.752.365 servidores [10].
Servidor
Número de Servidores
Sendmail
269.138
Microsoft Exchange
200.400
Exim
181.492
Postfix
133.801
IMail
31.176
%
29,42 %
21,90 %
19,84 %
14,62 %
3,41 %
Tabla 2.1: Los 5 servidores de correo más populares para agosto de 2007
Cliente de Correo o MUA (Mail User Agent)
Un cliente de correo electrónico, o también llamado Mail User Agent es un
programa usado para leer y enviar correos electrónicos [11].
Los clientes de correo electrónico fueron pensados para ser programas simples.
Su función consiste en leer los mensajes del correo del usuario almacenados en el
buzón. Para ello, deben soportar protocolos como POP3 e IMAP, para
comunicarse con un MTA y poder acceder a los correos almacenados en el buzón.
Para enviar los correos, estos son entregados al MTA mediante el protocolo
SMTP, de forma que el programa cliente de correo electrónico no necesita
proporcionar ninguna clase de función de transporte. En la Figura 2.2 se muestra
una captura del cliente de correo Mozilla Thunderbird.
Capítulo 2: Marco Teórico
22
Figura 2.2: Mozilla Thunderbird
Además de los clientes de correo electrónico que operan en la máquina cliente,
existen también programas de correo electrónico basados en la Web,
denominados webmail o correo Web, en donde el cliente de correo es una
aplicación que corre en un servidor Web. En la Figura 2.3 se muestra una captura
del cliente tipo Web SquirrelMail.
Capítulo 2: Marco Teórico
23
Figura 2.3: SquirrelMail
2.1.2 Protocolos
SMTP
Simple Mail Transfer Protocol (SMTP) o protocolo simple de transferencia de
correo electrónico. Es un protocolo de red basado en texto utilizado para el
intercambio de mensajes de correo electrónico entre computadoras. Está definido
en el RFC 2821 y es un estándar oficial de Internet.
Anteriormente estaba definido en los RFC 821 y RFC 822. El primero de ellos,
define el protocolo y, el segundo, el formato del mensaje que el protocolo debe
transportar.
Con el tiempo se ha convertido en uno de los protocolos más usados del Internet.
Para adaptarse a las nuevas necesidades surgidas del crecimiento y popularidad
del Internet se han hecho varias ampliaciones a este protocolo, como lo es, el
poder enviar un texto con formato o archivos adjuntos.
Capítulo 2: Marco Teórico
24
Funcionamiento
SMTP se basa en el modelo cliente-servidor, donde un cliente envía un mensaje a
uno o varios receptores. La comunicación entre el cliente y el servidor consiste
enteramente en líneas de texto compuestas por caracteres ASCII. El tamaño
máximo permitido para estas líneas es de 1.000 caracteres.
Las respuestas del servidor constan de un código numérico de tres dígitos,
seguido de un texto explicativo. El número va dirigido a un procesado automático
de la respuesta por un autómata, mientras que el texto permite que un humano
interprete la respuesta. En el protocolo SMTP todas las órdenes, réplicas o datos
son líneas de texto, delimitadas por los caracteres <CR><LF>. Todas las réplicas
tienen un código numérico al comienzo de la línea.
En el conjunto de protocolos TCP/IP, SMTP es transportado por TCP, usando
normalmente el puerto 25 en el servidor para establecer la conexión.
Resumen simple del funcionamiento del protocolo SMTP
Cuando un cliente establece una conexión con el servidor SMTP, espera a que
éste envíe un mensaje “220 <texto>” o “421 Service non available”.
Se envía un HELO desde el cliente. Con ello el servidor se identifica. Esto puede
usarse para comprobar si se conectó con el servidor SMTP correcto.
El cliente comienza la transacción del correo con la orden MAIL FROM. Como
argumento de esta orden se puede pasar la dirección de correo remitente. El
servidor responde “250 OK”.
Seguidamente se indican los destinatarios del correo. La orden para esto es RCPT
TO:<destino@host>. Se pueden mandar tantas órdenes RCPT TO como
destinatarios del correo. Por cada destinatario, el servidor contestará “250 OK” o
“550 No such user here”, si no encuentra al destinatario.
Una vez enviados todos los RCPT TO, el cliente envía una orden DATA para
indicar que a continuación se envían el contenido del mensaje. El servidor
responde “354 End data with <CR><LF>.<CR><LF>”. Esto indica al cliente como
ha de notificar el fin del mensaje.
Ahora el cliente envía el cuerpo del mensaje, línea a línea. Una vez finalizado, se
termina con un <CR><LF>.<CR><LF> (la última línea será un punto), a lo que el
servidor contestará “250 OK”, o un mensaje de error apropiado.
Tras el envío, el cliente, si no tiene que enviar más correos, finaliza la conexión
con la orden QUIT.
Capítulo 2: Marco Teórico
25
Puede que el servidor SMTP soporte las extensiones definidas en el RFC 1651, en
este caso, la orden HELO puede ser sustituida por la orden EHLO, con lo que el
servidor contestará con una lista de las extensiones admitidas. Si el servidor no
soporta las extensiones, contestará con un mensaje "500 Syntax error, command
unrecognized".
En la Tabla 2.2 se encuentran las órdenes básicas de SMTP:
Orden
HELO
MAIL FROM
RCPT TO
DATA
QUIT
RSET
Significado
Identifica el cliente
Indica el remitente del correo
Indica el destinatario del correo
Contenido del correo
Finaliza la conexión
Aborta el envío del correo
Tabla 2.2: Órdenes básicas del protocolo SMTP
En la Tabla 2.3 se indican los códigos de respuesta que puede dar el servidor
SMTP.
Código
Significado
2XX
Operación solicitada concluida con éxito
3XX
La orden fue aceptada, pero se esperan nuevos datos para terminar la
operación
4XX
Error temporal, se puede repetir la orden más tarde
5XX
Error permanente, no se puede repetir la orden
Tabla 2.3: Códigos de respuesta en el protocolo SMTP
Una vez que el servidor recibe el mensaje finalizado con un punto, puede: bien
almacenarlo si es para un destinatario que pertenece a su dominio, o bien
retransmitirlo a otro servidor para que finalmente llegue a un servidor del dominio
del receptor.
Ejemplo de una comunicación SMTP
En primer lugar se ha de establecer una conexión entre el emisor (cliente) y el
receptor (servidor). Esto puede hacerse automáticamente con un programa cliente
de correo o mediante un cliente telnet.
En la Figura 2.4 se muestra un ejemplo de una conexión típica.
Capítulo 2: Marco Teórico
26
Figura 2.4: Ejemplo de una conexión SMTP
Formato del mensaje
Como se muestra en la Figura 2.4, el mensaje es enviado por el cliente después
de que éste mande la orden DATA al servidor. El mensaje está compuesto por dos
partes:
Ø Cabecera: En el ejemplo, las tres primeras líneas del mensaje (luego de
enviada la orden DATA al servidor) son la cabecera. En ellas se usan unas
palabras claves para definir los campos del mensaje. Estos campos ayudan
a los clientes de correo a organizarlos y mostrarlos. Los más típicos son
subject (asunto), from (emisor) y to (receptor). Estos dos últimos campos,
Capítulo 2: Marco Teórico
27
no hay que confundirlos con las órdenes MAIL FROM y RCPT TO, que
pertenecen al protocolo, pero no al formato del mensaje.
Ø Cuerpo del mensaje: Es el mensaje propiamente dicho. En el SMTP
básico está compuesto únicamente por texto y finalizado con una línea en
la que el único carácter es un punto.
POP3
Post Office Protocol (POP3) es un protocolo que permite a los clientes locales de
correo obtener los mensajes de correo electrónico almacenados en un servidor
remoto. La mayoría de los suscriptores de los proveedores de Internet acceden a
sus correos a través de POP3.
Características
El diseño de POP3 es para recibir correos y no para enviarlos. Permite que los
usuarios con conexiones intermitentes (tales como las conexiones módem),
descarguen su correo electrónico cuando se encuentren conectados de tal
manera, que puedan ver y manipular sus mensajes, sin necesidad de permanecer
conectados. Cabe mencionar, que la mayoría de los clientes de correo incluyen la
opción de dejar los mensajes en el servidor, de manera tal que, un cliente que
utilice POP3 se conecta, obtiene todos los mensajes, los almacena en la
computadora del usuario como mensajes nuevos, los elimina del servidor y
finalmente se desconecta.
Los clientes que utilizan la opción dejar mensajes en el servidor, por lo general
usan la orden UIDL (Unique IDentification Listing). La mayoría de las órdenes de
POP3 identifican los mensajes dependiendo de su número ordinal del servidor de
correo. Esto genera problemas al momento que un cliente pretende dejar los
mensajes en el servidor, ya que el número de los mensajes cambia de una
conexión a otra. Por ejemplo, un buzón de correo contenía 5 mensajes en la última
conexión, después otro cliente elimina el mensaje número 3, el siguiente usuario
se topará con que los últimos dos mensajes estarán decrementados en uno. El
UIDL proporciona un mecanismo que evita los problemas de numeración. El
servidor le asigna una cadena de caracteres única y permanente al mensaje.
Cuando un cliente de correo compatible con POP3 se conecta al servidor utiliza la
orden UIDL para obtener el mapeo del identificador de mensaje. De esta manera,
el cliente puede utilizar ese mapeo para determinar qué mensajes hay que
descargar y cuáles hay que guardar al momento de la descarga.
Al igual que otros viejos protocolos de Internet, POP3 utilizaba un mecanismo de
autenticación posible. En la actualidad, POP3 cuenta con diversos métodos de
Capítulo 2: Marco Teórico
28
autenticación que ofrecen una diversa gama de niveles de protección contra los
accesos ilegales al buzón de correo de los usuarios. Uno de éstos es APOP, él
cual utiliza funciones MD5 para evitar los ataques de contraseñas. Mozilla,
Eudora, Novell Evolution así como Mozilla Thunderbird implementan funciones
APOP.
Funcionamiento
Para establecer una conexión a un servidor POP3, el cliente de correo abre una
conexión TCP en el puerto 110 del servidor. Cuando la conexión se ha
establecido, el servidor POP3 envía al cliente POP3 una invitación y después las
dos máquinas se envían entre sí otras órdenes y respuestas que se especifican en
el protocolo. Como parte de esta comunicación, al cliente POP3 se le pide que se
autentifique (estado de autenticación), donde el nombre de usuario y la contraseña
del usuario se envían al servidor POP3. Si la autenticación es correcta, el cliente
POP3 pasa al estado de transacción, en este estado se pueden utilizar las
órdenes LIST, RETR y DELE para mostrar, descargar y eliminar mensajes del
servidor, respectivamente. Los mensajes definidos para su eliminación no se
quitan realmente del servidor hasta que el cliente POP3 envía la orden QUIT para
terminar la sesión. En ese momento, el servidor POP3 pasa al estado de
actualización, fase en la que se eliminan los mensajes marcados y se limpian
todos los recursos restantes de la sesión.
En la Tabla 2.4 se muestran los comandos básicos del protocolo POP3.
Operación
USER <nombre>
PASS <password>
STAT
LIST
RETR <número>
TOP <número> <líneas>
DELE <número>
RSET
QUIT
Significado
Envía el nombre de usuario
Envía el password
Muestra la cantidad de mensajes y la longitud total que
ocupan
Muestra la lista de mensajes y su longitud
Muestra el mensaje indicado
Muestra la cabecera y el número de líneas especificado del
mensaje indicado
Marca para borrar el mensaje indicado
Desmarca los mensajes marcados para ser borrados
Terminar conexión
Tabla 2.4: Comandos del protocolo POP3
En la Figura 2.5, se muestra un ejemplo de una conexión POP3.
Capítulo 2: Marco Teórico
29
Figura 2.5: Ejemplo de una conexión POP3
IMAP
IMAP es un protocolo de red de acceso a mensajes electrónicos almacenados en
un servidor. Mediante IMAP se puede tener acceso al correo electrónico desde
cualquier equipo que tenga una conexión con el servidor que almacena los
correos. IMAP tiene varias ventajas sobre POP3, que es el otro protocolo
empleado para obtener los correos almacenados en un servidor. Por ejemplo, es
posible especificar en IMAP carpetas del lado servidor. Por otro lado, es más
complejo que POP3.
Capítulo 2: Marco Teórico
30
IMAP fue diseñado como una moderna alternativa a POP3 por Mark Crispin en el
año 1986. Fundamentalmente, los dos protocolos le permiten a los clientes de
correo, acceder a los mensajes almacenados en un servidor de correo.
Bien sea empleando POP3 o IMAP4 para obtener los mensajes, los clientes
utilizan SMTP para enviar mensajes. Los clientes de correo electrónico son
comúnmente denominados clientes POP3 o IMAP, pero en ambos casos se utiliza
SMTP.
IMAP es utilizado frecuentemente en redes grandes; por ejemplo los sistemas de
correo de un campus. IMAP le permite a los usuarios acceder a los nuevos
mensajes instantáneamente en sus computadoras, ya que el correo está
almacenado en la red. Con POP3 los usuarios tendrían que descargar el correo a
sus computadoras o accederlo vía Web. Ambos métodos toman más tiempo de lo
que le tomaría a IMAP, y se tiene que descargar el correo nuevo o refrescar la
página para ver los nuevos mensajes.
De manera contraria a otros protocolos de Internet, IMAP4 soporta mecanismos
nativos de cifrado. La transmisión de contraseñas en texto plano también es
soportada.
Ventajas sobre POP3
Algunas de las características importantes que diferencian a IMAP y POP3 son:
Ø Soporte para los modos de operación conectado y desconectado.
Ø Al utilizar POP3, los clientes se conectan al servidor de correo brevemente,
solamente lo que les tome descargar los nuevos mensajes. Al emplear
IMAP, los clientes permanecen conectados el tiempo que su interfaz
permanezca activa y descargan los mensajes bajo demanda. Esta forma de
trabajar de IMAP puede dar tiempos de respuesta más rápidos para
usuarios que tienen una gran cantidad de mensajes o mensajes grandes.
Ø Soporte para la conexión de múltiples clientes simultáneos a un mismo
buzón.
Ø El protocolo POP3 asume que el cliente conectado es el único dueño de
una cuenta de correo. En contraste, el protocolo IMAP4 permite accesos
simultáneos a múltiples clientes y proporciona ciertos mecanismos a los
clientes para que se detecten los cambios hechos a un buzón por otro
cliente concurrentemente conectado.
Capítulo 2: Marco Teórico
31
Ø Soporte para acceso a las partes MIME de los mensajes y obtención parcial
de las mismas.
Ø Casi todo el correo electrónico de Internet es transmitido en formato MIME.
El protocolo IMAP4 le permite a los clientes obtener separadamente
cualquier parte MIME individual, así como obtener porciones de las partes
individuales o los mensajes completos.
Ø Soporte para que la información del estado del mensaje se mantenga en el
servidor.
Ø A través de la utilización de indicadores definidos en el protocolo IMAP4 los
clientes pueden vigilar el estado del mensaje, por ejemplo, si el mensaje ha
sido o no leído, respondido o eliminado. Estos indicadores se almacenan en
el servidor, de manera que varios clientes conectados al mismo buzón en
diferente tiempo pueden detectar los cambios hechos por otros clientes.
Ø Soporte para accesos múltiples a los buzones de correo en el servidor.
Ø Los clientes de IMAP4 pueden crear, renombrar o eliminar los buzones (por
lo general presentado como carpetas al usuario) en el servidor y mover
mensajes entre buzones. El soporte para múltiples buzones de correo
también le permite al servidor proporcionar acceso a directorios públicos y
compartidos.
Ø Soporte para búsquedas del lado del servidor.
Ø IMAP4 proporciona un mecanismo para que los clientes pidan al servidor
que busque mensajes de acuerdo a una cierta variedad de criterios. Este
mecanismo evita que los clientes descarguen todos los mensajes de su
buzón de correo con el fin de agilizar las búsquedas.
Ø Soporte para un mecanismo de extensión definido.
Ø Como reflejo de la experiencia en versiones anteriores de los protocolos de
Internet, IMAP4 define un mecanismo explícito mediante el cual puede ser
extendido. Se han propuesto muchas extensiones de IMAP4 y son de uso
común.
Ø Un ejemplo de extensión es el IMAP IDLE, que sirve para que el servidor
avise al cliente cuando ha llegado un nuevo mensaje de correo y éstos se
sincronicen. Sin esta extensión, para realizar la misma tarea, el cliente
debería contactar periódicamente al servidor para ver si hay mensajes
nuevos.
Capítulo 2: Marco Teórico
32
2.2 Funcionamiento de la Infraestructura de Correo Electrónico
Para enviar un correo electrónico, el cliente de correo electrónico (MUA) envía el
correo mediante SMTP a un servidor de correo (MTA). Si el destino es local al
MTA, éste entrega el correo al MDA, él cual coloca el correo en el buzón. Los dos
formatos más comunes para almacenar los buzones son mbox y Maildir. En el
formato mbox, el buzón del correo se representa como un archivo de texto; en
cambio, en el formato Maildir, el buzón es una carpeta en donde cada mensaje se
representa como un archivo distinto. Si la entrega no es local, el MTA hace una
consulta DNS para la dirección del MTA que recibe los correos dirigidos al dominio
destino. Posteriormente, éste se comunica con el MTA destino mediante SMTP
para enviar el correo electrónico. El cliente, si desea acceder a los correos
almacenados en su buzón; se comunica con el servidor de correo, mediante el
protocolo POP3 o IMAP4, para así descargar los correos.
En la Figura 2.6 se muestra gráficamente el proceso necesario para enviar un
correo electrónico.
Capítulo 2: Marco Teórico
33
Figura 2.6: Proceso para enviar un correo electrónico
2.3 Servicio de Directorio
Un servicio de directorio es una aplicación software o un conjunto de aplicaciones
que almacena y organiza la información sobre los usuarios de una red y recursos
de red, y a la vez, permite a los administradores gestionar el acceso de usuarios a
los recursos sobre dicha red. Además, los servicios de directorio actúan como una
capa de abstracción entre los usuarios y los recursos compartidos [12].
Un servicio de directorio no debería confundirse con el repositorio de directorio,
que es la base de datos que contiene la información sobre los objetos de
nombrado, gestionada por el servicio de directorio. En el caso del modelo de
servicio de directorio distribuido en X.500, se usan uno o más espacios de nombre
Capítulo 2: Marco Teórico
34
(árbol de objetos) para formar el servicio de directorio. El servicio de directorio
proporciona la interfaz del acceso a los datos que se contienen en uno o más
espacios de nombre de directorio. La interfaz del servicio de directorio es el
encargado de gestionar la autenticación de los accesos al servicio de forma
segura, actuando como autoridad central para el acceso a los recursos del sistema
que manejan los datos del directorio.
Como base de datos, un servicio del directorio está altamente optimizado para
lecturas y proporciona alternativas avanzadas de búsqueda en los diferentes
atributos, que se puedan asociar a los objetos de un directorio. Los datos que se
almacenan en el directorio son definidos por un esquema extensible y modificable.
Los servicios de directorio utilizan un modelo distribuido para almacenar su
información y esa información generalmente está replicada entre los servidores
que forman el directorio.
Diferencias con una base de datos relacional
Existe un cierto número de cosas a distinguir entre un servicio de directorio
tradicional y una base de datos relacional.
Ø Dependiendo del uso del directorio, la información se lee generalmente con
mayor frecuencia que la escritura; por lo tanto, las transacciones y las
operaciones de restauración generalmente no están implementadas en
algunos sistemas de directorio. Los datos suelen ser redundantes, siendo
su principal objetivo las búsquedas eficientes.
Ø Los datos se organizan en una estructura terminantemente jerárquica que
en ocasiones suele ser problemática. Para superar espacios de nombres
profundos, algunos directorios desmontan la jerarquía del espacio de
nombre del objeto en sus mecanismos de almacenaje para optimizar la
navegación. Es decir, estos directorios buscan el ítem basándose en los
atributos de los datos y después determinan sus valores del espacio de
nombre, pues este procedimiento es más rápido que la navegación de
espacios de nombres grandes para buscar tal ítem. En términos de
cardinalidad, los directorios tradicionales no tienen relaciones múltiples. En
su lugar, tales relaciones se deben mantener explícitamente usando las
listas de distintos nombres o de otros identificadores (similares a los
identificadores de tablas cruzadas usados en bases de datos relacionales).
Ø Originalmente la jerarquía de la información del directorio del X.500 era
considerada problemática contra diseños de datos relacionales.
Actualmente, se desarrolla con bases de datos orientadas a objetos
basadas en Java y los formularios en XML, y adoptan un modelo de objetos
Capítulo 2: Marco Teórico
35
jerárquico, indicando una evolución de la ingeniería de datos relacional
tradicional.
Ø Un esquema se define como clases de objeto, atributos, referencias y
conocimiento (espacios de nombre).
Ø Las clases de objeto tienen:
•
Atributos obligatorios, cada una de las instancias que debe tener
•
Atributos opcionales, se puede definir para una instancia, pero podría
también omitirse cuando se crea el objeto. La carencia de certeza del
atributo es como un NULL en bases de datos relacionales.
Ø Atributos multivaluados en directorios, permiten múltiples atributos de
nombrado en un nivel, tales como: tipo de máquina y números de serie
concatenados o múltiples números de teléfono para el "teléfono del trabajo".
Ø Los atributos y las clases de objetos se estandarizan a través de la industria
y se registran formalmente en el IANA para la identificación del objeto. Por
lo tanto, los usos del directorio intentan reutilizar mucha de las clases y de
los atributos estándar para maximizar la ventaja de tener software servidor
de directorio.
Ø Las instancias del objeto residen en espacios de directorio. Es decir, cada
clase de objeto hereda de su padre (y en última instancia de la raíz de la
jerarquía) añadiendo atributos de la lista debe/puede.
Ø Los servicios del directorio son a menudo un componente central en el
diseño de la seguridad de un sistema de informático teniendo una
granularidad fina con respecto al control de acceso: quién puede entrar, de
qué manera, en qué información.
El diseño del directorio es bastante diferente del diseño de una base de datos
relacional. En las bases de datos se tiende a diseñar un modelo de datos para
asuntos de negocios y los requisitos de los procesos, el cliente, el servicio, el
administrador. Con los directorios, lo que se hace es colocar la información en un
repositorio común para muchos usos y usuarios. Su diseño y esquema de la
información (e identidad) deben ser desarrollados conforme a lo que está
representando, a objetos en la vida real. En la mayoría de los casos, estos objetos
representan los usuarios, agendas, listas, preferencias, derechos, productos y
servicios, dispositivos, perfiles, políticas, números de teléfono, rutas, etc. Además,
uno debe considerar también los aspectos operacionales de diseño, en vista del
funcionamiento y de escala.
Capítulo 2: Marco Teórico
36
2.3.1 LDAP
LDAP es un protocolo de aplicación para consultar y modificar servicios de
directorio corriendo sobre TCP/IP.
Un directorio es un conjunto de objetos con atributos similares, organizados de
manera lógica y jerárquica. Un ejemplo es la guía telefónica, la cual consiste en
una serie de nombres (de personas o sociedades) organizadas alfabéticamente,
con cada nombre, teniendo una dirección y un número de teléfono. Por este
diseño base (además de otros factores) LDAP es usado comúnmente por otros
servicios de autenticación.
Un árbol de directorio LDAP a menudo refleja varias distribuciones, pudiendo ser:
geográficas, políticas u organizacionales, dependiendo del modelo escogido.
Actualmente, la distribución de los directorios tiende a estar basada en los
nombres DNS para estructurar los niveles más altos de la jerarquía. En niveles
más profundos en el árbol de directorio pueden aparecer entradas representando
personas, unidades organizacionales, impresoras, documentos, grupos de
personas o cualquier cosa que se pueda representar como un árbol de una o
varias entradas.
La versión actual de LDAP es la versión 3, la cual está especificada en una serie
de RFCs del IETF, como se detalla en el RFC 4510.
Origen e influencias
Las compañías de telecomunicaciones introdujeron el concepto de servicio de
directorio al campo de la computación y redes de computadoras, basados en la
experiencia de desarrollar directorios telefónicos por más de 70 años. La
introducción de estos conceptos se expresó en la especificación X.500, un
conjunto de protocolos producidos por la ITU en 1980.
Los servicios de directorios X.500 eran tradicionalmente accedidos por medio del
protocolo de X.500 DAP, el cual dependía de la pila de protocolos OSI. LDAP fue
diseñado originalmente para ser una alternativa ligera al protocolo DAP, utilizando
la pila de protocolos TCP/IP.
Servidores de directorios LDAP siguieron después, ya que permitían tener
servicios de directorios sin tener que implementar la pila OSI.
El protocolo LDAP fue creado por Tim Howes, Steve Kille y Wengyik Yeong. Las
mejoras posteriores han sido hechas por la IETF.
LDAP ha influenciado protocolos de Internet como XED, DSML, SPML y SLP.
Capítulo 2: Marco Teórico
37
Estructura del protocolo
Un cliente comienza una sesión LDAP conectándose a un servidor LDAP, por
defecto el servidor LDAP escucha en el puerto TCP 389. Entonces, el cliente envía
al servidor peticiones de operaciones a realizar, a las cuales el servidor responde
enviando los resultados de las operaciones. Con algunas excepciones, el cliente
no necesita esperar una respuesta de una operación anterior para poder enviar la
siguiente petición, y el servidor puede enviar las respuestas en cualquier orden.
El cliente le da un Message ID positivo a cada petición, y el servidor envía la
respuesta correspondiente con el mismo Message ID. Las respuestas incluyen un
código de resultado numérico que puede indicar el éxito de la operación, la
presencia de algún error u otros casos especiales.
Entre las operaciones que se pueden pedir están:
Start TLS: Esta operación establece un TLS en la conexión. Esto puede proveer
confidencialidad de datos y/o protección de la integridad de los datos. Durante la
negociación TLS, el servidor envía su certificado X.509 para probar su identidad.
El cliente también puede enviar un certificado para probar su identidad. Esta
operación se incluyó en la versión 3 del protocolo LDAP, anteriormente se utilizaba
LDAPS a través del puerto 636.
BIND: La operación de BIND autentica al cliente. El BIND simple envía el DN del
usuario y su password en claro, así que la conexión debe estar protegida
utilizando TLS. El servidor usualmente revisa el password contra el atributo
userPassword del DN específico. El BIND anónimo (con DN y contraseña vacía)
reinicializa la conexión a un estado anónimo. EL BIND SASL provee servicios de
autenticación a través de mecanismos tan variados como Kerberos o el certificado
enviado por el cliente en la operación StartTLS. En la operación BIND también se
envía la versión del protocolo a usar, normalmente se utiliza la versión 3.
Search and Compare: La operación de búsqueda es usada para buscar entradas
en el directorio, sus parámetros son:
baseObject: El DN desde el cual comenzar la búsqueda.
scope: Alcance, puede tener 3 valores BaseObject, sólo busca en la entrada
dada, singleLevel entradas inmediatamente un nivel más abajo del DN en base
object, o wholeSubtree (se busca en todo el subdirectorio comenzando por el DN
base).
Filter: Cómo se examina cada entrada dentro del alcance de la búsqueda, por
ejemplo (&(objectClass=person)(|(fivenName=John)(mail=john*))), busca por
personas que se llamen John o que su correo empiece por john.
derefAliases: Indica como se siguen las entradas alias (entradas que se refieren
a otras entradas).
Attributes: Los atributos a retornar en las búsquedas.
Capítulo 2: Marco Teórico
38
sizeLimit, timeLimit: Máximo número de entradas y tiempo de búsqueda máximo,
typesOnly retorna sólo tipos de atributos, no el valor de los mismos.
El servidor retorna las entradas que concordaron y una posible continuación de
referencias, seguido por el resultado final con el código de resultado.
La operación de comparación, toma un DN, un nombre de atributo y un valor y
revisa si las entradas contienen algún atributo con ese valor.
Operaciones de modificación
Ø Agregar, Eliminar y Modificar DN, todas requieren el DN de la entrada que
va a ser cambiada.
Ø Modificar, toma una lista de atributos a modificar y las modificaciones a
cada uno. Borra el atributo o algunos valores, agrega valores nuevos o
reemplaza los valores actuales por nuevos.
Ø La operación de agregar puede tener atributos adicionales o valores para
atributos ya existentes.
Ø Modificar DN toma un nuevo RDN, opcionalmente el DN padre nuevo y un
indicador que indica si se puede borrar el valor en la entrada que concuerda
con el RDN anterior.
Ø Un punto importante es que las operaciones de actualización son atómicas.
LDAP no define transacciones de múltiples operaciones.
Estructura del directorio
Un directorio es un árbol de entradas. Cada entrada consta de un conjunto de
atributos. Un atributo tiene un nombre (tipo de atributo o descripción de atributo) y
uno o más valores. Los atributos están definidos en un esquema.
Cada entrada consiste en su RDN construido de algunos atributos en la entrada,
seguidos por el DN de la entrada padre. Un DN se puede ver como una ruta
absoluta y un RDN como una ruta relativa. Los DN pueden cambiar en el tiempo
de vida de una entrada, por ejemplo, cuando las entradas son movidas de lugar en
el árbol. Para identificar sin ambigüedades las entradas, un UUID se puede
proveer entre el conjunto de atributos operacionales.
La Figura 2.7 muestra una entrada representada en formato LDIF:
Capítulo 2: Marco Teórico
39
Figura 2.7: Entrada en formato LDIF
dn es el nombre de la entrada, no es ni un atributo ni parte de la entrada. “cn=John
Doe” es el RDN de la entrada, y “dc=example,dc=com” es el DN de la entrada
padre. Las otras líneas muestran los atributos de la entrada. Los nombres de
atributos son típicamente cadenas de caracteres nemónicas, como “cn” que es
common name, “dc” para domain component, “mail” para correo electrónico y “sn”
para surname.
Un servidor mantiene un árbol comenzando desde una entrada en particular,
ejemplo: “dc=example,dc=com” y sus hijos. Los servidores también pueden tener
referencias
a
otros
servidores,
así
un
intento
de
acceso
a
“ou=departmnt,dc=example,dc=com” puede retornar un referral a un servidor que
tenga esa parte del árbol. El cliente puede entonces contactar al otro servidor.
Algunos servidores también soportan chaining, lo que significa que el servidor
contacta el otro servidor y retorna los resultados al cliente.
LDAP raramente define cualquier orden, el servidor puede retornar los valores en
un atributo, los atributos en una entrada, y las entradas encontradas por una
operación de búsqueda en cualquier orden. Esto sigue la definición formal, una
entrada es definida como un conjunto de atributos, y un atributo es un conjunto de
valores, y los conjuntos no tienen que estar ordenados.
Esquema
Los contenidos de las entradas en su subárbol están regidos por un esquema. El
esquema define los tipos de atributos que las entradas en el directorio pueden
contener. La definición de un atributo incluye una sintaxis y la mayoría de los
Capítulo 2: Marco Teórico
40
valores no binarios en LADP versión 3 están definidos por cadenas de caracteres
UTF-8. Por ejemplo un atributo “mail” puede contener el valor
“[email protected].”. Un atributo “jpegphoto” puede contener fotos en formato
binario jpeg. Un atributo “member” contiene registros dn de otras entradas en el
directorio. La definición de los atributos también especifica cuando un atributo
tiene un único valor o tiene múltiples valores, como buscar o comparar el atributo,
por ejemplo diferenciando mayúsculas o no, buscando por subcadenas, etc.
El esquema define “objects classes”. Cada entrada debe tener un atributo “objects
classes”, el cual debe contener clases definidas en el esquema. La definición de
las clases en el esquema define qué tipo de objeto la entrada puede representar,
por ejemplo, una persona, un objeto, una organización o dominio. La definición de
las clases de objetos también lista qué atributos son obligatorios y cuales son
opcionales, por ejemplo: una entrada representando a una persona puede
pertenecer a las clases “top” y “person”. Si la entrada pertenece a la clase person,
la entrada requerirá que ésta contenga un atributo “sn” y “cn” y permitirá que
pueda contener los atributos de “user password”, “telephone number” y otros
atributos. Dado que las entradas pueden pertenecer a muchas clases, cada
entrada tiene un conjunto completo de atributos opcionales y obligatorios,
formados por la unión entre los “objects classes” que representan. Los “objects
classes” pueden ser heredados de una entrada, ésta puede tener múltiples objects
classes que definen los atributos requeridos y disponibles de la entrada.
El esquema también incluye otra información que permite controlar las entradas en
el directorio. La mayoría de los elementos de esquema tiene un nombre y un oid
único.
Los servidores de directorio pueden publicar los esquemas que controlan una
entrada. Los administradores del servidor también pueden definir sus propios
esquemas, además de los estándares.
En la Figura 2.8 se muestra la definición del objectClass país.
Figura 2.8: Definición del objectClass País
Capítulo 2: Marco Teórico
41
Usos y Aplicaciones
Una razón para escoger LDAP para un servicio es que está ampliamente
soportado y los datos presentes en LDAP están disponibles para muchos clientes
y librerías. Otro aspecto es que LDAP es muy general e incluye seguridad básica y
puede soportar muchos tipos de aplicaciones.
Dos aplicaciones comunes de LDAP son: para tener datos de computadores,
usuarios y grupos, así como para mantener libretas de direcciones. Muchos
clientes de correo electrónico soportan búsquedas de LDAP.
Estructura de nombres
Dado que un servidor LDAP puede retornar referencias a otros servidores para
peticiones que él no puede servir, es necesaria una estructura de nombres para
las entradas de LDAP, para que uno pueda conseguir al servidor que posee un dn
en específico. Tal estructura de datos ya existe en los registros dns, los nombres
superiores en los servidores usualmente están basados en los nombres DNS.
Debajo del nivel superior los nombres de las entradas reflejan típicamente la
estructura interna de la organización.
La Figura 2.9 muestra un ejemplo de la estructura de nombres que puede tener el
directorio LDAP de una organización.
Figura 2.9: Ejemplo de la estructura de nombres que puede tener un directorio LDAP en una
organización
Capítulo 2: Marco Teórico
42
Capítulo 3: Método para Implementar el Sistema
43
3 MÉTODO PARA IMPLEMENTAR EL SISTEMA
El presente capítulo trata sobre el como determinar los componentes necesarios y
los pasos a seguir para implementar un servicio para el manejo de correos
electrónicos, integrado con un servicio de directorio, que esté adaptado a los
requerimientos del organismo en donde se va a implementar el sistema; siendo los
requerimientos principales, entre otros: el manejo centralizado de la autenticación
y los usuarios, el filtrado de distintos tipos de correo no deseado o con virus,
posibilidad de acceso a los correos electrónicos por parte de los usuarios
mediante Webmail, etc. En la Figura 3.1 se muestra el sistema resultante.
Por otro lado, cabe resaltar, que este método no tiene que ser seguido
necesariamente al pie de la letra, sino que el mismo debe ser adaptado de
acuerdo a los propósitos del organismo en el que se va a aplicar el servicio.
Figura 3.1: Sistema de manejo de correos electrónicos con servicio de autenticación
3.1 Definiciones
Antes de iniciar con los pasos a seguir para la aplicación del método es necesario
dar ciertas definiciones.
3.1.1 Correo Spam
El correo spam, es también conocido como correo basura o correo no deseado.
Consiste en el envío masivo de correos a numerosos destinatarios, usualmente
con fines comerciales o fraudulentos. La principal característica de este tipo de
correo es que el mismo no ha sido solicitado por el receptor, pudiendo también
contener identidades forjadas, material pornográfico, etc.
Capítulo 3: Método para Implementar el Sistema
44
3.1.2 Métodos utilizados por el spam
Para enviar correo no deseado, los spammers utilizan diversas técnicas para
obtener direcciones de correo válidas. Entre los métodos más usados para
construir listas de direcciones están:
Ø Obtener direcciones de correo que hayan sido publicadas en la Web,
utilizando robots para escanear páginas, foros, directorios de empresa y
consultando registros WHOIS.
Ø Virus que roban listas de contactos de la máquina infectada.
Ø Listados comprados a sitios Web que almacenan direcciones de correo.
Ø Confirmación de direcciones válidas mediante correos spam respondidos o
por la petición de retirar una suscripción.
3.1.3 Métodos para enviar correo spam
Los spammers aprovechan las deficiencias en varios sistemas para enviar correos
no solicitados, siendo las técnicas principales:
Ø Usando Webmails: Los spammers crean robots que se suscriben a
servicios de Webmail gratuito para así enviar correos a gran cantidad de
destinatarios. Actualmente, muchos proveedores de Webmail utilizan
sistemas llamados captcha, es decir, los usuarios intentando crear una
nueva cuenta son presentados con la imagen de una palabra, que
utilizando una fuente extraña o un fondo que dificulte su lectura, deben
ingresar para completar la creación de la cuenta. El objetivo es distinguir
entre un ser humano y un robot, aprovechando el hecho de que a los
programas lectores OCR, se les hace casi imposible leer estas palabras en
estas condiciones. Ciertos spammers han encontrado formas de superar
esta medida, utilizando sitios que ofrecen material pornográfico gratuito. Al
usuario se le presenta la imagen que le da el Webmail al robot, la cual al
ser llenada, dicha información puede ser utilizada por éste para crear la
cuenta.
Ø Usando computadoras infectadas con virus o malware: Los spammers
utilizan los computadores infectados para así enviar correos no solicitados
cubriendo sus rastros.
Ø Relay Abiertos: Los spammers aprovechan que muchos servidores de
correo no son configurados para restringir el relay de correo, así que los
spammers utilizan estos servidores para enviar correos a otros destinos.
Capítulo 3: Método para Implementar el Sistema
45
Actualmente, se exige que los servidores de correo tengan su funcionalidad
de relay configurada correctamente para evitar este problema. También,
ciertos organismos han creado listas de servidores de correo que funcionan
como relays abiertos para que sean utilizadas los servidores de correo,
para indicarles que no reciban correos enviados por estos servidores.
Ø Proxyes Abiertos: Los spammers también utilizan servicios de proxy que
permiten conectarse a cualquier destino en cualquier puerto, para así enviar
los correos no deseados. Con los relays abiertos, varios organismos han
creado listas de estos servicios, para que sean incluidos en listas negras en
los servidores de correo.
3.1.4 Técnicas para engañar a los filtros de correo
Muchos spammers utilizan varias técnicas con el fin de evitar el filtrado de correos
que hacen muchos servidores de correo, para así llegar a su destino, siendo la
principal la ofuscación del contenido de los mensajes, la cual aprovecha que
muchos filtros para correo examinan los mismos buscando patrones asociados
con el correo basura (publicidad, ciertos medicamentos, etc). Estos filtros pueden
ser instruidos para que eliminen correos que, por ejemplo, tengan en el asunto la
palabra viagra. Así pues, los spammers utilizan técnicas como dejar espacios, o
incluir caracteres especiales en los términos asociados con el spam, para poder
engañar al filtro del correo, pero permitiendo que la persona pueda entender el
mensaje enviado. Otra técnica común es mezclar el mensaje con etiquetas HTML
para engañar a los filtros, pero que a su vez puedan ser visualizados por clientes
que soporten mensajes basados en HTML. También, se utilizan imágenes que
contienen el texto del spam. Otra técnica utilizada para engañar a filtros más
avanzados es incluir muchas frases que no estén asociadas a spam para que el
correo no sea etiquetado como spam.
3.1.5 Técnicas Anti-Spam
Se han desarrollado varias técnicas para luchar contra el flagelo del correo basura,
pudiendo dividirse en dos grandes categorías, las técnicas utilizadas por el usuario
final, y las técnicas implementadas en los servidores de correo.
Técnicas usadas por el usuario final
Existen varios métodos que pueden utilizar los usuarios finales de los sistemas de
correo para prevenir y mitigar la recepción de grandes cantidades de correo
basura, siendo éstas:
Ø Alteración de direcciones: Si se van a publicar direcciones de correo
electrónico se pueden utilizar técnicas como la ofuscación de las
Capítulo 3: Método para Implementar el Sistema
46
direcciones, o ocultarlas utilizando imágenes o elementos CSS, para que
las mismas no puedan ser adquiridas por robots que escanean la Web.
Ø Evitar responder a correos basura: Confirmar un correo no deseado es un
gran error, ya que le permite saber al que lo envió que la dirección de
correo es válida.
Ø Ofrecer formularios para permitir ser contactado: Se pueden publicar
formularios que puedan ser llenados por los visitantes de una página para
que puedan contactar a la persona encargada, evitando así la necesidad de
publicar la dirección de correo electrónico.
Ø Desactivar el HTML en los correos: Esto permite evitar el spam que está
embebido en imágenes o en HTML. Además se pueden evitar infecciones
por instalaciones de malware.
Ø Direcciones de correo desechables: Se utilizan principalmente para
suscribirse a sitios no confiables que obligan a registrar una dirección de
correo electrónico
Ø Reportar el spam al ISP: Si se puede seguir el rastro hasta llegar al origen,
se puede denunciar al que envió los correos no solicitados, para que le sea
retirado el servicio de Internet. La efectividad de esta técnica depende
mucho del ISP.
Técnicas usadas por los servidores de correo
Existen varios métodos que se aplican al nivel del servidor de correo para evitar la
recepción de grandes cantidades de correo basura, siendo éstas:
Ø Filtrado basado en firmas: Se generan firmas de las partes no variables de
los correos y se comparan con una base de datos de firmas de correos
basura, para así clasificarlos.
Ø Listas negras: Existen organismos que mantienen listas de servidores y
direcciones IP conocidas como fuente de correo basura. La idea es
configurar los servidores de correo para que rechacen envíos de correos
originados de esos sitios.
Ø Obligar el uso de comunicaciones que cumplan con los RFCs de SMTP:
Esta técnica aprovecha que la mayoría de los programas que envían
correos no deseados están escritos pobremente y no cumplen
completamente con las especificaciones de los RFCs.
Capítulo 3: Método para Implementar el Sistema
47
Ø Listas Grises: Esta técnica consiste en que el servidor de correo rechaza
temporalmente los correos entrantes enviados de servidores de correos
desconocidos. El servidor responde con el código de error 4xx, él cual es
reconocido por todos los MTAs normales, los cuales intentaran enviar el
correo más tarde. Las listas grises están basadas en la premisa de que los
spammers no van a intentar reenviar sus mensajes, sino que van a intentar
enviar su mensaje a la siguiente dirección de correo que tengan en la lista.
Ø Registros MX falsos: Esta técnica consiste en colocar varios registros MX
que hagan referencia a direcciones IP inválidas, asumiendo que los
spammers al encontrarse con un servidor que no responde, desistirán de
enviar correos a esa dirección, a diferencia de un servidor MTA legítimo,
que intentará conectarse con el siguiente servidor de correo listado en los
registros MX para así enviar el correo.
Ø Chequeos de registros PTR: Se revisa que la dirección IP desde la que se
intenta enviar un correo está registrada en un servidor DNS y resuelve a un
nombre de host registrado como MX.
Ø Filtrado basado en reglas: Se escanean los correos buscando frases
asociadas con el spam, como: viagra, dietas, créditos, etc. Estos sistemas
usualmente requieren que se les proporcione listas de palabras para poder
identificar correos no deseados.
Ø Filtrado de contenidos con análisis estadístico: Conocidos también como
listas bayesianas; estos sistemas clasifican los correos mediante la
creación de reglas (o aprendizaje) que son generadas a partir de correos
deseados y no deseados proporcionados por el usuario. El sistema analiza
los correos en base a esta información asociándole un puntaje al correo, lo
que permite definir si un correo es deseado o no.
3.2 Fases del método
3.2.1 Recopilación de requerimientos
En esta fase se debe hacer la traducción de los requerimientos y características
del organismo al campo de funcionalidades que va a ofrecer el sistema, para así
definir los roles a implementar y conocer las características de hardware y
software necesarios para satisfacer estas necesidades. Una forma práctica es
dando respuesta a las siguientes preguntas:
Ø ¿Cuántos usuarios van a utilizar el sistema?
Ø ¿Se van a aplicar cuotas de almacenamiento?
Capítulo 3: Método para Implementar el Sistema
48
Ø ¿Se van a aplicar restricciones al envío y recepción de correos?
Ø ¿Se van a filtrar correos no deseados y con virus?
Ø ¿Los usuarios necesitan acceder a sus correos desde redes externas?
3.2.2 Definición de los roles
Según las funcionalidades que van a ser ofrecidas por el sistema se definen los
roles necesarios y el hardware a emplear, siendo lo idóneo tener cada rol un
servidor distinto. Los roles son los siguientes:
Ø Servidor MTA e IMAP.
Ø Servidor de directorio.
Ø Servidor para el Webmail (opcional, depende del organismo).
Ø Servidor para el filtrado de correo no deseado y virus (opcional, depende
del organismo).
3.2.3 Criterios para la selección del software
Una parte importante a tomar en cuenta, es definir los programas que se van a
utilizar y las características que deben poseer los mismos, para permitir la
implementación del sistema completo, pudiéndose desglosar en:
Ø Sistema operativo:
•
Multiusuario y con soporte para multiprogramación.
•
Soporte para cuotas en el sistema de archivos y capacidad de manejar
gran número de archivos e información.
•
Capacidad de acceder a la base de datos de los usuarios almacenada
en directorios de LDAP.
•
Capacidad de notificar el exceso en la cuota utilizando el correo
electrónico.
Capítulo 3: Método para Implementar el Sistema
49
Ø Servidor de filtrado de correo basura (este servicio a veces se integra con el
MTA):
•
Detección, marcaje y eliminación de correos basura según criterios
configurables, utilizando técnicas como: listas negras y grises, chequeos
del cumplimiento del protocolo SMTP, filtros bayesianos, etc.
•
Detección y remoción de virus, con la posibilidad de descarga y
actualización automática de las firmas de virus.
Ø Servidor SMTP:
•
Capacidad para manejar gran volumen de correo.
•
Capacidad de consultar la lista de usuarios del organismo mediante el
protocolo LDAP
•
Capacidad de configurar restricciones de envío basadas en orígenes y
destinos.
•
Integración con programas externos que realicen las funciones de MDA.
•
Capacidad de almacenar los correos en buzones con formato mbox y
Maildir.
Ø Servidor IMAP:
•
Proveer métodos para autenticar a los usuarios de forma segura (evitar
el envío de claves en texto claro).
•
Manejo de los formatos mbox y Maildir.
•
Capacidad para manejar gran volumen de usuarios e información.
Ø Servidor LDAP:
•
Capacidad para manejar grandes volúmenes de información y consultas.
•
Capacidad de extender y agregar esquemas al directorio.
•
Ofrecer controles de acceso para los datos almacenados en el
directorio.
Capítulo 3: Método para Implementar el Sistema
•
50
Proveer métodos para realizar conexiones seguras (evitar el envío de
claves en texto claro).
Ø Servidor Web (Webmail):
•
Capacidad para realizar conexiones a directorios LDAP.
•
Capacidad para conectarse a servidores IMAP y soporte para varios
métodos de autenticación.
•
Capacidad de enviar mensajes al MTA utilizando SMTP.
•
Ofrecer métodos de acceso seguros. (No envía formularios con
contraseñas sin cifrar).
Ø Clientes de correo electrónico de los usuarios:
•
Capacidad para conectarse a directorios LDAP.
•
Capacidad para conectarse a servidores IMAP y soporte para varios
métodos de autenticación.
•
Capacidad de enviar mensajes al MTA utilizando SMTP.
3.2.4 Procedimiento para la implementación
A continuación se especifican los pasos a seguir para tener el sistema en estado
operativo:
Configuración del DNS
El sistema de correos electrónicos depende de la buena configuración del servicio
DNS y la creación de ciertos registros como:
Ø Agregar el registro MX del dominio para que haga referencia a la dirección
IP pública del servidor de filtrado de correo basura.
Ø Agregar el registro PTR asociado a la dirección IP, desde la cual se
enviarán correos electrónicos a redes externas.
Capítulo 3: Método para Implementar el Sistema
51
Configuración del servicio de directorio
Como parte primordial de todo el sistema, es necesario tener un servicio de
directorio seguro, que opere correctamente, para ello se siguen estos pasos:
Ø Instalar servicio de directorio.
Ø Configurar servicio de directorio cumpliendo con los requisitos de seguridad
y adaptado al organismo.
Ø Cargar los datos del personal del organismo al servicio de directorio.
Configuración del servidor SMTP
Para enviar y recibir correctamente correos electrónicos es necesario tener un
servidor SMTP operativo y correctamente configurado. Con el fin de lograr estos
objetivos se siguen los pasos señalados a continuación:
Ø Configurar el sistema operativo del servidor de correo para que obtenga el
listado de las cuentas de usuario del servidor de directorio.
Ø Instalar el servidor de SMTP (el MTA).
Ø Configurar el servidor SMTP para que obtenga el listado de destinatarios
locales y alias válidos del servidor de directorio.
Ø Configurar las restricciones de envío y recepción de correo electrónico.
Ø Configurar los límites en los mensajes de correo electrónico.
Ø Configurar el método para almacenar los correos electrónicos en el sistema
(mbox o Maildir).
Ø Definir y configurar la aplicación de cuotas para los usuarios.
Configuración del servidor IMAP
Una parte fundamental de los sistemas de correo electrónico es la forma en que
los usuarios acceden e interactúan con su buzón de correo. Para permitir esto es
necesario contar con una correcta configuración del servidor IMAP, con los
siguientes pasos:
Ø Instalar el servidor IMAP.
Capítulo 3: Método para Implementar el Sistema
52
Ø Configurar el servidor IMAP, indicando el formato que el servidor SMTP
utilizó para almacenar los correos.
Configuración del servidor de filtrado de correo no deseado y virus
El surgimiento de correo no deseado y la proliferación de virus, hace que sea
fundamental el correcto funcionamiento de este componente, siguiendo esta serie
de pasos para configurarlo:
Ø Instalar el servidor de filtrado de correo no deseado y virus.
Ø Configurar todos los diversos mecanismos para filtrar correos no deseados
(listas negras, análisis por firmas, listas grises, análisis estadístico de
contenido, cumplimiento de los RFCs, verificación de registros PTR y reglas
de filtrado, restricción de adjuntos como ejecutables, scripts, etc.).
Ø Configurar el antivirus para revisar todos los mensajes de correo y las
actualizaciones de las firmas.
Ø Configurar la integración del mecanismo de filtrado de correos con el
servidor MTA.
Configuración de los clientes de correo electrónico
La importancia de este paso radica en que, es con esta parte del sistema con la
que el usuario interactúa directamente, pudiendo ser una aplicación de escritorio o
una aplicación en un servidor Web accesible desde un navegador. Para configurar
este servicio se siguen los pasos detallados a continuación:
Ø Instalar el servidor Web para instalar el servidor de Webmail.
Ø Configurar el servidor de Webmail y los clientes de correo de los usuarios,
para que utilicen el servidor SMTP para enviar los correos electrónicos, el
servidor IMAP para obtener los correos electrónicos almacenados y el
servicio de directorio para consultar la lista de correos del organismo.
Capítulo 4: Caso de Estudio
53
4 CASO DE ESTUDIO
Con el fin de validar el sistema para el manejo de correos electrónicos, se
instanció el método descrito en el capítulo anterior, en el Instituto Geográfico de
Venezuela Simón Bolívar (IGVSB). En este capítulo, se hace una breve reseña del
IGVSB, posteriormente se estudian las necesidades particulares que presenta el
Instituto, se exponen los criterios para seleccionar los programas utilizados para
implementar el sistema, y por último, se presentan el proceso de implementación y
la configuración necesaria para cumplir los requerimientos.
4.1 Instituto Geográfico de Venezuela Simón Bolívar (IGVSB)
El Instituto Geográfico de Venezuela Simón Bolívar, es un instituto autónomo
adscrito al Ministerio del Poder Popular para el Ambiente. Su sede actual se
encuentra en el Edificio Camejo, ubicado en el Distrito Capital. El IGVSB es el ente
rector de la actividad geográfica, cartográfica y de catastro del Estado Venezolano
[13].
Misión: Dirigir, producir y proveer la información territorial oficial en materia de
Geografía, Cartografía y Catastro, a los fines de contribuir con el desarrollo
integral y la seguridad de la Nación.
Visión: Institución tecnológica de vanguardia, reconocida nacional e
internacionalmente como una organización pionera, vital y estratégica del Estado
Venezolano, que hace posible con su información geográfica, el desarrollo
sustentable, sustitutivo del modelo petrolero, que promueve el redescubrimiento y
utilización de la invalorable riqueza territorial, con el trabajo creador de toda la
sociedad.
Entre sus atribuciones están:
Ø Dirigir, coordinar y ejecutar las políticas y los planes nacionales en materia
de geografía, geodesia, geofísica, cartografía, percepción remota y
catastro, que formule el Presidente de la República y el Ministerio del Poder
Popular para el Ambiente.
Ø Fomentar y dirigir los programas nacionales en materia de catastro y
coordinar con los organismos competentes su formación y conservación.
Ø Dictar las normas y especificaciones técnicas en las materias reguladas por
la Ley de Geografía, Cartografía y Catastro Nacional y velar por su
cumplimiento.
Capítulo 4: Caso de Estudio
54
Ø Elaborar y actualizar la cartografía básica, así como el mapa físico y político
de la República.
Ø Planificar, establecer, mantener y actualizar el Sistema Geodésico
Nacional.
Ø Verificar técnicamente y autorizar la ejecución de los levantamientos a
realizarse por medios aerotransportados, con fines de obtención de
información territorial, en coordinación con los organismos públicos
competentes.
Ø Ejercer la autoridad nacional en materia de nombres geográficos o
topónimos.
Ø Establecer, mantener y administrar el archivo nacional de nombres
geográficos o topónimos.
Ø Dictar las normas técnicas para establecer el Sistema de Codificación
Catastral.
Ø Dictar las normas técnicas de valoración catastral.
Ø Promover y realizar estudios e investigaciones para el desarrollo
tecnológico en materia de geografía, geodesia, geofísica, cartografía,
percepción remota y catastro.
Ø Suministrar datos e información y prestar asistencia técnica para la
elaboración de productos y servicios en las materias de su competencia.
Ø Verificar técnicamente y certificar los proyectos cartográficos realizados
para los organismos del Estado.
Ø Verificar y certificar los mapas, planos, cartas y cualesquiera otras formas
de representación del territorio nacional, de conformidad con las normas
técnicas establecidas.
Ø Establecer conjuntamente con los organismos competentes los
procedimientos técnicos para vincular el catastro con el Registro Público.
Ø Dictar las normas técnicas para establecer el Registro Catastral.
Ø Promover, coordinar y ejecutar las acciones necesarias para la formación y
conservación del catastro de las tierras de las comunidades indígenas.
Capítulo 4: Caso de Estudio
55
Ø Promover, coordinar y ejecutar las acciones necesarias para la formación y
conservación del inventario de recursos naturales y del catastro de la
infraestructura de servicios públicos, en función de las políticas y planes del
Ejecutivo Nacional. A tales efectos, el Instituto podrá celebrar convenios
con los organismos públicos competentes.
Ø Publicar los resultados de los estudios en materia de geografía, cartografía
y catastro.
Ø Ejercer la guarda y custodia del acervo histórico en las materias de su
competencia.
Ø Gestionar y administrar la ejecución de convenios, programas y proyectos
no reembolsables y de inversión, en materias de su competencia.
Ø Fortalecer las relaciones de cooperación con los organismos técnicos o
científicos afines al área de su competencia.
Ø Brindar apoyo técnico a los organismos del Poder Público en el ámbito de
su competencia.
Ø Propiciar y coordinar la formación y capacitación del personal requerido
para el cumplimiento de su misión.
4.2 Requerimientos
Como parte fundamental del proceso de implementación del sistema, se incluyen
a continuación una serie de requerimientos, que constituyen la base que guiarán
los elementos que compondrán el sistema final:
Ø Administración centralizada de usuarios y la libreta de direcciones del
Instituto.
Ø Sistema de cuotas para controlar el crecimiento de los buzones.
Ø Listas que indiquen, qué personal puede o no enviar y recibir correo de
sitios externos.
Ø Sistema adecuado a las disposiciones del Decreto Nº 3.390.
Ø El sistema no debe restringir que programas se pueden utilizar en el
sistema. En particular los MUAs.
Capítulo 4: Caso de Estudio
56
4.3 Equipos de Hardware que Integraran el Sistema
A continuación se indican los equipos de hardware con los que contaba el Instituto
y que fueron utilizados para implementar el sistema con sus características
respectivas.
4.3.1 Unidad de almacenamiento para los buzones de los usuarios
Para el almacenamiento de los buzones, se utilizó una unidad de almacenamiento
externo marca Promise modelo Vtrak. 15110 con 4 discos SATA de 500 GB en
una configuración RAID 5 de 3 discos, con el 4 disco como spare. En la Figura 4.1
se muestra una imagen referencial de la unidad.
Figura 4.1: Unidad Promise Vtrak. 15110
4.3.2 Servidor de correo e IMAP
Para la implementación del servidor SMTP e IMAP se utilizó un servidor marca HP
modelo Proliant DL360 G3 (en la Figura 4.2 se muestra una imagen referencial),
con las siguientes características:
Ø 2 procesadores Intel Xeon a 3.0 GHz
Ø 1 GB de memoria RAM
Ø 2 discos duros de 72,8 GB Ultra SCSI 320 con 2 tarjetas controladoras Ultra
SCSI.
Ø 2 tarjetas de red 100/1000 Mbps.
Capítulo 4: Caso de Estudio
57
Figura 4.2: HP Proliant DL360 G3
4.3.3 Servidor de directorio
Para la implementación del servidor de directorio se utilizó un servidor marca IBM
modelo xSeries 336 (en la Figura 4.3 se muestra una imagen referencial), con las
siguientes características:
Ø 2 procesadores Intel Xeon a 3.0 GHz
Ø 1 GB de memoria RAM
Ø 2 discos duros de 68,36 GB Ultra SCSI 320 con 2 tarjetas controladoras
Ultra SCSI.
Ø 2 tarjetas de red 100/1000 Mbps.
Figura 4.3: IBM xSeries 336
Capítulo 4: Caso de Estudio
58
4.4 Programas que Integran el Sistema
A continuación se muestran los criterios que se emplearon para seleccionar los
programas utilizados en el sistema implementado y una breve descripción de los
mismos.
4.4.1 Sistema operativo
Para cumplir con el requerimiento impuesto por el Instituto, referente a que los
programas a utilizar deben ser primariamente basados en software libre, conforme
con lo dispuesto en el Decreto Nº 3.390; se seleccionó el sistema operativo
GNU/Linux por ser su licencia GPL v2 y ser más conocido que otras alternativas
con licencias compatibles con el Decreto Nº 3.390, como OpenBSD, FreeBSD,
NetBSD. La distribución seleccionada fue Debian GNU/Linux, dada su reconocida
estabilidad y facilidad para instalar y actualizar programas.
Linux
Linux es la denominación de un sistema operativo tipo-Unix y el nombre de un
núcleo. Es uno de los desarrollos más prominente del software libre, cuyo código
fuente está disponible públicamente, para que cualquier persona pueda libremente
usarlo, estudiarlo, redistribuirlo y, con los conocimientos informáticos adecuados,
modificarlo [14].
Los primeros sistemas Linux se originaron en 1992, al combinar utilidades de
sistema y librerías del proyecto GNU con el núcleo Linux, completando un sistema
también conocido como GNU/Linux. Desde fines de 2000, Linux ha obtenido un
reconocimiento significativo, por haber recibido apoyo por parte de diversas
empresas multinacionales del mundo de la informática, tales como: IBM [15], Sun
Microsystems, Hewlett-Packard [16] y Novell [17].
Si bien Linux es utilizado como sistema operativo en computadores de escritorio
(PCs x86 y x86-64, etc), computadores de bolsillo, teléfonos celulares, dispositivos
empotrados y otros, su mayor desarrollo se ha llevado a cabo en el mundo de los
servidores y supercomputadores.
Linux se distribuye junto con otros programas en la forma de distribuciones. Una
distribución es un conjunto de aplicaciones reunidas por un grupo de personas o
empresas para permitir instalar fácilmente un sistema Linux.
Capítulo 4: Caso de Estudio
59
La creciente popularidad de Linux se debe a las ventajas que presenta con
respecto a otros tipos de software. Entre otras razones se debe a su estabilidad, al
acceso a las fuentes (lo que permite personalizar el funcionamiento y auditar la
seguridad y privacidad de los datos tratados), a la independencia de proveedor, al
costo casi nulo en licencias (en la Tabla 4.1 se muestra una comparación en el
costo inicial que tiene la puesta en marcha de sistemas Windows y Linux [18]), a la
seguridad, a la rapidez con que incorpora los nuevos adelantos tecnológicos (IPv6,
microprocesadores de 64 bits), a la escalabilidad (se pueden crear clusters de
cientos de computadoras), a la activa comunidad de desarrollo que hay a su
alrededor, a su interoperatibilidad y a la abundancia de documentación.
Windows GNU/Linux (Red Hat) Ahorro
Compañía con 50 usuarios $ 69.987
$ 80
$ 69.907
Compañía con 100 usuarios $ 136.734
$ 80
$ 136.654
Compañía con 250 usuarios $ 282.974
$ 80
$ 282.894
Tabla 4.1: Comparación de costos en la puesta en marcha inicial de Windows vs. Linux
Hay muchos organismos públicos que han mostrado su apoyo al software libre,
sea migrando total o parcialmente sus servidores y sistemas de escritorio, sea
subvencionándolo. Como ejemplos se tiene a:
Ø Alemania, pagando por el desarrollo del Kgroupware. Además, ciudades
como Munich, que migró sus sistemas a SuSE Linux, una distribución
alemana especialmente orientada a KDE.
Ø En España, algunos gobiernos autónomos están desarrollando sus propias
distribuciones no sólo para uso administrativo sino también académico. Por
ejemplo GuadaLinex en Andalucía, Molinux en Castilla-La Mancha.
Ø Venezuela, donde por decreto presidencial, se estableció el uso
preferencial del software libre y GNU/Linux en toda la administración
pública, incluyendo ministerios y oficinas gubernamentales y se está
fomentando la investigación y el desarrollo de software libre.
Debian GNU/Linux
Debian GNU/Linux es la principal distribución Linux del proyecto Debian, que
basa su principio y fin en el software libre [19].
Creada por el proyecto Debian en el año 1993, esta distribución combina el kernel
Linux y utilidades GNU.
Capítulo 4: Caso de Estudio
60
Nace como una apuesta por separar en sus versiones el software libre del
software no libre. El modelo de desarrollo es independiente a empresas, creado
por los propios usuarios, sin depender de ninguna forma de necesidades
comerciales. Debian no vende directamente su software, lo pone a disposición de
cualquiera en el Internet, aunque sí permite a personas o empresas distribuir
comercialmente este software mientras se respete su licencia.
Debian se caracteriza por:
Ø La disponibilidad en varias plataformas hardware. La versión 4.0 incluye
soporte para 11 plataformas (alpha, amd64, arm, hppa, i386, ia64, mips,
mipsel, powerpc, s390 y sparc).
Ø Una amplia colección de software disponible. La versión 4.0 viene con
18.733 paquetes.
Ø Un grupo de herramientas para facilitar el proceso de instalación y
actualización del software (APT, Aptitude, Dpkg, Synaptic, Dselect, etc).
Ø Su compromiso con los principios y valores involucrados en el movimiento
del software libre.
Ø No tiene marcado ningún entorno gráfico en especial, pudiéndose instalar,
ya sea: GNOME, KDE, Xfce, Enlightenment y otros.
4.4.2 Sistema de archivos
El sistema de archivos seleccionado para el almacén de los buzones de los
usuarios fue el sistema de archivos XFS, esto debido a su capacidad para manejar
volúmenes grandes, expansión del sistema de archivos en línea, capacidad para
realizar varias operaciones de entrada y salida en paralelo, soporte para cuotas,
journal para los metadatos del sistema de archivos y gran ancho de banda para
las transacciones.
XFS
XFS es un sistema de archivos de 64 bits con journaling de alto rendimiento
creado por SGI (Silicon Graphics Inc.) para su implementación de Unix llamada
IRIX. En mayo del 2000, SGI liberó XFS bajo una licencia de código abierto.
XFS se incorporó a Linux a partir de la versión 2.4.25, cuando Marcelo Tosatti
(responsable de la rama 2.4) lo consideró lo suficientemente estable para
incorporarlo en la rama principal de desarrollo del kernel. Los programas de
Capítulo 4: Caso de Estudio
61
instalación de las distribuciones de SuSE, Gentoo, Mandriva, Slackware, Fedora,
Ubuntu y Debian ofrecen XFS como un sistema de archivos más.
Capacidad
XFS soporta un sistema de archivos de hasta 9 exabytes, aunque esto puede
variar dependiendo de los límites impuestos por el sistema operativo. En sistemas
Linux de 32 bits, el límite es 16 terabytes.
Registro de Bitácora (Journaling)
XFS provee soporte para llevar un registro (journaling), donde los cambios al
sistema de archivos primero son escritos en un diario o journal antes de que se
actualicen los datos del disco. El journal es un buffer circular de bloques del disco
que no son parte del sistema de archivos. En XFS el registro (journal) contiene
entradas 'lógicas' que describen a un alto nivel las operaciones que se están
realizando, al contrario de otros sistemas de archivo con un registro (journal)
'físico', que guardan una copia de los bloques modificados durante cada
transacción. Las actualizaciones del registro (journal) se realizan asincrónicamente
para evitar una baja en el rendimiento. En el caso de una caída repentina del
sistema, las operaciones inmediatamente anteriores a la caída pueden ser
terminadas, garantizando así la consistencia del sistema. La recuperación se
realiza automáticamente a la hora del montaje del sistema de archivos y la
velocidad de recuperación es independiente del tamaño del sistema de archivos.
Incluso, si alguna información que fuese modificada inmediatamente antes de la
caída del sistema no fuese escrita al disco, XFS se encarga de borrar todos los
bloques de datos sin escribir, eliminando así cualquier compromiso de seguridad.
Grupos de Asignación
Los sistemas de archivos XFS están particionados internamente en grupos de
asignación, que son regiones lineares de igual tamaño dentro del sistema de
archivos. Los archivos y los directorios pueden crear grupos de asignación. Cada
grupo gestiona sus inodos y su espacio libre de forma independiente,
proporcionando escalabilidad y paralelismo. Múltiples hilos pueden realizar
operaciones de E/S simultáneamente en el mismo sistema de archivos.
Reservación de bandas
Si un sistema de archivos XFS va a ser creado en un arreglo de discos RAID, la
unidad de banda puede ser especificada cuando el sistema de archivos es creado.
Esto maximiza la tasa de peticiones de E/S, asegurando que las reservaciones de
datos, inodos y el log interno estén alineadas en potencias de la unidad de banda.
Capítulo 4: Caso de Estudio
62
Reservación basada en extents
Los bloques usados en los archivos guardados en sistemas de archivos XFS son
manejados con extents (Bloque de espacio contiguo en disco) de tamaño variable,
donde un extent describe uno o más bloques contiguos. Esto permite reducir esta
lista en comparación a otros sistemas de archivos. En XFS, las estructuras de
datos para manejar los extents son pares de árboles B, por cada grupo de
reservación. Este esquema permite reservar espacio de manera muy eficiente.
Bloques de tamaño variable
XFS permite especificar el tamaño del bloque, el cual puede variar desde 512 B a
64 KB, lo cual permite optimizarlo según el uso esperado.
Reservación retardada
XFS utiliza técnicas de evaluación flojas para la reservación de espacio. Así,
cuando un archivo es escrito, éste se guarda en un buffer y no se reserva el
espacio para los datos inmediatamente, haciéndose esta reserva cuando los datos
finalmente están vaciados al disco. Esto permite que existan más posibilidades de
que los archivos sean almacenados en espacios contiguos, reduciendo la
fragmentación y mejorando el desempeño.
E/S directa
Para aplicaciones con muchas operaciones de E/S, XFS permite que las
operaciones que no sean guardadas en cache accedan directamente al espacio
de usuario. Así, los datos son transmitidos entre el buffer de la aplicación y el
disco utilizando DMA.
Tasa de E/S garantizada
XFS permite garantizar tasas de E/S, por medio de la reservación de ancho de
banda. Esta funcionalidad tiene un uso principalmente por aplicaciones en tiempo
real, tales como el streaming.
Defragmentación en línea
Aunque XFS utiliza técnicas para evitar sufrir de problemas de fragmentación, XFS
provee una utilidad para defragmentar el sistema de archivos sin necesidad de
desmontarlo o desactivarlo.
Capítulo 4: Caso de Estudio
63
Redimensionamiento en línea
XFS provee una utilidad que permite redimensionar un sistema de archivos sin
necesidad de desmontarlo, si existe espacio sin asignar en el dispositivo. Cabe
destacar que sólo se permite aumentar el tamaño del sistema de archivos, esta
utilidad se utiliza típicamente en conjunción con el manejo lógico de volúmenes.
Utilidades para respaldar y restaurar nativas
XFS provee utilidades que permiten respaldar y restaurar el nivel de sistema de
archivos; es decir, se respaldan o restauran también los metadatos del sistema de
archivos. XFS permite volcar el sistema de archivos mientras está en uso, además
de permitir que las operaciones de volcado y restauración se puedan resumir o
interrumpir sin problemas.
4.4.3 Servidor SMTP
De las tres principales alternativas de servidor SMTP (Sendmail, Postfix e EXIM
4), se seleccionó Postfix por su diseño orientado a la seguridad, su capacidad para
manejar grandes volúmenes de correo electrónico y su configuración sencilla. En
la Tabla 4.2 se muestra la comparación realizada entre varios servidores SMTP.
Seguridad
Escalabilidad
Facilidad de
Configuración
Sendmail
Gran historial de
fallos de seguridad
Postfix
Diseño modular.
EXIM 4
Diseño monolítico.
La seguridad es
una de sus
metas.
Escrito tratando de
evitar los errores
cometidos por
Sendmail
Problemas de
desempeño en el
procesamiento de la
cola de correos en
sitios con gran
cantidad de tráfico
Maneja varios
protocolos.
Maneja varios
protocolos.
Posee un lenguaje
de programación
para realizar su
configuración
Soporta
integración con
varias bases de
datos y procesos
externos
Dos archivos de
configuración con
un sintaxis simple
Complejo de
configurar
correctamente por
administradores sin
experiencia
Un archivo de
configuración con una
sintaxis simple
Tabla 4.2: Comparación de varios servidores SMTP que son software libre
Capítulo 4: Caso de Estudio
64
Postfix
Postfix es un MTA de código abierto. Es un programa para el enrutamiento y envío
de correo electrónico, creado con la intención de que sea una alternativa más
rápida, fácil de administrar y segura al ampliamente utilizado Sendmail. En varias
distribuciones de Linux es el MTA incluido por defecto. Fue originalmente escrito
por Wietse Venema y continúa siendo desarrollado activamente. Postfix fue
liberado a mediados de 1999, bajo la licencia IBM Public License 1.0, la cual es
una licencia de software libre.
Características
Ø Ofrece soporte para TLS.
Ø Delegación de políticas SMTP a un proceso externo: esto permite la
implementación de listas grises y filtrado de contenido avanzado.
Ø Soporte para diferentes fuentes de información, como: listas de usuarios,
listas de destinos válidos, etc. Entre las fuentes de datos soportadas se
encuentran: Berkeley BD, CDB, DBM, LDAP, MySQL y PostgreSQL.
Ø Soporte para dominios virtuales y distintos formatos para almacenar los
buzones: el formato mbox y Maildir.
Ø Reescritura de direcciones en la cabecera y cuerpo del mensaje, soporte
para VERP, SMTP-AUTH por SASL, etc.
Ø Soporte para Milter.
Ø Puede ser compilado en cualquier sistema operativo Unix que cumpla con
el estándar POSIX y posea las librerías de sockets BSD.
Una de las fortalezas de Postfix es su resistencia contra ataques de buffer
overflow. Otra, es la capacidad de manejar grandes cantidades de correo. Postfix
está compuesto por diferentes servicios, donde cada uno está diseñado bajo la
filosofía de funcionar con la menor cantidad de privilegios. Así, si alguna parte del
sistema es comprometida, el impacto es limitado a ese servicio y es más
complicado que afecte al resto del sistema. Sólo existe un proceso con privilegios
administrativos llamado Master, y otros pocos (local, virtual, pipe) que pueden
escribir en disco e invocar programas externos. Si se desea la mayoría de estos
servicios pueden correr en un entorno restringido chroot. En la Figura 4.4, se
muestra la arquitectura de procesos de Postfix para recibir los correos electrónicos
y en la Figura 4.5, se muestra la arquitectura para el reenvío o entrega de los
correos electrónicos.
Capítulo 4: Caso de Estudio
65
Figura 4.4: Arquitectura de Postfix para recibir correos electrónicos
Figura 4.5: Arquitectura de Postfix para reenviar / entregar correos electrónicos
4.4.4 Servidor IMAP
Existen 3 principales implementaciones de IMAP de dominio público (Cyrus IMAP
Server, Courier-IMAP y Dovecot). En la selección del servidor de IMAP, se
tomaron en cuenta características tales como: facilidad de configuración,
seguridad, eficiencia y manejo de buzones almacenados con el formato Maildir;
Capítulo 4: Caso de Estudio
66
dando como resultado que se utilice el servidor Dovecot al adaptarse a todos
estos criterios. En la Tabla 4.3 se muestra la comparación realizada entre varios
servidores IMAP.
Seguridad
Facilidad de
configuración
Eficiencia
Cyrus IMAP
Server
Diseñado con el
objetivo de ser
seguro.
Poca
documentación en
el sitio Web del
programa.
Courier-IMAP
Diseñado con el
objetivo de ser
seguro.
Un archivo de
configuración
por cada
parámetro.
Difícil de configurar
por administradores
sin experiencia.
Capacidad de
manejar gran
volumen de
usuarios.
Permite
configuración
por Webmin
Capacidad de
manejar gran
volumen de
usuarios.
Puede ser
implementado en
clusters.
Formatos de
almacenamiento
soportados
Formato Maildir
especifico de
Cyrus.
mbox, Maildir.
Dovecot
Diseñado con el
objetivo de ser
seguro.
Un archivo de
configuración.
Gran volumen de
documentación.
Uso de índices.
Capacidad de
manejar gran
volumen de
usuarios.
Capacidad de
controlar el número
de procesos para
cargas altas.
mbox, Maildir, dbox
(Propio de Dovecot).
Tabla 4.3: Comparación de varios servidores IMAP que son software libre
Dovecot
Dovecot es un servidor IMAP y POP3 open source para sistemas Unix. En su
diseño se le ha dado gran importancia a los aspectos de seguridad. Entre sus
otros objetivos están: el ser liviano, rápido y fácil de configurar. Dovecot puede
funcionar con los formatos de buzones mbox y Maildir.
Entre sus características más resaltantes se encuentran:
Ø Dovecot está entre los servidores IMAP más eficientes, dado que los
buzones son indexados transparentemente, lo cual permite tener un buen
Capítulo 4: Caso de Estudio
67
desempeño sin sacrificar la compatibilidad con otras herramientas que
manipulen buzones.
Ø Dovecot permite que los buzones y sus índices puedan ser modificados por
varias computadoras al mismo tiempo. Esto permite que Dovecot pueda
funcionar con NFS y sistemas de archivos en cluster.
Ø Los mecanismos de autenticación soportados son muy flexibles,
permitiendo utilizar varios mecanismos y bases de datos de autenticación.
Ø Dovecot es altamente extensible por medio de plugins.
Ø Soporte completo para IMAP4rev1 y POP3. Soporte para IPv6, SSL y TLS.
Ø Soporte para varias extensiones de IMAP como SORT, THREAD y IDLE.
4.4.5 Servicio de directorio
Para la implementación del servicio de directorio, se utilizó el programa
OpenLDAP. OpenLDAP es la más popular implementación libre del protocolo
LDAP, las otras implementaciones conocidas no son software libre; como por
ejemplo: Active Directory, Sun Java System Directory Server, IBM Tivoly Directory
Server.
OpenLDAP
OpenLDAP es una implementación open source del protocolo LDAP, desarrollado
por el Proyecto OpenLDAP. Es distribuido bajo la licencia OpenLDAP Public
License. Varias distribuciones de Linux incluyen OpenLDAP para el soporte del
protocolo LDAP. OpenLDAP puede funcionar también en las variantes Unix,
basadas en BSD, AIX, HP-UX, MAC OS X, Solaris, etc.
Componentes de OpenLDAP, se divide principalmente en:
Ø Slapd- Servidor de LDAP y sus herramientas asociadas.
Ø Slurp Servidor de replicación.
Ø Librerías para implementar el protocolo LDAP y clientes de ejemplo.
Capítulo 4: Caso de Estudio
68
4.5 Implementación
El sistema quedó distribuido como aparece en la Figura 4.6. Para implementarlo
se instalaron en los 2 servidores Debian GNU/Linux versión 4 (nombre código
Etch), con la versión del kernel de Linux 2.6.18. En la configuración, sólo se instaló
el sistema base y se removieron servicios no utilizados como ident, NFS y
portmapper.
Figura 4.6: Distribución del Sistema en el IGVSB
4.5.1 Configuración del servidor de directorio
Para instalar OpenLDAP como servicio de directorio se siguieron los siguientes
pasos: (En la Figura 4.7, se muestra la distribución del árbol de directorio
implementado y en la Figura 4.8, se muestran los comandos necesarios para
realizar estas operaciones):
Ø Instalar el servidor OpenLDAP, los programas clientes para acceder al
directorio y el paquete del programa Courier que contiene el esquema que
permite guardar los alias del correo en el servicio de directorio.
Ø Copiar el esquema que contiene la definición de los alias de correo en el
directorio de esquemas de OpenLDAP.
Ø Obtener un certificado digital y configurar el servidor de LDAP. (En la Figura
4.9, se muestra la configuración hecha con debconf y en la Figura 4.10, se
muestra los cambios a hacer en los archivos de configuración).
Ø Crear índices y cargar usuarios (En la Figura 4.11, se muestra un ejemplo
de los datos a cargar en formato LDIF).
Capítulo 4: Caso de Estudio
Figura 4.7: Estructura del árbol de directorio implementada
Figura 4.8: Pasos para instalar y configurar el servidor LDAP
Figura 4.9: Configuración hecha con debconf para slapd
69
Capítulo 4: Caso de Estudio
Figura 4.10: Configuración para el servidor de LDAP
70
Capítulo 4: Caso de Estudio
71
Figura 4.11: Ejemplo de archivo LDIF utilizado para cargar los datos
4.5.2 Configuración del servidor de correo
Para instalar el servidor de correo y centralizar la autenticación, se siguieron los
siguientes pasos: (En la Figura 4.12, se muestran los comandos necesarios para
realizar estas operaciones):
Ø Configurar las opciones del sistema de archivos de la partición a utilizar
como almacén de los buzones de correo y las cuotas. (En la Figura 4.13, se
muestran los cambios necesarios).
Ø Eliminar el servidor de correo que trae la distribución por defecto (Exim),
para así instalar Postfix y procmail.
Capítulo 4: Caso de Estudio
72
Ø Configurar Postfix con el soporte para LDAP (En la Figura 4.14, se muestra
la configuración con debconf, en la Figura 4.15, se muestran los cambios en
los archivos de configuración, en la Figura 4.16, se muestra la consulta
LDAP para obtener lista destinos locales valida y en la Figura 4.17, se
muestran las listas utilizadas).
Ø Configurar el soporte para autenticación con LDAP (En Figura 4.18, se
muestran los cambios realizados).
Ø Instalar y configurar Dovecot (En la Figura 4.19, se muestran los cambios
realizados para utilizar IMAP).
Figura 4.12: Comandos para configurar el servidor de correo
Capítulo 4: Caso de Estudio
Figura 4.13: Configuración para el manejo de cuotas y el sistema de archivos
Figura 4.14: Configuración de Postfix con debconf
73
Capítulo 4: Caso de Estudio
Figura 4.15: Cambios en el archivo de configuración /etc/postfix/main.cf
74
Capítulo 4: Caso de Estudio
Figura 4.16: Parámetros de búsqueda para obtener la lista de usuarios locales mediante
LDAP
Figura 4.17: Lista de control del envío de correos electrónicos
75
Capítulo 4: Caso de Estudio
Figura 4.18: Cambios para realizar autenticación mediante LDAP
76
Capítulo 4: Caso de Estudio
Figura 4.19: Configuración del servidor IMAP
77
Capítulo 5: Pruebas
79
5 PRUEBAS
En este capítulo se describe el escenario al que se sometió a prueba el sistema de
manejo de correos electrónicos implementado en el Instituto, para medir y evaluar
el funcionamiento de los 2 servidores y sus servicios asociados.
5.1 Escenario
Para realizar las pruebas del sistema, se comenzó con la oficina de Tecnología y
Sistemas del IGVSB, utilizándose clientes de correo como Outlook y Thunderbird.
Posteriormente, se probó el sistema con 175 usuarios en condiciones de
producción en las cuales se realizaron las mediciones aquí citadas.
5.1.1 Configuración de los clientes de correo electrónico
Primero, se configuró la cuenta de correo en el cliente de correo electrónico
preferido por el usuario, especificando parámetros tales como: nombre a mostrar,
dirección del servidor SMTP (ver Figura 5.1); luego, el método para descargar los
correos electrónicos; en este caso se utilizó el protocolo IMAP sobre SSL (ver
Figura 5.2) y, por último la dirección del servidor de directorios para descargar la
libreta de direcciones.
Figura 5.1: Configuración del cliente de correo especificando el servidor SMTP e IMAP
Capítulo 5: Pruebas
80
Figura 5.2: Configuración del cliente de correo electrónico para utilizar IMAP sobre SSL
5.2 Medición del Desempeño del Servidor de Correo y Directorio
Las mediciones de desempeño de los 2 servidores se hicieron en las horas
laborables y con una carga aproximada de 175 usuarios, que son los que ya
utilizaban el sistema implementado.
Para realizar las mediciones, se usaron las utilidades que incluye Linux, como:
uptime (permite revisar el promedio de procesos que están esperando por CPU),
vmstat (permite revisar el uso del procesador y de la memoria principal del
sistema), df (muestra cuanto espacio está libre en un filesystem), repquota
(reporta el uso de la cuota de espacio en disco de los usuarios). Además, se utilizó
la información de archivos log del sistema.
Capítulo 5: Pruebas
81
5.2.1 Servidor de correo electrónico
A continuación se muestran los resultados obtenidos en el servidor de correo:
Ø Resultados de los comandos df (ver Figura 5.3) y repquota (ver Figura 5.4):
Se observa que para una carga aproximada de 200 usuarios utilizando
cuotas, se puede controlar el uso del espacio en disco, lo que permite
proponer el uso de un espacio de almacenamiento de 500 GB (2 GB para
cada usuario) para almacenar los correos, utilizando el resto del espacio en
el disco para otras tareas como, la implementación de un servidor de
archivos compartidos.
Figura 5.3: Salida del comando df ejecutado en el servidor de correo
Figura 5.4: Salida del comando repquota en el servidor de correo
Ø Resultados del comando vmstat (ver Figura 5.5): Se observa que el servidor
donde operan los servicios de SMTP e IMAP, generan poco uso de CPU
(98% ocioso) y de memoria virtual (64 KB), siendo utilizada la memoria
principalmente en buffers (38505 KB) y cache (846020 KB). Estos datos
permiten concluir que, no se necesitan grandes cantidades de memoria
RAM para implementar estos servicios con tiempos de respuesta dentro del
rango aceptable para los usuarios.
Capítulo 5: Pruebas
82
Figura 5.5: Salida del comando vmstat ejecutado en el servidor de correo
Ø Resultados del comando uptime (ver Figura 5.6): Se observa que en
promedio, se tiene máximo 2 procesos esperando por CPU, lo que permite
concluir que no es necesario invertir en un servidor con mayor poder de
procesamiento.
Figura 5.6: Salida del comando uptime en el servidor de correo
Ø Fragmento de mail.log (ver Figura 5.7): Se observa el correcto
funcionamiento del servidor SMTP en sus funciones de recepción y envío
de correo electrónico.
Figura 5.7: Parte del archivo mail.log
Capítulo 5: Pruebas
83
5.2.2 Servidor de directorio
A continuación se muestran los resultados obtenidos en el servidor de directorio:
Ø Resultados del comando vmstat (ver Figura 5.8): Se observa que el servidor
de LDAP genera poco uso de CPU (100% ocioso) y de memoria virtual (0
KB), siendo utilizada la memoria principalmente en buffers (116708 KB) y
cache (42744 KB). Estos datos permiten concluir que, no se necesitan
grandes cantidades de memoria RAM para implementar este servicio, en
particular, aprovechando el uso de cache de las consultas que hacen los
clientes del directorio.
Figura 5.8: Salida del comando vmstat en el servidor de directorio
Ø Resultados del comando uptime (ver Figura 5.9): Se observa que en
promedio se tiene máximo 1 proceso esperando por CPU, lo que permite
concluir que no es necesario invertir en un servidor con mayor poder de
procesamiento para implementar un servidor de directorio.
Figura 5.9: Salida del comando uptime en el servidor de directorio
5.3 Interpretación de los Resultados
5.3.1 Servidor de correo electrónico
De la ejecución de los comandos mencionados, se puede observar el poco uso del
espacio en el disco donde se almacenan los buzones, lo cual permite posibilidades
de crecimiento mediante la expansión de las cuotas de los buzones de los
usuarios y así dar un mejor aprovechamiento al espacio disponible. Se observa
también, el poco uso del procesador y la carga promedio baja, esto gracias a la
configuración del servidor IMAP para evitar la creación de procesos sin un límite
preestablecido, lo cual le da al servidor un grado de holgura para mantener niveles
de funcionamiento adecuados. Finalmente, se observa como funciona
correctamente el sistema de cuotas, limitando el uso de los recursos y, al servidor
SMTP realizando sus labores de entrega y envío de correos electrónicos.
Capítulo 5: Pruebas
84
La aplicación del método propuesto en este caso particular utilizando software
libre, se puede apreciar que comparado con soluciones propietarias ya existentes;
no se necesita tener hardware muy potente para implementar estos sistemas de
forma eficiente (respetando las diferencias en funcionalidades ofrecidas) y que no
hay limitación alguna por licencias, en aspectos como el tamaño máximo que
puede ser utilizado en buzones de correo.
5.3.2 Servidor de directorio
En el servidor de directorio se observa la poca utilización de los recursos
computacionales del mismo, esto debido en parte a la cantidad de usuarios del
servicio y al uso exclusivo del hardware para cumplir esta función únicamente, y
por otra parte, a la capacidad de los clientes de correo electrónico y servidor de
correo de guardar en cache, las consultas realizadas con anterioridad al servicio
de directorio. Este servidor podría ser utilizado también en otras funciones para
aprovechar el poder de cómputo disponible del mismo.
Capítulo 6: Conclusiones
85
6 CONCLUSIONES
Los resultados obtenidos en el desarrollo del presente Trabajo Especial de Grado
conllevan a destacar las siguientes conclusiones:
Ø Se cumplieron con los objetivos del trabajo especial de grado al
seleccionarse y configurarse exitosamente, los servidores SMTP, IMAP y
LDAP para implementar el sistema de correos electrónicos integrado con
servicios de directorio, lográndose satisfacer los requerimientos generales
que presentan los organismos, siendo éstos: el envío y recepción de
correos electrónicos, el acceso a los correos almacenados, la autenticación
y manejo de la lista de contactos de manera centralizada, entre otros.
Ø Actualmente, el software libre permite implementar en los organismos, un
conjunto de sistemas que pueden igualar o hasta superar soluciones
propietarias equivalentes.
Ø El usar tecnologías libres permite la construcción de sistemas sumamente
amplios y complejos, según sean las necesidades particulares.
Ø Los programas software libre no necesitan de hardware de última línea para
poder implementar servicios con niveles de calidad aceptables, dando la
posibilidad de ser escalados si las condiciones lo ameritan.
Ø Se implementó de manera exitosa un sistema en software libre para el
manejo de correos electrónicos que es capaz de funcionar en un ambiente
de producción y se creó un método para su implementación, que permite
satisfacer las necesidades de manejo de correo electrónico para la mayoría
de los organismos.
Ø En base al éxito obtenido, luego de instanciado el método propuesto y
adaptado a las necesidades particulares del IGVSB, se hace posible
proponer su implementación en ambientes donde la cantidad de usuarios e
información sea mayor, para así probar ambientes con interacciones más
complejas y medir las capacidades de expansión del sistema.
6.1 Recomendaciones
La solución del sistema de manejo de correos electrónicos con software libre
propuesta en el presente Trabajo Especial de Grado fue instanciada para cumplir
con los requerimientos específicos del organismo donde se realizó el caso de
estudio (IGVSB).
Capítulo 6: Conclusiones
86
En base a los exitosos resultados, se desarrollan a continuación, unas
recomendaciones para mejorar el método propuesto e implementar la solución a
una escala más amplia y con la capacidad de ofrecer mayor cantidad de servicios
según las necesidades del organismo.
Las recomendaciones se realizan a través de las siguientes consideraciones:
Para soportar conexiones seguras entre los distintos componentes del sistema,
sería importante implementar un servidor de certificados, para así generar los
certificados que pudieran requerir los componentes del sistema.
Conseguir herramientas que permitan la administración del servicio de directorio
de manera gráfica y sencilla.
Integrar al servicio de directorio, sistemas como: la mensajería instantánea, para
así igualarlo a soluciones propietarias, como: Microsoft Exchange.
Añadir al sistema un servicio de Groupware, aprovechando el uso de tecnologías
abiertas.
Dar una inducción a los usuarios de los organismos para que hagan un uso más
racional y eficiente del servicio de correo electrónico.
En relación al caso de estudio es aconsejable configurar un servicio para la
replicación del directorio, además de definir el respectivo plan de respaldo y
recuperación de la información que manejan los componentes del sistema.
Bibliografía
87
7 BIBLIOGRAFÍA
[1] J. Klensin. Simple Mail Transfer Protocol. The Internet Engineering Task
Force. RFC 2821. Abril 2001.
[2] M. Crispin. Internet Message Access Protocol. The Internet Engineering Task
Force. RFC 3501. Marzo 2003.
[3] J. Myers, M. Rose. Post Office Protocol – Version 3. The Internet Engineering
Task Force. RFC 1939. Mayo 1996.
[4] Lotus. http://www-306.ibm.com/software/lotus.
[5] Microsoft Exchange 2007. http://www.microsoft.com/exchange/default.mspx.
[6] K. Zeilenga. Lightweight Directory Access Protocol. The Internet Engineering
Task Force. RFC 4510. Junio 2006.
[7] Decreto Nº 3.390. Publicado en la gaceta oficial Nº 38.095 el 28/12/2004.
[8] D. Word, M. Stone. Programming Internet Email. O’Reilly Media Inc. Primera
edición. Agosto 1993.
[9] K. Dent. Postfix: The Definitive Guide. O’Reilly Media Inc. Primera edición.
Diciembre 2003.
[10] Mail (MX) Server Survey. Security Space.
http://www.securityspace.com/s_survey/data/man.200708/mxsurvey.html.
[11] R. Blum. Open Source E-Mail Security. Sams. Primera edición. Octubre 2001.
[12] T. Howes, M. Smith, G. Good, T. Howes. Understanding and Deploying LDAP
Directory Services. Addison-Wesley. Segunda edición. Mayo 2003.
[13] Ley de Geografía, Cartografía y Catastro Nacional. Publicada en la gaceta
oficial Nº 36.920. Publicada el 28 de marzo de 2000.
[14] E. Sieber, A. Weber, S. Figgins, R. Love, A. Robbins. Linux In a Nutshell.
O’Reilly Media. Quinta edición. Julio 2005.
[15] Linux and IBM. http://www-03.ibm.com/linux.
[16] HP Open Source and Linux – HP and Debian GNU/Linux.
http://activeanswers.compaq.com/enterprise/cache/390110-0-0-0-121.html.
Bibliografía
88
[17] Linux Operating Systems: SUSE Linux Enterprise. http://www.novell.com/linux.
[18] Why Open Source Software. http://www.dwheeler.com/oss_fs_why.html.
[19] B. McCarty. Learning Debian GNU/Linux. O’Reilly Media. Primera edición.
Octubre 1999.