Operar tu propio servidor de correo como si fuera 1984
(maxadamski.com)- Operar tu propio servidor de correo permite gestionar de forma económica tareas automatizadas y listas de correo
- Existe en la práctica el problema de la confiabilidad de entrega, por lo que puede haber fallas al enviar o recibir correo con servicios grandes
- Con solo la configuración de Postfix y OpenDKIM se puede montar un sistema básico de SMTP y envío de correos autenticados
- Configurar certificados SSL, DKIM, SPF y DMARC puede mejorar la confiabilidad del correo y la seguridad de la transmisión
- Si además se configura un registro PTR (DNS inverso), se puede esperar una mejor tasa de entrega hacia grandes servicios de correo
Resumen
Operar directamente un servidor de correo es útil para automatizar tareas como listas de correo, boletines y APIs de verificación por email
Sin embargo, el mayor desafío real es la confiabilidad de entrega del correo: existe el riesgo de que los mensajes no lleguen correctamente o fallen al recibirse
El autor aplica este enfoque a proyectos personales aceptando ese riesgo
La ventaja de operarlo por cuenta propia es que casi no implica costos adicionales, ya que solo hay que instalar software en un sitio web existente, y el consumo de almacenamiento y energía también es muy bajo
Parecía que operar un servidor de correo sería demasiado difícil, pero en la práctica no difiere mucho en complejidad de configurar un servicio de correo tipo SaaS
Para facilitar la configuración y simplificar el entorno, se omiten por ahora el webmail y los entornos multiusuario, evitando así la necesidad de cuentas de usuario, bases de datos e interfaces web
Esta configuración es adecuada para operar con una sola cuenta y, si hace falta, permite enviar y recibir correo mediante SSH y herramientas como mailx, sendmail, mutt
Más adelante se puede considerar expandirlo y agregar webmail según sea necesario
Postfix
Básicamente, basta con abrir el puerto 25 e instalar y configurar Postfix y OpenDKIM para montar un servidor SMTP básico
Para entregar correos de forma confiable a la mayoría de los servicios de correo, como Gmail, se necesita OpenDKIM (autenticación de correo)
El autor dejó master.cf con sus valores predeterminados, y en el ejemplo de la configuración principal (main.cf) solo se muestran los ajustes clave, como cifrado TLS e integración con DKIM
No se configuró POP3/IMAP, y se simplificó el sistema para que, si hace falta, se pueda acceder directamente al servidor por SSH y enviar o recibir correo con comandos como mailx
TLS (cifrado de transporte)
Se necesita un certificado SSL para cifrar la transmisión de datos con el servidor SMTP
No hace falta emitir certificados para cada dominio: basta con tener un certificado para el único host donde está el servidor de correo, es decir, el del registro MX
Por ejemplo, si el registro MX es mx.example.com, solo hay que obtener y aplicar para ese dominio un certificado gratuito de Let’s Encrypt
TLS solo cifra el tramo de transmisión entre servidores, y es independiente de la autenticación real del nombre de dominio remitente
Por eso, en el encabezado From del correo se puede establecer libremente el valor que se desee
DKIM, SPF, DMARC
DKIM se usa para demostrar que el correo realmente proviene de tu dominio y así ganar confiabilidad
Con OpenDKIM se crea un par de claves para cada dominio y la clave pública se registra como un registro DNS TXT
Las claves no expiran automáticamente, pero se recomienda rotarlas periódicamente
También se agregan a DNS los registros TXT de SPF y DMARC para definir qué hosts pueden enviar correo y cuál es la política DMARC, por ejemplo rechazar si falla la autenticación
En los archivos de ejemplo de configuración (opendkim.conf, KeyTable, SigningTable, TrustedHosts) se puede ver con claridad cómo se define cada elemento
En DNS solo hace falta agregar los registros relacionados con MX, SPF, DKIM y DMARC
DNS inverso (PTR)
El registro PTR (DNS inverso) mejora la confiabilidad del servidor de correo y aumenta la probabilidad de que grandes servicios como Gmail no bloqueen los mensajes
Es necesario contactar al ISP para solicitar la configuración del registro PTR del servidor de correo
En un entorno real de despliegue, incluso sin PTR, los correos llegaron correctamente a Gmail, GMX y Outlook, y obtuvieron una puntuación de 10/10 en mail-tester.com
Aunque la falta de PTR restó puntos, se obtuvieron puntos extra como "trusted relay"
Además, al no aparecer en listas negras, la reputación de la IP de envío también fue buena
Prueba de envío a Gmail
Se envió un correo de prueba a Gmail con el comando sendmail usando un mensaje HTML
El correo llegó de inmediato a Gmail y se confirmó el cifrado TLS
Al ver el mensaje original con "Show original", SPF, DKIM y DMARC aparecieron como validados
También se puede revisar el contenido del correo recibido localmente en el servidor con mailx
Si hay problemas de configuración, conviene revisar de nuevo el DNS, el certificado y los permisos de acceso a las claves DKIM; en particular, los archivos de configuración de OpenDKIM son sensibles a errores tipográficos
Siguientes pasos
En el próximo artículo se presentará cómo crear una aplicación de correo electrónico con Python
Si tienes preguntas u opiniones, puedes escribir a max@idx.cy
1 comentarios
Comentarios en Hacker News
Me da orgullo haber alojado mi propio correo por más de 20 años, y pienso seguir haciéndolo. Curiosamente, ni el gobierno ni las dependencias relacionadas pueden operar sus propios sistemas de correo; solo el departamento nacional de seguridad hace hosting por su cuenta. Tal vez he tenido suerte, pero casi no he tenido problemas para enviar correos. El caso más reciente que recuerdo fue cuando Microsoft se tragaba mis mensajes, y era por un enredo de autenticación TLS entre una versión vieja de exim y Outlook. Lo resolví ajustando una sola configuración. El mantenimiento no requiere tanto trabajo, así que cada vez que toco algo lo tomo como una oportunidad para aprender algo nuevo. Este año cambié Debian jessie por Arch Linux y migré por completo las tareas de cron a timers de systemd. Cuando envío correos importantes, siempre reviso los logs del servidor, y también creo que eso es un buen hábito en sí mismo. Si tuviera que dar un consejo, sería que es mucho mejor si disfrutas el hosting propio como un hobby. Y por último: quien diseñó la configuración de Exim en Debian es responsable de hacerme perder muchísimo tiempo. Si vas a montar Exim en Debian, lo correcto es cambiar a la configuración oficial upstream y personalizarla a tu gusto
Hoy muchas redes sociales presumen que son “descentralizadas” o “abiertas”, pero en realidad ya tenemos herramientas con las que podemos ser completamente independientes y autosuficientes. A menudo se nos pasa que, mientras dicen mejorar la UX, en realidad se está perdiendo el control del usuario. Al final, si nos acostumbramos a sistemas demasiado simplificados, llegará un futuro en el que ni siquiera podremos instalar una app si alguien en otro lugar no nos “autoriza la transacción”
Usé correo electrónico por primera vez en la universidad, antes de la WWW, y después, como mi cuenta del ISP tenía poquísimo espacio y solo soportaba POP, terminé montando mi propio servidor de correo. Como no estaba siempre conectado a internet, recibía correo usando relay y DNS dinámico. Hoy en día recibo y almaceno el correo en un servidor en casa, pasando por un VPS. A lo largo de los años he tenido que pedir a servicios grandes como Outlook que desbloqueen mi IP o mi dominio, pero no ha sido tan frecuente. No quiero vivir en un mundo donde dos o tres empresas controlen todo el correo del planeta, así que considero este hosting propio como un pequeño acto de resistencia
Ojalá me quedara aunque fuera el 1% de la motivación que tenía hace 20 años. Ahora, con trabajo de tiempo completo y familia —esposa e hijo—, simplemente ya no tengo tiempo para hacer ese tipo de cosas
Yo también me alejé del hosting propio por un tiempo, pero como cambió el balance entre tiempo y costo, estoy pensando si vale la pena retomarlo. Lo que más me preocupa en el hosting de correo es el manejo del spam. Si alguien tiene consejos sobre cómo está eso hoy en día, agradecería que los compartiera
Para mí, el correo es un servicio muy importante. Lo alojé por mi cuenta durante 15 años y lo dejé por tres razones: 1) no estaba haciendo bien los respaldos/restauraciones periódicas ni el monitoreo, 2) como no tenía un plan de recuperación ante desastres, me salía más caro que otros servicios, y 3) no podía estar siempre al pendiente de la seguridad. Un servidor de un amigo cayó por ransomware y perdió todo, mientras que yo me salvé por usar FreeBSD, porque no era objetivo del ataque. En general el mantenimiento no es muy complejo, pero cuando algo se enreda puede volverse realmente doloroso, e incluso crítico
Antes alojaba mi propio correo, pero lo dejé no por reputación sino porque no podía evitar el requisito de disponibilidad 100%, con el riesgo de perder correos o acabar en listas negras. En teoría el protocolo de correo tolera bien el downtime, pero en la práctica los grandes proveedores de correo rechazan mensajes tras un solo fallo y luego ni siquiera reintentan. Antes hasta GitHub, si había un bounce una vez, te marcaba como “no entregable” y dejaba de mandarte correo por completo. Ya mejoró, pero los sistemas de correo modernos asumen que siempre estás en línea
Mi servidor de correo usa deliberadamente graylisting para rechazar el primer intento de un remitente nuevo. He recibido muchísimos correos y nunca he tenido un caso de un mensaje legítimo que no se entregara. El reintento forma parte del estándar del correo, así que si te preocupa puedes añadir un servidor receptor de respaldo y hacer backhaul por LMTP. El sistema de correo fue diseñado originalmente pensando en una época en la que no existía la conexión permanente 24/7
Esto está exagerado. En mi caso, si un correo no llegaba, aparecía de nuevo unas horas o un día después, y normalmente no hay forma de saber dónde falló exactamente. Si autenticas bien tu correo —por ejemplo con dkim y spf—, el hosting propio puede conseguir más del 99% de probabilidad de entrega. No hay que asustarse por la complejidad. Además, también puedes usar caldav de forma privada
No entiendo por qué alguien se preocuparía por “perder correos” si el servidor se cae unas horas. Mi servidor lleva 219 días seguidos encendido. Comparado con lo que hacemos normalmente, operar un servidor de correo es realmente fácil
De verdad, cuando ves el sistema de correo actual, dan ganas de decir: “¿qué le han hecho a mi hijo?”
Mi consejo para quien quiera empezar con hosting propio de correo: primero úsenlo solo para registrarse en cuentas. No hace falta usarlo desde el inicio para correo personal. Con “Mail-in-a-box” https://mailinabox.email./, si sigues la guía de instalación, puedes tenerlo funcionando en unas horas y funciona bien. Úsenlo uno o dos años y, cuando ya le tengan confianza, entonces sí migren su correo personal
Recomiendo Stalwart https://github.com/stalwartlabs/stalwart. Es un servicio de correo completo en un solo binario, sin dependencias, y la instalación/actualización es facilísima. Probé muchos otros proyectos, pero Stalwart fue el más simple y me ha funcionado sin un solo problema
Llevo años operando MIAB en la nube. Mientras la reputación de la IP esté limpia, no hay problema para enviar, pero cuando los correos no llegan a Outlook lo resuelvo escribiéndole directamente al postmaster de Microsoft. Lo recomiendo porque te permite aprender cosas como DKIM/SPF/DMARC. Pero recibir correos de registro es realmente difícil. El graylisting de MIAB rechaza al primer remitente y espera el reintento, pero incluso sitios legítimos muchas veces no reintentan. Los correos de verificación o códigos de dos factores tardan muchísimo en llegar, y tampoco hay una forma sencilla de desactivar temporalmente el filtro antispam
Hoy incluso el correo que te da el ISP, y hasta Google Gmail, a veces falla con el filtrado de spam. Por ejemplo, si haces un pedido por Shopify, los correos de Shopify terminan marcados como spam en Gmail una y otra vez. Incluso pasando DMARC, SPF y DKIM, a veces no queda claro por qué los filtran. Técnicamente enviar y recibir correo no es tan difícil, y ningún servicio es 100% perfecto. Hay tantos usuarios maliciosos —spammers— que sorprende que este sistema funcione tan bien como funciona
DMARC, SPF y DKIM son solo configuraciones de autenticación; no están directamente relacionadas con si algo es spam o no. Hay correos basura perfectamente autenticados y correos valiosísimos sin autenticar
Los correos de Shopify se clasifican como spam porque mucha gente marca a Shopify como spam, o porque hay usuarios con mala reputación compartiendo el mismo servidor de correo. Aunque yo siga marcándolos como “no es spam”, si la reputación global del remitente es demasiado mala, no van a salir de la carpeta de spam
He alojado mi propio correo por cerca de 20 años. Durante 10 a 15 años reenvié todo a Gmail, pero me cansé de que el filtro de spam desapareciera hasta correos importantes, así que empecé a correr mi propio imapd. Si configuras bien cosas como SPF, siento que el hosting propio es mucho mejor
Ese tipo de políticas de filtrado son precisamente el problema. Si haces hosting propio o usas un servicio de correo pequeño, es mucho menos probable que te bloqueen correos, especialmente con filtros estrictos como los de Gmail. Google insiste en políticas de filtrado frecuentes aunque Gmail sigue siendo uno de los principales orígenes del spam
Últimamente el filtro de spam de Gmail reacciona de forma excesiva al correo de marketing. Hace 10 años el problema era el opuesto, pero ahora manda tantas cosas a spam que ya resulta molesto. Hoy en día gran parte del spam viene de correos en frío enviados desde direcciones nuevas y pequeñas. La función de “cancelar suscripción” de Gmail funciona bien para correos de marketing, pero no sirve de nada con ese tipo de cold email
Si quieres una configuración completa y un servidor IMAP que funcione con muchos clientes distintos, la guía https://workaround.org/ispmail-bookworm/ puede ser más adecuada. Yo lo opero de forma simple con archivos de texto plano en vez de una base de datos. Si tú eres el único usuario, eso puede funcionar muy bien; y esa guía también escala sin problema para empresas grandes
Autopromoción: estamos beta probando Hyvor Relay https://github.com/hyvor/relay, una alternativa self-hosted. Estamos enfocados en visibilidad, con monitoreo de DKIM/SPF y automatización de DNS. Se puede poner a funcionar con un simple
docker compose uphttps://relay.hyvor.com/hosting/deploy-easyDurante 10 a 15 años he hecho hosting propio de correo con opensmtp, dovecot y rspamd en una caja kimsufi barata. No tuve mayores problemas; una vez telekom.de bloqueó mi servidor, pero en cuanto les expliqué por correo formal me pusieron en whitelist enseguida. Tal vez porque he conservado la misma IP por mucho tiempo, personalmente no he sufrido esos problemas que todos dicen tener. Eso sí, el servidor y la IP están a mi nombre
Comparto en alemán una guía sobre hosting propio de correo basada en Debian trixie en https://krei.se/Doc. Si lo montas bien por tu cuenta, realmente es una experiencia muy disfrutable. Tengo actualizaciones automáticas y reinicios, y con systemd personalizado recibo cada día por correo un reporte del estado. Durante 2 o 3 años, o hasta 5 con trixie, no hace falta tocar nada y sigue estable. El software de servidores de correo ya es lo bastante maduro. Recomiendo el hosting propio. La autonomía, la tranquilidad y el control directo valen muchísimo
Llevo más de 10 años operando mi propio correo y a veces he dejado enlaces a comentarios antiguos de HN (por ejemplo 39891262, 38471262). Como la IP de Digital Ocean quedó marcada como maliciosa, reemplacé los envíos con Amazon SES, y uso Gmail como entrenador gratuito de spam para alimentar mis propios filtros (38843288). Como ya varios mencionaron, el graylisting ayuda muchísimo. Los servidores de correo legítimos siempre reintentan, así que aunque es incómodo para cosas como 2FA, a nivel del sistema es confiable. Incluso si hay varios días de downtime no pasa nada, y separar los servidores de recepción y almacenamiento facilita mucho los respaldos (38512732). Para el tema de correos de 2FA también uso https://github.com/stevejenkins/postwhite, pero la verdad no recomendaría depender del correo electrónico para 2FA (eso merecería una discusión aparte)
Hace poco no pude recibir un correo importante enviado por Amazon SES debido a una blacklist de spam (bl.spamcop.net). Amazon reintentó desde varias IP, se topó con el graylisting y al final una de ellas fue rechazada. Tal vez entre proveedores grandes —de MX a MX— esto no sea tan problemático, pero incluso esta arquitectura no es una solución 100% perfecta
Al final, por más que se hable largo y tendido, parece que la conclusión es que simplemente conviene más usar un servicio grande como Gmail
¿Dónde quedó UUCP, por qué la dirección ya no es un bang path, y qué pasó con sendmail.cf?
Exacto. Si intentaras hacer hosting propio “al estilo 1984” —correo clásico— acabarías con un open relay que retransmite todo, expuesto a toda clase de vulnerabilidades y peligros
Hablando de esa época, recuerdo en el laboratorio de la universidad seis estaciones de trabajo Unix moviendo correos de un servidor a otro, y podías sentir que el correo estaba circulando por el sonido de los discos
Yo también vi el título y pensé en bang paths y direcciones como “killer!jolet!”. Qué tiempos tan entrañables
Coincido. Entré por el título de “1984”, pero al final era una charla sobre configurar postfix, y me decepcionó bastante