Tema 3: Servidores de correo. Contenedores y microservicios

Servidores de correo electrónico y sus protocolos

Un sistema de correo electrónico distingue dos funciones básicas: el envío de mensajes (correo saliente) y la recepción/consulta de mensajes (correo entrante). Cada función la gestiona un protocolo distinto de la familia TCP/IP: SMTP para el correo saliente y POP3 o IMAP para el correo entrante. Conviene tener claro que SNMP (Simple Network Management Protocol) NO es un protocolo de correo electrónico, sino de gestión de red.

SMTP (Simple Mail Transfer Protocol)

SMTP es el protocolo de correo saliente: se emplea para enviar mensajes desde un cliente a un servidor de correo y, sobre todo, para transferirlos de un servidor a otro a través de Internet. Está definido en la RFC 5321 (que actualiza la RFC 2821). En un envío completo, SMTP se usa desde el ordenador del usuario de origen hasta el servidor de origen y de este al servidor de destino; después, POP3 o IMAP entregan el mensaje desde el servidor de destino al ordenador del destinatario cuando este se conecta.

Puertos SMTP:

El protocolo STARTTLS en SMTP permite negociar una capa de cifrado TLS sobre una conexión existente, proporcionando una forma segura de transmitir el correo por Internet sin necesidad de un puerto dedicado a SSL implícito.

Comandos SMTP principales:

• HELO / EHLO: inician la sesión. EHLO es el comando recomendado para abrir una sesión en servidores que admiten extensiones ESMTP (RFC 2821/5321); HELO es la forma clásica.

• MAIL FROM: indica el remitente.

• RCPT TO: indica el destinatario del mensaje.

• DATA: anuncia el comienzo del cuerpo del mensaje. Si se acepta, el servidor responde con un mensaje intermedio 354 que indica que puede iniciarse el envío del cuerpo (termina con <CRLF>.<CRLF>).

• AUTH: permite autenticarse en el servidor de correo.

• RSET: reinicia la transacción; NOOP, QUIT, VRFY: sin operación, cierre y verificación.

La secuencia típica de una sesión SMTP simple según la RFC 2821 es: HELO, MAIL FROM, RCPT TO, DATA.

Según la RFC 5321 (sección 4.5.1), una implementación mínima debe tener implementados en todos los receptores los comandos: EHLO, HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT, VRFY.

Códigos de respuesta SMTP (numéricos de tres dígitos):

POP3 (Post Office Protocol v3)

POP3 es un protocolo de correo entrante. Se pone en contacto con el servicio de correo y descarga todos los mensajes nuevos en el dispositivo del cliente, y puede eliminarlos del servidor tras la descarga. Su modelo natural reduce el uso de espacio en el servidor, pero está pensado para un único dispositivo.

• Puerto por defecto: 110 (sin cifrar). Con SSL/TLS (POP3S): puerto 995.

• Configurando la opción de "mantener copia en el servidor", POP3 permite descargar los mismos correos en varios dispositivos configurados con la misma cuenta.

• Comandos: STAT (devuelve el número de mensajes en el servidor y el total que ocupan en bytes), RSET (resetea la sesión), LIST, RETR, DELE, QUIT.

IMAP (Internet Message Access Protocol)

IMAP es un protocolo de correo entrante orientado a mantener los mensajes en el servidor. Permite gestionar y manipular los mensajes directamente en el servidor sin necesidad de descargarlos, y acceder a los correos desde múltiples ubicaciones/dispositivos sin eliminarlos del servidor, manteniéndolos sincronizados con el cliente. Esta es su principal ventaja frente a POP3, que descarga localmente.

• Puerto por defecto: 143.

• IMAP sobre TLS / IMAP4-SSL (IMAPS): puerto 993 (TCP).

• Comandos: SUBSCRIBE (suscribirse a una carpeta específica del servidor), SELECT, FETCH, STORE, SEARCH, etc.

Diferencia clave POP3 vs IMAP: POP3 descarga los correos al dispositivo local (gestión offline, ahorro de espacio en servidor); IMAP los mantiene y gestiona en el servidor, sincronizándolos entre múltiples clientes.

Seguridad en la transmisión

Para garantizar confidencialidad se emplean las variantes cifradas: POP3S e IMAPS, que son los protocolos clásicos encapsulados en túneles de cifrado SSL/TLS. Es importante distinguir: TLS cifra la comunicación en tránsito, pero NO el contenido del mensaje en origen. Para cifrar el propio contenido de extremo a extremo se usa S/MIME (envío de correo seguro con firma y cifrado).

Microsoft Exchange Server y Exchange ActiveSync

