Postfix vs Dovecot: funciones distintas en un servidor de correo entrante

Postfix y Dovecot suelen instalarse juntos, pero no desempeñan la misma función. En un sistema receptor habitual, Postfix acepta SMTP y administra la cola, mientras Dovecot realiza la entrega final o expone el buzón mediante LMTP e IMAP. Que un servicio esté activo no demuestra que el recorrido completo funcione.

Esta página es un mapa de diagnóstico, no una receta de producción. Un despliegue real exige DNS, TLS, validación de destinatarios, control de abuso, permisos, copias, monitorización y restricciones de relay. Once Email solo recibe correo; no proporciona envío SMTP, respuesta, reenvío ni correo masivo.

Comparación rápida

No suele ser una elección «Postfix o Dovecot». En un buzón alojado, la pregunta útil es dónde termina una responsabilidad y comienza la siguiente.

Seguir un mensaje entrante

La arquitectura oficial de Postfix muestra el correo de red entrando por smtpd, pasando por cleanup y llegando a una cola. Después el gestor escoge un agente de entrega. De ahí salen cuatro puntos de control:

1. Conexión SMTP: el servidor remoto alcanza Postfix y negocia la transacción.
2. Aceptación: Postfix acepta o rechaza el destinatario de sobre según mapas y reglas.
3. Cola y transferencia: el mensaje aceptado pasa a local, virtual, pipe o LMTP.
4. Acceso: tras la entrega, Dovecot deja que un cliente autorizado liste y lea por IMAP.

Un 250 SMTP no equivale a visibilidad en el buzón. Postfix puede aceptar primero y aplazar después por un error LMTP, cuota o almacenamiento. A la inversa, el mensaje puede estar guardado y seguir invisible por autenticación IMAP, índices, espacios de nombres o permisos.

LMTP une las dos responsabilidades

Una frontera común es LMTP. Postfix mantiene SMTP y la cola, y conecta con Dovecot para la entrega final. La guía LMTP de Dovecot ilustra un socket Unix protegido dentro del spool de Postfix.

El socket no es solo una ruta copiada de un tutorial. Propietario, grupo, modo, ubicación chroot y estado del servicio forman un contrato. Si Postfix no puede alcanzarlo, el resultado correcto suele ser un elemento aplazado, no un buzón presentado como vacío. Tras aceptar LMTP, pesan más las evidencias de cuota y almacenamiento.

No hagas el socket escribible por todos para ocultar un error. Identifica la cuenta de servicio que necesita acceso y concede lo mínimo. Tampoco publiques LMTP en Internet sin una arquitectura que defina autenticación y protección del transporte.

Diagnosticar por evidencia

Usa un marcador único y una ventana limitada. Conserva ID de cola, clase SMTP, resultado LMTP y resultado del buzón ya redactado. No envíes direcciones reales, códigos, tokens, asuntos, cuerpos, adjuntos ni URL completas a registros compartidos o analítica.

Cree una ficha de cuatro campos antes de cambiar la configuración

Para un único mensaje de prueba autorizado, conserve solo cuatro hechos redactados. Juntos permiten comprobar si la aceptación, la cola, la entrega final y la visibilidad pertenecen a la misma transacción:

Empiece con inspección de solo lectura. postqueue -p enumera la cola; filtre localmente por el ID abreviado y no exporte toda la cola. doveadm mailbox status -u TEST_USER "messages unseen" INBOX consulta contadores, usando solo una identidad de prueba autorizada. Las referencias oficiales de herramientas de cola de Postfix y estado de buzón de Dovecot explican estos datos. Sin coincidir también en tiempo y marcador redactado, no prueban que sea el mismo mensaje.

Errores de categoría y orden seguro

Instalar Dovecot no crea un listener SMTP; instalar Postfix no ofrece un buzón IMAP. SPF, DKIM y DMARC son otra capa: aportan autenticación y alineación, no acceso. Para eso está la guía de resultados SPF, DKIM y DMARC.

Una cola vacía no prueba éxito: el mensaje pudo rebotar, expirar, ser descartado por una política explícita o haber salido. Un buzón vacío tampoco prueba que nada llegó: la consulta puede haber fallado, el cliente estar sin conexión o mirar otro namespace. Mantén separados «sin resultado», «fallo temporal» y «vacío confirmado».

Verifica primero el endpoint SMTP, entrega un único mensaje autorizado, registra la aceptación de Postfix, sigue cola y entrega, confirma el buzón Dovecot y léelo por el mismo IMAP usado por la aplicación. Elimina la cuenta de prueba y conserva solo evidencia redactada. Reiniciar ambos servicios antes de observar borra tiempos y colas sin explicar la causa.