RFC 5598 – Arquitectura de Correo de Internet
Por qué existe este RFC
Antes de RFC 5598, la comunidad de correo electrónico utilizaba términos como "MTA", "relay" y "gateway" de manera flexible e inconsistente. Diferentes RFC utilizaban terminología diferente para los mismos conceptos. Esto creó una confusión real, especialmente cuando mecanismos de autenticación como SPF, DKIM y DMARC necesitaban definiciones precisas de quién hacía qué en la ruta del mensaje.
Publicado en 2009 por Dave Crocker, RFC 5598 proporciona un modelo arquitectónico integral para correo electrónico de internet. No es una especificación de protocolo — no define ningún nuevo formato de cable ni comandos. En cambio, es un marco de referencia que nombra y define cada actor, rol y función en el ecosistema de correo electrónico. Casi todos los RFC modernos de correo electrónico hacen referencia a la terminología de 5598.
Cómo funciona
RFC 5598 divide el sistema de correo electrónico en componentes funcionales distintos organizados alrededor del viaje del mensaje desde el autor al destinatario.
Los cuatro entornos principales
La arquitectura define cuatro entornos operacionales a través de los cuales pasa un mensaje:
- Entorno del agente de usuario de correo (MUA): Donde el usuario compone y lee mensajes. Tu cliente de correo electrónico — Gmail, Outlook, Thunderbird, o tu aplicación llamando a una API.
- Entorno del agente de envío de correo (MSA): El servicio que acepta mensajes de un MUA para entregarlos en el sistema de correo. Opera en el puerto 587 según RFC 6409, requiere autenticación.
- Entorno del agente de transferencia de correo (MTA): La infraestructura de enrutamiento central. Los MTA retransmiten mensajes a través de internet usando SMTP (RFC 5321) en el puerto 25.
- Entorno del agente de entrega de correo (MDA): El sistema final que coloca el mensaje en el buzón del destinatario, haciéndolo disponible a través de IMAP, POP3 o webmail.
El flujo de mensajes
Actores y roles clave
| Actor | Abreviatura | Rol |
|---|---|---|
| Agente de usuario de correo | MUA | Compone y muestra mensajes para el usuario. El cliente de correo electrónico. |
| Agente de envío de correo | MSA | Acepta mensajes de MUA autenticados, aplica políticas e los inyecta en la infraestructura de MTA. |
| Agente de transferencia de correo | MTA | Enruta y retransmite mensajes entre dominios usando SMTP. La "columna vertebral" del correo electrónico. |
| Agente de entrega de correo | MDA | Entrega final en el buzón del destinatario. Puede aplicar reglas de filtrado. |
| Almacén de correo | MS | Almacena mensajes y proporciona acceso a través de IMAP/POP3/JMAP. |
Tipos de identidad
RFC 5598 distingue cuidadosamente las diferentes identidades asociadas con un mensaje:
| Identidad | Dónde aparece | Qué significa |
|---|---|---|
| Autor |
From: encabezado |
La persona o entidad que escribió el mensaje |
| Remitente |
Sender: encabezado |
El agente que realmente transmitió el mensaje (cuando es diferente del autor) |
| Return-Path |
MAIL FROM sobre / Return-Path: encabezado |
Dónde deben enviarse los rebotes; la parte responsable del transporte |
| Destinatario |
RCPT TO sobre / To:/Cc: encabezados |
Los destinatarios previstos |
Esta distinción importa enormemente para la autenticación. SPF valida la identidad de Return-Path. DKIM puede firmar en nombre del Autor o un intermediario. DMARC alinea la identidad del Autor con los resultados de SPF y DKIM.
Detalles técnicos clave
Mediadores
RFC 5598 identifica una categoría crucial de actores llamados mediadores — entidades que reciben un mensaje y luego lo vuelven a publicar, potencialmente modificándolo en el camino:
-
Lista de correo: Recibe un mensaje, añade encabezados de lista, posiblemente modifica el asunto o cuerpo, y redistribuye a los suscriptores. La lista se convierte en el nuevo remitente de
MAIL FROM. - Pasarela: Convierte entre correo electrónico y otro sistema de mensajería (por ejemplo, correo electrónico a SMS, correo electrónico a fax).
- Reenviador/Redistribuidor: Reenvía o redistribuye correo, como direcciones de reenvío de ex alumnos.
Los mediadores son la razón principal por la que la autenticación de correo electrónico es compleja. Cuando una lista de correo cambia el remitente del sobre y modifica el mensaje, SPF se rompe (la nueva IP del remitente no está autorizada para el dominio original) y DKIM puede romperse (el cuerpo fue modificado). Este es exactamente el problema que ARC (RFC 8617) fue diseñado para resolver.
ADMD: Dominio de administración
RFC 5598 introduce el concepto de un ADMD — el límite administrativo de una operación de correo. Un ADMD es una organización que opera uno o más servicios de correo bajo una única autoridad administrativa. Ejemplos:
- Una empresa que ejecuta su propio servidor Exchange es un ADMD.
- Gmail/Google Workspace es un ADMD.
- Un servicio de correo transaccional como MailerToGo es un ADMD.
Los mensajes cruzan límites de ADMD cuando salen de la infraestructura de correo de una organización y entran en la de otra. Las decisiones de autenticación y confianza ocurren en estos límites.
Sobre vs. contenido
La arquitectura formaliza las dos capas de cada mensaje de correo electrónico:
-
Sobre: La información a nivel SMTP (
MAIL FROM,RCPT TO) utilizada para enrutamiento. Creada durante el envío y modificada en cada salto. - Contenido: Los encabezados y cuerpo del mensaje como se define en RFC 5322. Destinado a ser inmutable después de la composición, aunque los mediadores pueden modificarlo.
Errores comunes
- Confundir MTA y MSA. El MSA (puerto 587, autenticado) y el MTA (puerto 25, servidor a servidor) sirven para propósitos diferentes. Enviar correo de aplicación directamente a un MTA remoto en el puerto 25 — omitiendo un MSA — omite la autenticación y aplicación de políticas. La mayoría de proveedores de nube bloquean el puerto 25 saliente por esta razón.
-
Ignorar el problema del mediador. Si aplicas DMARC estricto (
p=reject) sin considerar que tus mensajes pueden pasar a través de listas de correo, esos mensajes reenviados serán rechazados en el destino. Entender el concepto de mediador te ayuda a planificar para esto. -
Tratar From: como el remitente. El encabezado
From:identifica el autor, no el remitente del transporte. SPF comprueba el remitente del sobre, no el encabezado From. Esta distinción es la base completa de la alineación de DMARC. - Asumir una topología plana. Los mensajes no siempre van directamente de remitente a receptor. Pueden pasar a través de múltiples MTA, listas de correo, servicios de reenvío y pasarelas. Cada salto puede modificar el sobre y potencialmente el contenido.
- No entender los límites de ADMD. Cuando delegas el envío a un servicio de correo electrónico, el mensaje cruza un límite de ADMD. SPF, DKIM y DMARC deben configurarse para contabilizar esta delegación.
Impacto en la entregabilidad
- Arquitectura de envío adecuada. Usar un MSA (puerto 587 con autenticación) en lugar de inyectar directamente en un MTA asegura que tus mensajes estén debidamente autenticados y cumplan políticas desde el inicio. Servicios como MailerToGo actúan como tu MSA.
- Alineación de autenticación. Entender qué identidad verifica cada mecanismo de autenticación — SPF verifica Return-Path, DKIM firma en nombre de un dominio, DMARC alinea estos con el encabezado From — requiere entender el modelo de identidad de RFC 5598.
- Manejo de reenvío y listas. Si tus destinatarios usan servicios de reenvío o listas de correo (mediadores), tus mensajes pueden fallar la autenticación en el destino final. Entender el rol del mediador te ayuda a diagnosticar "¿por qué mi mensaje que aprobó DMARC fue rechazado?"
- Procesamiento de rebotes. La arquitectura distingue entre el autor (encabezado From) y el return-path (MAIL FROM). Los rebotes van al return-path. Si configuras tu return-path correctamente, puedes procesar rebotes automáticamente sin confundirlos con respuestas al autor.