Microsoft Exchange Server es un servidor de correo electrónico al que puede accederse mediante un navegador web (Outlook on the web/OWA) y que es compatible con aplicaciones cliente como Microsoft Outlook. Ofrece correo, calendario y contactos, pero NO proporciona funcionalidades ajenas al correo como la administración de acceso remoto seguro a archivos del sistema operativo.

Exchange ActiveSync (EAS) es un protocolo cliente de sincronización basado en HTTP y XML que permite a los dispositivos móviles sincronizar su buzón (correos, calendario, contactos) alojado en servidores Exchange, incluso trabajando sin conexión. Características relevantes:

• Soporta mensajes en formato HTML.

• Está basado en HTTP y XML (NO en JSON): es FALSO afirmar que reduce el peso de los mensajes empleando JSON.

Fuentes

• IETF RFC 5321, Simple Mail Transfer Protocol (comandos, implementación mínima §4.5.1, códigos de respuesta): https://datatracker.ietf.org/doc/html/rfc5321

• IETF RFC 2821, Simple Mail Transfer Protocol (EHLO/ESMTP, secuencia): https://datatracker.ietf.org/doc/html/rfc2821

• IETF RFC 1939, Post Office Protocol - Version 3 (comandos STAT, RSET): https://datatracker.ietf.org/doc/html/rfc1939

• IETF RFC 3501, Internet Message Access Protocol - Version 4rev1: https://datatracker.ietf.org/doc/html/rfc3501

• IANA Service Name and Transport Protocol Port Number Registry (puertos 25, 110, 143, 465, 587, 993, 995): https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

• Microsoft Learn, Exchange Server y Exchange ActiveSync: https://learn.microsoft.com/en-us/exchange/clients/exchange-activesync/exchange-activesync

Administración de servidores de correo electrónico y sus protocolos

La administración de correo electrónico abarca la configuración, el mantenimiento y la seguridad de los servidores que transportan, entregan y almacenan mensajes, así como la gestión de los mecanismos de autenticación que evitan la suplantación (spoofing) y el correo no solicitado. Un servidor de correo combina normalmente un MTA (Mail Transfer Agent, p. ej. Postfix, Exim, Sendmail) que enruta el correo entre dominios, un MDA (Mail Delivery Agent, p. ej. Dovecot) que lo entrega al buzón, y el MUA (Mail User Agent) del usuario final.

Protocolos básicos de correo

• SMTP (Simple Mail Transfer Protocol) es un protocolo de envío: transfiere el mensaje del cliente al servidor y de un servidor a otro. Su extensión ESMTP añade autenticación (AUTH) y cifrado oportunista mediante el comando STARTTLS.

• POP3 descarga los mensajes y, por defecto, los elimina del servidor, siendo adecuado para un único dispositivo.

• IMAP mantiene los mensajes en el servidor y sincroniza carpetas y estados entre múltiples dispositivos, siendo hoy la opción preferida.

El DNS es esencial en la administración de correo: los registros MX (Mail eXchanger) indican qué servidores reciben el correo de un dominio, ordenados por prioridad.

Autenticación de correo: SPF, DKIM y DMARC

Para combatir la falsificación del remitente, la administración de correo se apoya en tres mecanismos complementarios publicados como registros DNS.

SPF (Sender Policy Framework)

El SPF, definido en el RFC 7208, es un mecanismo de autenticación cuyo propósito principal es comprobar que el correo proviene de una dirección IP autorizada por el dominio del remitente. En otras palabras, los registros SPF indican los servidores de correo autorizados a enviar correo en nombre de un dominio determinado.

Características clave:

• Se publica como un registro DNS de tipo TXT en la zona del dominio (el tipo de registro SPF propio quedó obsoleto).

• La cadena comienza con el identificador de versión v=spf1, seguida de mecanismos (ip4, ip6, a, mx, include, all) y cualificadores.

• Los cualificadores determinan el resultado: + (Pass, autorizado), - (Fail, rechazar), ~ (SoftFail, aceptar pero marcar) y ? (Neutral).

• El servidor receptor consulta la IP del emisor (identidad MAIL FROM o HELO) contra el registro SPF del dominio; si la IP no está autorizada, puede rechazar el mensaje antes de recibir el cuerpo.

Ejemplo de registro: v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all. Aquí solo el rango indicado y los servidores de Google están autorizados; el resto se marca como fallo (-all).

DKIM (DomainKeys Identified Mail)

