Prefacio:

Tal y como dice el títlulo, esta entrada que iré dividiendo en varias entregas para hacerla lo menos monótona de leer posible intentará explicar desde de la base como funciona un servidor de correo electrónico, su implementación en linux y por que es tan complicado de hacer para el usuario de a pié.

Todo lo que mas abajo transcribo se basa pura y exclusivamente en mi experiencia personal. Mi servidor de correo funciona en Gentoo, mi distribución favorita. Todos los comandos salvo quizás por el gestor de paquetes, trataré de hacerlos lo mas genérico posibles para que sean aplicables a cualquier versión de Linux.

Esta guía usará a tal efecto el par Postfix / Dovecot para transporte, postfixadmin para administración del servidor y MySQL como medio de almacenamiento del correo electrónico entrante y saliente.

Para toda la sección de configuración me basaré principalmente en la exelente guía de la Wiki de Gentoo.

Breve reseña histórica:

Todos los servidores de correo electrónico se comunican entre sí usando el protocolo SMTP que escucha en el puerto 25 TCP.

De por sí este protocolo no está pensado teniendo en cuenta la seguridad, no viaja encriptado, no conoce de nombres de usuario y contraseña ni ningún tipo de autenticación cuando se trata de comunicación servidor-servidor y hasta cierto punto, tiene lógica.

Como funciona el sistema básicamente:

• Si [email protected] necesita enviar un correo electrónico a [email protected], juan se conecta usando el protocolo SMTP (esta vez autenticado) al servidor de correo de dominio1.com.
• Dominio1.com verifica que juan es quien dice ser por medio del nombre de usuario y contraseña y de ser así recibe el mensaje.
• Cuando juan se desconecta, el servidor dominio1.com se comunica con el servidor dominio2.com de nuevo usando el protocolo SMTP pero esta vez, sin ningún tipo de autenticación. Miles de servidores de correo electrónico en todo el mundo, pertenecientes a dominios diferentes a dominio1.com no pueden conocer cual es la contraseña de juan en su servidor, esto crearía una brecha de seguridad importantísima, entonces, ¿Como lo hacen?
• Simple. Una vez establecida la conexión entre el servidor de email de dominio1.com y dominio2.com el  servidor en dominio1 dice: Este soy yo, la autoridad en dominio1.com. Uno de mis usuarios cuya casilla de correo es [email protected] necesita que este mensaje que transcribo a continuación sea entregado al usuario jose, miembro de su dominio2.com. (Esto es lo que se conoce como el handshake, darse la mano en inglés).
• El servidor de dominio2.com revisa su lista de usuarios a continuación en busca de uno que se identifique como jose. En este punto pueden ocurrir tres cosas:

1. El usuario existe, el mensaje se entrega y se informa de esto al servidor que inició la conexión (en este caso, dominio1.com).
2. El usuario no existe, se informa al servidor de dominio1.com de esto y el mensaje es devuelto (bounced, rebotado).
3. El usuario no existe, se notifica al servidor dominio1.com que el mensaje es entregado pero este va a parar a la casilla de correo catch-all del administrador del dominio.

En cualquiera de los tres casos anteriores, puede dispararse alguno de los mecanismos de seguridad que describo mas adelante y hacer que el email sea devuelto/rebotado.

Dado que cualquiera podría montar su propio servidor de correo electrónico y decir: «Este soy yo, la autoridad en dominio1.com» aun que no lo sea, sería muy facil suplantar la identidad de cualquier persona a la hora de enviar un correo electrónico (De hecho, lo fué en su momento, y al día de hoy todavía es posible hacerlo contra ciertos servidores de correo mal configurados.)

Para evitar esto han surgido varias soluciones. De alguna manera u otra, todos los servidores de correo electrónico se tienen que conocer entre si, pero sin usar autenticación. La mayoría de las soluciones se basan en registros TXT montados sobre el servidor de nombres que atiende al dominio en cuestión.

Las tres soluciones mas usadas son: Sender Policy Frmaework o SPF, DomainKeys (Que dejará de estar en vigencia en poco tiempo) y la versión mejorada de Domainkeys: DKIM.

Todo servidor de correo electrónico que se precie, necesita tener como mínimo implementado SPF y DKIM.

El sistema se basa en la seguridad del conocimiento de que quien tenga el control sobre el DNS del dominio es el único que puede decidir cuales son los servidores autorizados a enviar correo electrónico a su nombre. Cualquier servidor de correo electrónico que no esté habilitado para enviar email en nombre de dominio1.com no figurará en los TXT records de dominio1.com con lo que suplantar su identidad se vuelve imposible.

DomainKeys y DKIM por otro lado, van mas allá y le agregan una firma digital de seguridad encriptada a todo el asunto, con lo que aún que un usuario mal intencionado se hiciera con el control de los DNS del dominio, no podría enviar correo electrónico en su nombre por carecer de la firma de seguridad en cuestión.

Transacción no autenticada entre servidores SMTP

En definitiva, esto es lo que ocurre cada vez que enviamos un mail:

• El servidor en dominio1.com se conecta a dominio2.com como ya vimos antes y le informa: «Este soy yo, la autoridad en dominio1.com«.
• El servidor de dominio2.com no se lo traga así como así y verifica que esto sea cierto.
• Consulta el MX record para el domino en busca de el número de IP del servidor de correo electrónico.
• Una vez obtenido el número de IP verifica el registro TXT para SPF verificando si este número de IP se encuentra mencionado en el mismo.
• Si lo anterior es positivo, entonces aparentemente el servidor de correo electrónico es quien dice ser:  El número de IP desde donde se origina la conexión es el mismo del registro MX y se encuentra mencionado en el registro SPF.
• Lo siguiente que se verificará será la firma digital de DomainKeys o DKIM (o ambos) si la hubiera.
• Si todavía todo esto es positivo, se verifica que el número de IP desde donde se inició la conexión no figure listado en ninguna de las RBL o lista negra de servidores conocidos por hacer SPAM.

Una vez que todos los chequeos anteriores son positivos, el mensaje se entrega en la bandeja de entrada del destinatario.

Si alguno de los ítems anteriores no es positivo, o bien el mensaje será rebotado o el filtro anti SPAM del servidor de correo electrónico lo marcará como correo basura e irá a parar a la sección «correo no deseado» o simplemente será eliminado.

Es muy común que se verifique además que el banner del servidor SMTP se corresponda con el registro PTR para el número de IP que origina la conexión. Este último ítem, el PTR Record es lo que hace imposible para un usuario común y silvestre hacerse de su propio servidor de correo electrónico sin haber pagado por un servicio de conexión corporativo o similar.

Algunos servidores, –hotmail por ejemplo-, implementan además un sistema de ranking interno: Cuanto mayor sea la cantidad de usuarios que marquen al correo enviado desde un dominioX como «esto no es correo basura«, menor será la posibilidad de que un email originado en este dominio vaya a parar a la sección «correo no deseado«.

Este sistema de ranking interno como todos sabrán no funciona en absoluto. Mensajes vendiendo viagra se saltean todas las protecciones habidas y por haber y llegan derechito a la bandeja de entrada de hotmail.

Eso fué a groso modo, una explicación didáctica del principio de funcionamiento.

En la próxima entrega vamos directamente a la instalación y configuración del software para que todo esto funcione.