Definido en el RFC 6376, DKIM añade a cada mensaje una firma criptográfica en una cabecera (DKIM-Signature) generada con una clave privada del dominio emisor. El receptor recupera la clave pública desde un registro DNS TXT del dominio y verifica que el mensaje no ha sido alterado y que procede del dominio firmante. Aporta integridad y autenticación de dominio, complementando a SPF.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Especificado en el RFC 7489, DMARC se apoya en SPF y DKIM: define, mediante un registro DNS TXT (v=DMARC1), la política que debe aplicar el receptor cuando un mensaje no supera la autenticación (p=none, p=quarantine, p=reject) y establece el requisito de alineación (alignment) entre el dominio del From visible y los dominios validados por SPF/DKIM. Además genera informes agregados y forenses.

Cifrado y firma de mensajes: S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions), en su versión 4.0 definida por el RFC 8551 y basado en la sintaxis criptográfica CMS (derivada de PKCS #7), proporciona seguridad de extremo a extremo al propio mensaje, empleando certificados X.509 de una infraestructura de clave pública (PKI). Ofrece cuatro servicios de seguridad:

• Autenticación del remitente.

• Integridad del mensaje (garantía de no alteración).

• No repudio de origen, mediante firma digital.

• Confidencialidad de los datos, mediante cifrado.

Es fundamental distinguir sus dos operaciones:

• La firma digital proporciona autenticación, integridad y, sobre todo, no repudio: como la firma se genera con la clave privada del remitente (que solo él posee), este no puede negar haber enviado el correo. Esta es precisamente la característica de S/MIME que asegura que el remitente no pueda negar haber enviado un mensaje.

• El cifrado (con la clave pública del destinatario) proporciona confidencialidad, no repudio.

En resumen: mientras SPF, DKIM y DMARC autentican el dominio y el trayecto del correo a nivel de transporte, S/MIME protege el contenido del mensaje y vincula jurídicamente al firmante mediante criptografía asimétrica.

Fuentes

• IETF — RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1: https://datatracker.ietf.org/doc/html/rfc7208

• IETF — RFC 8551, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification: https://datatracker.ietf.org/doc/html/rfc8551

• IETF — RFC 6376, DomainKeys Identified Mail (DKIM) Signatures: https://datatracker.ietf.org/doc/html/rfc6376

• IETF — RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC): https://datatracker.ietf.org/doc/html/rfc7489

• IETF — RFC 5321, Simple Mail Transfer Protocol (SMTP): https://datatracker.ietf.org/doc/html/rfc5321

• RFC Editor — Información RFC 7208: https://www.rfc-editor.org/info/rfc7208/

Contenedores: concepto y virtualización a nivel de sistema operativo

Un contenedor es una unidad estándar de software que empaqueta el código de una aplicación junto con todas sus dependencias (bibliotecas, binarios, ficheros de configuración y entorno de ejecución) de forma que la aplicación se ejecute de manera rápida y fiable en cualquier entorno. Los contenedores son la expresión práctica de la llamada virtualización a nivel de sistema operativo (OS-level virtualization): en lugar de virtualizar el hardware completo, se aíslan procesos que comparten el mismo núcleo (kernel) del sistema operativo anfitrión, empleando mecanismos del propio kernel como namespaces (aislamiento) y cgroups (control de recursos) en Linux.

Esta aproximación contrasta con la virtualización tradicional basada en máquinas virtuales (VM), donde un hipervisor emula hardware y cada VM incluye su propio sistema operativo invitado completo. Al no arrastrar un sistema operativo por cada instancia, el contenedor es mucho más ligero.

Docker

Docker es la plataforma de contenedores más extendida. Es una herramienta de virtualización a nivel de sistema operativo que permite empaquetar y distribuir aplicaciones junto con todas sus dependencias en contenedores. Su objetivo principal es facilitar el despliegue de aplicaciones en contenedores de software, estandarizando el modo en que una aplicación se construye, se distribuye y se ejecuta.

Docker introduce una capa de abstracción entre la aplicación y la infraestructura subyacente. El propósito de esa abstracción es aumentar la portabilidad de las aplicaciones: una imagen de contenedor se ejecuta igual en el portátil del desarrollador, en un servidor de pruebas o en la nube, sin las diferencias de entorno que producen el clásico problema de "en mi máquina funciona".

Ventajas frente a la virtualización tradicional

La principal ventaja de Docker frente a la virtualización tradicional es la eficiencia en el uso de los recursos del sistema. Como los contenedores comparten el kernel del anfitrión y no replican un sistema operativo completo por instancia:

• Consumen menos memoria y CPU que las máquinas virtuales equivalentes.

• Arrancan en segundos (o milisegundos), frente a los minutos de una VM.

• Ocupan menos espacio en disco, al reutilizar capas de imagen comunes.

• Permiten una densidad mucho mayor (más aplicaciones por servidor físico).

Ecosistema de contenerización

Docker no es la única tecnología de contenedores. Entre las tecnologías relacionadas con la contenerización y la gestión de contenedores destacan Docker, containerd y Podman:

• Docker: plataforma completa (CLI, motor y formato de imagen) que popularizó los contenedores.

• containerd: runtime de contenedores de bajo nivel, proyecto de la CNCF, encargado de gestionar el ciclo de vida completo del contenedor (imágenes, ejecución, almacenamiento, red). Es el motor que utiliza internamente Docker y también Kubernetes.

• Podman: motor de contenedores sin demonio (daemonless) y con soporte rootless, compatible con la Open Container Initiative (OCI) y con una interfaz de comandos muy similar a la de Docker.

Todos estos motores se apoyan en los estándares de la OCI (Open Container Initiative), que definen las especificaciones de imagen, de ejecución (runtime) y de distribución, garantizando la interoperabilidad y la portabilidad de las imágenes entre distintas herramientas.

El comando docker run

El comando docker run es la instrucción fundamental de Docker: crea e inicia un nuevo contenedor, descargando la imagen si es necesario, y ejecuta en el contenedor un comando especificado. Formalmente, docker run crea una capa de contenedor escribible sobre la imagen indicada y a continuación la arranca; equivale a encadenar las operaciones de creación (docker create) y de arranque (docker start) del contenedor.

Su sintaxis básica es:

Si la imagen indicada no está disponible localmente, Docker la descarga automáticamente desde el registro (por defecto Docker Hub) antes de crear el contenedor. Es el comando con más opciones de todo Docker, permitiendo configurar red, volúmenes de almacenamiento, variables de entorno, límites de recursos y parámetros de seguridad.

Contenedores en el sistema: Vanilla OS y Apx

La filosofía de contenedores también se aplica al propio sistema operativo. Vanilla OS es una distribución Linux inmutable que gestiona la implementación (instalación) de software mediante contenedores controlados por Apx para reducir conflictos y peligros para el sistema.

Apx es el gestor de paquetes por defecto de Vanilla OS: actúa como envoltorio (wrapper) sobre varios gestores de paquetes e instala el software dentro de uno o más contenedores gestionados, sin alterar el sistema de ficheros raíz. De este modo, el sistema base permanece limpio e inmutable y se minimiza el riesgo de rotura por paquetes incompatibles, mal construidos o en conflicto, a la vez que las aplicaciones contenerizadas siguen pudiendo usar los mismos controladores, servidor gráfico y recursos del sistema. Apx utiliza motores de contenedores como Podman (recomendado) o Docker por debajo.

Fuentes

• Docker Docs — docker container run (CLI reference): https://docs.docker.com/reference/cli/docker/container/run/

• Docker Docs — Running containers: https://docs.docker.com/engine/containers/run/

• Podman — What is Podman? (documentación oficial): https://docs.podman.io/

• containers/Podman — repositorio oficial (OCI, daemonless): https://github.com/containers/podman

• Vanilla OS Documentation — Apx (introducción y funcionamiento): https://docs.vanillaos.org/docs/en/apx

• Vanilla-OS/apx — repositorio oficial: https://github.com/Vanilla-OS/apx

• Open Container Initiative (OCI) — especificaciones de imagen, runtime y distribución: https://opencontainers.org/

Orquestación y microservicios

Qué es la arquitectura de microservicios

La arquitectura de microservicios es un estilo de diseño de software en el que las aplicaciones se descomponen en pequeños servicios independientes que se comunican entre sí mediante API (habitualmente REST/HTTP, gRPC o mensajería asíncrona). Cada uno de estos servicios es autónomo, se despliega por separado y es responsable de una tarea específica o de una capacidad de negocio concreta. Se opone al modelo monolítico, donde toda la funcionalidad reside en un único artefacto desplegable.

Una característica común es, por tanto, que cada servicio es responsable de una tarea específica, con su propio ciclo de vida, su base de datos (patrón database per service) y, con frecuencia, tecnologías heterogéneas.

Ventajas

• Escalabilidad independiente: cada servicio se escala según su demanda sin replicar toda la aplicación.

• Mayor tolerancia a fallos en comparación con la arquitectura monolítica: el fallo de un microservicio puede aislarse (mediante circuit breakers, timeouts, bulkheads) sin derribar el sistema completo.

• Despliegue continuo y ciclos de entrega más cortos por servicio.

• Autonomía tecnológica de los equipos.

Inconvenientes y dificultades

Los microservicios no son una solución ideal para resolver todos los problemas de escalabilidad (afirmación falsa clásica): introducen coste y complejidad que no siempre compensan. Entre las principales dificultades y desventajas destaca la mayor complejidad en el proceso de desarrollo: sistemas distribuidos, comunicación por red, consistencia eventual, observabilidad, gestión de configuración, seguridad entre servicios y necesidad de una robusta automatización (CI/CD y contenedores).

Buenas prácticas de diseño

• Dividir los servicios en función de la lógica de negocio y de las entidades de negocio que manejan (alineados con los bounded contexts del Domain-Driven Design), buscando alta cohesión y bajo acoplamiento. La descomposición por capacidad/entidad de negocio evita servicios anémicos o excesivamente acoplados.

• Diseñar servicios pequeños y autónomos, con contratos de API bien definidos y versionados.

• Automatizar despliegue y pruebas; instrumentar logging, métricas y trazas distribuidas.

Composición: coreografía y orquestación

Las funcionalidades se implementan mediante la composición de varios microservicios. Existen dos estrategias para gestionar esa composición:

• Orquestación: un componente central (el orquestador) coordina y dirige explícitamente las llamadas a los distintos servicios, controlando el flujo del proceso de negocio.

• Coreografía: no hay coordinador central; cada servicio reacciona a eventos publicados por otros (típicamente sobre un bus de eventos), colaborando de forma descentralizada.

Ambas son las dos aproximaciones habituales al patrón Saga para transacciones distribuidas: coreografía y orquestación.

Patrones de infraestructura: gateway y balanceo de carga

• API Gateway: es un componente que actúa como intermediario entre los clientes y los servicios. Ofrece un único punto de entrada y centraliza responsabilidades transversales: enrutamiento, autenticación y autorización, rate limiting, agregación de respuestas, terminación TLS y traducción de protocolos. Evita que el cliente conozca la topología interna de servicios.

• Balanceo de carga (load balancing): es un proceso que permite distribuir la carga de trabajo entre los diferentes servicios (o entre las réplicas de un mismo servicio), mejorando el rendimiento, la disponibilidad y la tolerancia a fallos.

Orquestación de contenedores: Kubernetes

Kubernetes (K8s) es la plataforma de referencia para orquestar contenedores. Fue creado originalmente por Google (inspirado en su sistema interno Borg) y donado en 2015 a la Cloud Native Computing Foundation (CNCF). Su objetivo principal es automatizar el despliegue —así como el escalado y la gestión— de aplicaciones en contenedores.

Plano de control (Control Plane)

El plano de control gobierna el estado del clúster. Sus componentes principales son:

Por tanto, el componente del plano de control responsable de decidir en qué nodo debe ejecutarse un Pod basándose en los recursos disponibles es el kube-scheduler.

Componentes de nodo

En cada nodo worker se ejecutan: el kubelet (agente que garantiza que los Pods y sus contenedores están en ejecución), el kube-proxy (mantiene las reglas de red que implementan los Services) y el runtime de contenedores (containerd, CRI-O, etc.).

Objetos básicos de Kubernetes

Los objetos básicos de Kubernetes son Pod, Service, Volume y Namespace:

• Pod: unidad de despliegue más pequeña; agrupa uno o varios contenedores que comparten red y almacenamiento.

• Service: abstracción que expone un conjunto de Pods bajo una dirección estable y balancea el tráfico entre ellos.

• Volume: mecanismo de almacenamiento asociado a los Pods.

• Namespace: partición lógica del clúster para aislar recursos.

Sobre ellos se construyen objetos de nivel superior (controllers) como Deployment, ReplicaSet, StatefulSet, DaemonSet o Job.

Estructura de un objeto: el campo metadata

Todo objeto de Kubernetes se describe con cuatro campos requeridos: apiVersion, kind, metadata y spec. El campo en el que hay que incluir los valores que permiten identificar unívocamente al objeto es metadata, que contiene entre otros el name, el UID (identificador único asignado por el sistema) y el namespace. Además, spec describe el estado deseado y status (gestionado por el sistema) el estado actual.

Fuentes

• Kubernetes — Components (plano de control y nodos): https://kubernetes.io/docs/concepts/overview/components/

• Kubernetes — Understanding Kubernetes Objects (campos requeridos y metadata): https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/

• Kubernetes — kube-scheduler: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/

• CNCF / Kubernetes — historia y origen (Google/Borg): https://kubernetes.io/blog/

• Microsoft Learn — Microservices architecture / API Gateway pattern: https://learn.microsoft.com/azure/architecture/microservices/

• Microsoft Learn — Saga pattern (orquestación y coreografía): https://learn.microsoft.com/azure/architecture/reference-architectures/saga/saga