Migración de correo: mover correo a un nuevo servidor con mínimo tiempo de inactividad (pasos reales)

Qué significa realmente “mínimo tiempo de inactividad”

Para el correo, “tiempo de inactividad” no es un interruptor único. La entrega SMTP es store-and-forward: los servidores remotos reintentará durante horas o días si tu servidor está caído. IMAP es con estado: los clientes mantienen conexiones abiertas y almacenan en caché identificadores de buzón. DNS está en caché: tu cambio “instantáneo” de MX puede tardar un día para algunos remitentes.

Así que el objetivo no es “sin interrupciones”. Es una interrupción controlada:

• Sin correo perdido. El retraso es aceptable; perder correo es algo que arruina carreras.
• Ventana corta donde las escrituras son mono-homed. Durante el corte, el correo nuevo debe aterrizar en un único servidor. Todo lo demás es una trampa peligrosa.
• Comportamiento de cliente predecible. Los endpoints de IMAP/Submission y los certificados deben ser estables para que los clientes no se subleven.
• Rollback que no requiera rezos. Recuperar debe ser “volver a poner el MX y reactivar la entrada”, no “reconstruir la antigua máquina desde el humo”.

El patrón de migración que funciona en producción es la replicación en dos pasadas:

1. Sincronización masiva mientras el servidor antiguo está activo.
2. Congelación corta (o entrega dual controlada) durante el corte, luego sincronización final.

No estás moviendo “correo”. Estás moviendo buzones, identidades, reputación criptográfica y un montón de supuestos operativos.

Algunos datos (y fragmentos de historia) que cambian decisiones

1. SMTP es anterior a la mayoría de tus herramientas. SMTP se estandarizó a principios de los años 80 y aún asume conectividad intermitente y reintentos. Por eso tu corte puede ser indulgente si manejas bien las colas.
2. Los registros MX no obligan la entrega. Algunos remitentes ignoran las preferencias de MX o hacen caché agresivo. Reduces riesgo con planificación de TTL, pero nunca tendrás control perfecto.
3. Los UID de IMAP no son IDs de mensajes. Los clientes dependen de secuencias UID por buzón y UIDVALIDITY. Si los reinicias accidentalmente, los clientes pueden duplicar o “perder” mensajes hasta una resync completa.
4. Maildir vs mbox es una diferencia operacional real. Maildir son muchos archivos; mbox es un único archivo. Migrar mbox con rsync puede parecer “hecho” mientras corrompes el estado por escrituras concurrentes.
5. DMARC cambió cómo funciona “solo cambiar IPs”. La entregabilidad moderna es reputación más alineación (SPF y DKIM). Puedes romper la aceptación entrante en destinatarios incluso si tu servidor está perfecto.
6. El greylisting aún vive en algunos lugares. A remitentes por primera vez se les difiere intencionalmente. Durante el corte, IP nueva + reputación fría puede significar más diferimientos y correo más lento.
7. TLS en SMTP se volvió estándar por cifrado oportunista. La mayoría de servidores caerán a texto plano si están mal configurados—salvo que la política lo imponga. Tu migración puede reducir seguridad sin que nadie lo note.
8. Los grandes proveedores aplican sus propias reglas. Algunos destinatarios mantienen reputación interna por IP y por dominio; mover servidores puede parecer “remitente nuevo” aunque tu dominio sea antiguo.

Decide qué vas a migrar: SMTP, IMAP, autenticación y almacenamiento

Elige una forma objetivo antes de tocar datos

Un servidor de correo no es un solo daemon. Es un pequeño ecosistema:

• Entrada SMTP (puerto 25): normalmente Postfix. Recibe correo para tus dominios y aplica políticas.
• Submission (587/465): envío autenticado para usuarios; debería requerir TLS y autenticación.
• IMAP/POP: normalmente Dovecot. Aquí es donde ocurre el dolor del cliente.
• Autenticación: usuarios locales, LDAP, SQL, pasarelas tipo OAuth. Migrar la autenticación mal es cómo te despiertas a las 02:00.
• Escaneo de contenido: rspamd/Amavis/ClamAV. Opcional, pero muchas organizaciones dependen de ello sin admitirlo.
• Firmado DKIM: OpenDKIM/rspamd. Las claves deben sobrevivir al traslado.
• Almacenamiento: sistema de archivos + cuotas + backups + snapshots. Aquí es donde o tienes éxito aburrido o tienes una historia que la gente cuenta.

Deja de fingir que DNS es solo MX

Para un corte limpio, normalmente tocarás:

• A/AAAA para mail.example.com (endpoint IMAP/submission)
• MX para example.com
• SPF TXT: autorizar nuevas IPs de envío
• DKIM TXT: asegurar que el nuevo servidor firme con el mismo selector/clave, o publicar la nueva clave primero
• DMARC TXT: alineación y política; no endurezcas la política la semana de la migración
• Reverse DNS (PTR) para la nueva IP: muchos destinatarios puntúan sin él

Una cita sobre fiabilidad, porque es verdad

La esperanza no es una estrategia. — a menudo atribuido en círculos de ingeniería; úsalo como idea parafraseada si lo prefieres. De cualquier modo, construye el rollback.

Broma #1: El correo es el único producto donde “se entregó finalmente” se considera criterio de éxito y modelo de amenaza.

Preparación pre-migración que realmente importa

1) Elige la identidad que no cambiará

Para mínimo tiempo de inactividad, mantén estables los nombres visibles por los clientes. Usa mail.example.com para IMAP/submission y mueve la IP detrás de él. No cambies nombres de host y certificados durante la misma ventana de mantenimiento a menos que te gusten los tickets de soporte.

2) Baja los TTL de DNS con antelación (y confirma)

Los cambios de TTL solo ayudan si tienen tiempo para propagarse antes del corte. Redúcelos al menos 24–48 horas antes para:

• MX del dominio
• mail.example.com A/AAAA

Usa un TTL como 300 segundos temporalmente. Luego restaura TTLs sensatos más tarde (3600–14400) tras la estabilidad.

3) Decide: rsync, dsync o exportar/importar?

Si usas Dovecot e IMAP, Dovecot dsync suele ser lo más seguro porque respeta metadata de buzón y puede hacer sincronizaciones incrementales limpiamente. Para Maildir puro, rsync puede funcionar, pero solo si entiendes qué significan los “cambios en vuelo”.

4) Planifica la ventana de congelación del correo

El corte más limpio es:

• Detener SMTP entrante en el servidor antiguo (o rechazar temporalmente con un 4xx).
• Vaciar colas y asegurar que todo el correo nuevo vaya al servidor nuevo.
• Sincronización final del antiguo al nuevo para cualquier cambio último en buzones.

Esa ventana de congelación puede ser de 5–30 minutos si hiciste la sincronización masiva antes.

5) No migres un desastre; créale snapshot

Si tu almacenamiento soporta snapshots (ZFS, LVM, snapshots de FS), tómalos. Poder revertir el estado de los buzones es la diferencia entre “ups” y “incidente”.

Tareas reales con comandos: comprobar, replicar, verificar, decidir

Estos no son comandos “de juguete”. Son las cosas que realmente ejecutas al migrar un sistema de correo de producción. Cada tarea incluye: comando, qué significa la salida y qué decisión tomar.

Task 1: Inventory listening services (old and new)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|465|587|993|143)\b'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1123,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1123,fd=14))
LISTEN 0      128          0.0.0.0:993       0.0.0.0:*    users:(("dovecot",pid=1402,fd=40))

Significado: Confirma que Postfix master está enlazado para SMTP/submission y Dovecot para IMAPS. Puertos faltantes significan que los clientes fallarán o que el entrante no llegará.

Decisión: Si el servidor nuevo no escucha los puertos correctos, detente. Arregla firewall/unidades de servicio antes de sincronizar datos o tocar DNS.

Task 2: Confirm DNS TTLs (what you think you set vs reality)

cr0x@server:~$ dig +nocmd +noall +answer MX example.com
example.com.  300 IN MX 10 mail.example.com.

Significado: TTL 300 es bajo. Bueno para agilidad en el corte. Si todavía ves 3600/86400, lo has hecho demasiado tarde.

Decisión: Si los TTL son altos y el corte es pronto, planifica una ventana de coexistencia más larga y mantén el servidor antiguo recibiendo por más tiempo.

Task 3: Verify name resolves consistently (A/AAAA)

cr0x@server:~$ dig +short A mail.example.com
203.0.113.10

Significado: Muestra la IP a la que los clientes se conectarán para IMAP/submission (si usas este hostname). ¿Dual-stack? Comprueba AAAA también.

Decisión: Si A/AAAA no coincide con tu plan, arregla DNS ahora—antes de depurar informes fantasma de “no puedo conectar”.

Task 4: Check TLS certificate on IMAP (clients care a lot)

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Peer certificate: CN = mail.example.com
Verification: OK

Significado: CN/SAN coincide con el hostname; verificación OK. Si ves errores de verificación, los clientes pueden mostrar advertencias o negarse.

Decisión: Arregla la cadena de certificados y el hostname antes del corte. No digas “lo arreglaremos después”; no lo harás.

Task 5: Confirm Postfix identity and domains (avoid accepting for wrong domains)

cr0x@server:~$ sudo postconf myhostname mydestination virtual_mailbox_domains
myhostname = mail.example.com
mydestination = $myhostname, localhost.localdomain, localhost
virtual_mailbox_domains = example.com, example.org

Significado: Aceptas correo para los dominios previstos como buzones virtuales (configuración común). Si mydestination incluye por error example.com, podrías entregar localmente en cuentas del sistema.

Decisión: Corrige el enrutamiento de dominios ahora. Una clasificación errónea causa entregas silenciosas equivocadas.

Task 6: Verify mailbox format and location (Maildir vs mbox)

cr0x@server:~$ sudo doveconf -n | egrep '^(mail_location|mail_privileged_group|first_valid_uid)'
mail_location = maildir:/var/vmail/%d/%n/Maildir
first_valid_uid = 5000

Significado: Ruta Maildir y baseline de UID. Si el servidor nuevo usa un mail_location o asignación de UID diferente, los clientes pueden ver buzones vacíos o errores de permisos.

Decisión: Mantén rutas de buzón y estrategia de UID consistentes entre servidores a menos que estés migrando formatos intencionalmente (proyecto distinto).

Task 7: Measure mailbox data size (so you can estimate sync time)

cr0x@server:~$ sudo du -sh /var/vmail
842G    /var/vmail

Significado: Tamaño aproximado del almacenamiento de correo. Si está cerca de la capacidad del disco en el servidor nuevo, no estás migrando—estás moviendo a un incendio.

Decisión: Asegura al menos 30–50% de margen. Los sistemas de correo crecen y ocurren picos (journaling, indexado, archivos temporales).

Task 8: Check filesystem and inode pressure (Maildir eats inodes)

cr0x@server:~$ df -h /var/vmail && df -ih /var/vmail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       1.8T  1.1T  680G  62% /var/vmail
Filesystem      Inodes  IUsed  IFree IUse% Mounted on
/dev/sdb1        120M   79M   41M   66% /var/vmail

Significado: Maildir puede consumir inodos rápidamente. Quedarse sin inodos se ve como “disco lleno” mientras df -h parece bien.

Decisión: Si el uso de inodos es alto, elige un sistema de archivos/ratio de inodos apropiado para millones de archivos pequeños o planifica una estrategia de archivado.

Task 9: Bulk sync Maildir with rsync (first pass)

cr0x@server:~$ sudo rsync -aHAX --numeric-ids --delete --info=stats2,progress2 /var/vmail/ root@mail-new:/var/vmail/
sending incremental file list
...
Number of files: 18,492,310 (reg: 18,491,900, dir: 310)
Total file size: 901,223,554,120 bytes
Total transferred file size: 901,223,554,120 bytes
Literal data: 210,331,112,455 bytes
Speedup is 4.28

Significado: La primera pasada copia casi todo. “Literal data” y speedup te hablan de compresión y comportamiento delta; los deltas en Maildir suelen ser pobres porque los mensajes son inmutables pero numerosos.

Decisión: Si el rendimiento es terrible, no “tunes” a ciegas. Revisa IOPS de disco y red. Puede que necesites limitar, programar fuera de horario o usar ZFS send/receive si puedes.

Task 10: Incremental sync (second pass) with rsync

cr0x@server:~$ sudo rsync -aHAX --numeric-ids --delete --info=stats2 /var/vmail/ root@mail-new:/var/vmail/
Number of files: 18,492,400 (reg: 18,492,090, dir: 310)
Number of created files: 120
Number of deleted files: 6
Total transferred file size: 87,991,230 bytes

Significado: El delta ahora es pequeño. Eso es lo que quieres antes del corte: una ventana final corta.

Decisión: Si los deltas siguen siendo enormes, los usuarios están cambiando activamente correo (mover carpetas, borrar). Planifica una congelación corta o usa dsync para reconciliación más segura.

Task 11: Dovecot dsync replication (preferred when available)

cr0x@server:~$ sudo doveadm -v dsync -u alice@example.com remote:vmail@mail-new
dsync(alice@example.com): Debug: Added connection to remote:vmail@mail-new
dsync(alice@example.com): Debug: Mailbox INBOX: GUIDs match
dsync(alice@example.com): Debug: Finished successfully

Significado: Dsync compara GUIDs de buzón y sincroniza cambios de forma segura. “GUIDs match” es reconfortante; las discrepancias pueden arreglarse pero requieren atención.

Decisión: Si dsync reporta problemas con UIDVALIDITY o GUID, pausa y diagnostica la metadata del buzón antes de cortar. Aquí nacen las duplicaciones del cliente.

Task 12: Verify Dovecot can see mailboxes on new server

cr0x@server:~$ sudo doveadm mailbox list -u alice@example.com
INBOX
Sent
Trash
Archive/2024

Significado: La jerarquía de buzones está presente para un usuario representativo. Si está vacía, tu mail_location, permisos o mapeo de autenticación están mal.

Decisión: Arregla la estructura ahora; no cortes DNS y luego descubras que todos tienen “solo INBOX”.

Task 13: Check permissions/ownership on migrated Maildir

cr0x@server:~$ sudo namei -l /var/vmail/example.com/alice/Maildir
f: /var/vmail/example.com/alice/Maildir
drwxr-x--- root  vmail /var
drwxr-x--- root  vmail vmail
drwxr-x--- vmail vmail example.com
drwxr-x--- vmail vmail alice
drwx------ vmail vmail Maildir

Significado: Los directorios son propiedad del usuario/grupo de correo. Si ves root:root en directorios de buzón, Dovecot puede lanzar “Permission denied” y los clientes verán carpetas vacías.

Decisión: Arregla con chown -R vmail:vmail /var/vmail (con cuidado) y verifica que first_valid_uid/last_valid_uid coincidan.

Task 14: Validate Postfix queue state before cutover

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
2A1B2C3D4E*     912 Thu Jan  4 10:15:11  sender@example.net
                                         user@example.com

-- 12 Kbytes in 1 Request.

Significado: El servidor antiguo todavía tiene correo en cola. Una cola pequeña está bien; una cola en crecimiento indica problemas de entrega aguas arriba.

Decisión: Si la cola es grande o está atascada, investiga antes del corte. De lo contrario estarás migrando un backlog y llamándolo “tiempo de inactividad”.

Task 15: Watch logs for active delivery errors (during testing)

cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Jan  4 10:21:07 mail postfix/smtpd[2201]: connect from unknown[198.51.100.77]
Jan  4 10:21:08 mail postfix/smtpd[2201]: NOQUEUE: reject: RCPT from unknown[198.51.100.77]: 450 4.7.1 Client host rejected: cannot find your hostname; from= to= proto=ESMTP helo=

Significado: Estás rechazando a un remitente por política de reverse DNS. Eso puede ser intencional, pero te perjudicará si tu política es más estricta que la tolerancia del negocio.

Decisión: Decide si quieres ser “técnicamente puro” o “recibir correo”. Ajusta smtpd_client_restrictions según corresponda, especialmente durante la semana del corte.

Task 16: Confirm SPF and DKIM are in place before moving sending traffic

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all"

Significado: SPF autoriza temporalmente ambas IPs, antigua y nueva. Esa es la aproximación segura para corte y rollback.

Decisión: Mantén la IP antigua autorizada hasta que estés seguro de que ningún sistema sigue enviando desde ella (apps, impresoras, relays heredados). Luego la quitas.

Task 17: Confirm DKIM signing actually happens on the new server

cr0x@server:~$ sudo rspamc stat | egrep 'dkim|dmarc|spf'
Actions: reject: 0, add header: 120, greylist: 4, no action: 980
DKIM sign: 110
DMARC policy: 12
SPF: 940

Significado: El contador “DKIM sign” en aumento indica que el correo saliente se está firmando. Si es cero, vas a tener problemas de entregabilidad que parecen “rebotes aleatorios”.

Decisión: Arregla el firmado DKIM antes de mover tráfico saliente. La entregabilidad se recupera lentamente y se destruye rápidamente.

Task 18: Smoke-test end-to-end mail flow (SMTP in, IMAP read)

cr0x@server:~$ swaks --to user@example.com --server mail.example.com --port 25
=== Trying mail.example.com:25...
=== Connected to mail.example.com.
<  220 mail.example.com ESMTP Postfix
>  EHLO client.local
<  250-mail.example.com
...
>  DATA
<  354 End data with <CR><LF>.<CR><LF>
>  Subject: migration test
>
>  hello
>  .
<  250 2.0.0 Ok: queued as 9F8E7D6C5B

Significado: La aceptación SMTP funciona y el mensaje queda en cola. Aún necesitas confirmar la entrega al buzón y la visibilidad en el cliente.

Decisión: Si SMTP acepta pero el correo no aparece en IMAP, estás frente a problemas de entrega/LMTP, permisos de buzón o reglas de filtrado. No toques DNS hasta entender por qué.

Listas de verificación / plan paso a paso (migración en dos fases)

Fase 0: Restricciones y rollback (ponlo por escrito)

• Define la ventana de mantenimiento y quién está responsable de DNS, correo y almacenamiento.
• Decide tu disparador de rollback: por ejemplo, “tasa de error de entrega entrante > X por Y minutos”, o “fallo de autenticación IMAP generalizado”.
• Mantén el servidor antiguo intacto y accesible hasta terminar. No reutilices la IP el primer día.
• Autoriza temporalmente ambas IPs de envío en SPF.

Fase 1: Construye el servidor nuevo como si importara

• Instala y configura Postfix + Dovecot + pila de filtrado para que coincida con el comportamiento existente.
• Copia claves DKIM y asegúrate de que los selectores de firma coincidan con los registros DNS (o publica los nuevos registros primero).
• Instala certificados TLS para los nombres estables (especialmente IMAP y submission).
• Haz coincidir la base de usuarios/mapeo de autenticación (LDAP/SQL/local). Prueba con un usuario real.
• Provisiona almacenamiento con margen y densidad de inodos correcta; habilita snapshots/backups.

Fase 2: Sincronización masiva de datos de correo (primera pasada)

• Ejecuta rsync o dsync mientras el servidor antiguo está en línea.
• No detengas servicios todavía; deja que los usuarios trabajen.
• Mide duración y rendimiento. Si va a tardar días, pláncalo en lugar de fingir.

Fase 3: Validación antes de cualquier cambio en DNS

• Elige 5–10 buzones representativos: grandes, pequeños, compartidos, con mucho uso de carpetas IMAP.
• Verifica inicio de sesión, lista de carpetas y recuentos de mensajes en el servidor nuevo.
• Envía correos de prueba entrantes y salientes; revisa cabeceras por firmas DKIM y cadena Received.
• Confirma cuotas, reglas sieve (si se usan) y cualquier filtrado del lado del servidor.

Fase 4: Sincronización delta previa al corte (segunda pasada)

• Ejecuta una sincronización incremental para reducir la ventana final.
• Monitorea la actividad de escritura del servidor antiguo (conexiones IMAP activas y entregas).
• Comunica: una ventana corta donde el correo puede retrasarse es mejor que una larga interrupción misteriosa.

Fase 5: Corte (congelación corta + DNS)

1. Detén o difiere SMTP entrante en el servidor antiguo (devuelve fallo temporal). Quieres que los remitentes reintenten, no que reboten.
2. Asegura que submission (587/465) para usuarios apunte al servidor nuevo, idealmente usando el mismo hostname.
3. Realiza la sincronización final (rsync o dsync).
4. Cambia MX (y A/AAAA si aplica) al servidor nuevo.
5. Vuelve a habilitar SMTP entrante en el servidor nuevo y vigila logs como si fuera un thriller.

Fase 6: Monitoreo post-corte y limpieza

• Vigila la cola de Postfix, fallos de autenticación Dovecot y latencia de entrega.
• Mantén el servidor antiguo aceptando nada más que disponible para recuperación de emergencia por un tiempo.
• Tras un periodo estable: restaura TTLs más altos, elimina la IP antigua del SPF y archiva el servidor antiguo de forma segura.

Broma #2: La herramienta de migración de correo más fiable es una invitación de calendario titulada “Sincronización final” a la que realmente asiste todo el mundo.

Día de corte: DNS, colas e impacto en clientes

Cómo “congelar” el entrante sin perder correo

Tu servidor antiguo debería responder con un fallo temporal para que los MTAs remitentes reintenten. Un defer controlado es más seguro que cerrar el puerto y hacer que algunos remitentes te traten como hostil. Si no puedes enrutar políticas limpiamente, parar Postfix sigue siendo aceptable—la semántica de reintentos SMTP existe por una razón.

Un enfoque práctico: mantén el servidor antiguo en funcionamiento, pero haz que rechace nuevo correo entrante con un 4xx. Así sigue vivo para entrega desde la cola y acceso administrativo.

Estrategia de vaciado de colas

Antes del corte, quieres que la cola saliente del servidor antiguo esté estable o disminuyendo. Si está creciendo, cortarás y aún tendrás saliente atascado, lo que los usuarios interpretarán como “el correo está roto” aunque el entrante esté bien.

Después del corte, aún puedes ver algún entrante llegar al servidor antiguo por MX en caché. Mantén un plan:

• Opción A (limpia): el servidor antiguo difiere todo entrante con 4xx por un periodo, forzando reintentos al nuevo MX cuando las cachés se actualicen.
• Opción B (desordenada pero funcional): el servidor antiguo acepta y retransmite entrante al servidor nuevo por un tiempo limitado.

La Opción B puede ser útil, pero también es la forma en que accidentalmente creas bucles de correo y entregas duplicadas si configuras mal mapas de transporte. Elige con cuidado.

Impacto en clientes y cómo mantenerlo aburrido

Si los usuarios se conectan a mail.example.com para IMAP y submission, y el certificado es válido en ambos servidores, puedes mover el registro A/AAAA sin requerir reconfiguración cliente. El comportamiento visible será una desconexión/reconexión corta.

Si cambias nombres de host, obtendrás:

• Advertencias de certificado
• Contraseñas guardadas en conflicto
• Clientes móviles atascados en “verificando cuenta”
• Tickets reclamando “mi buzón está vacío” cuando sólo está reindexando

Así que: mantén hostnames estables salvo que sea absolutamente imposible.

Guía de diagnóstico rápido (encuentra el cuello de botella en minutos)

Este es el orden de triaje cuando algo se siente lento o roto justo después del corte. No te inventes nada; sé sistemático.

Primero: ¿es DNS o enrutamiento?

• Comprueba qué MX ve el mundo para el dominio.
• Comprueba qué A/AAAA resuelven los clientes para mail.example.com.
• Confirma que el servidor nuevo realmente recibe conexiones.

cr0x@server:~$ dig +short MX example.com
10 mail.example.com.

cr0x@server:~$ sudo tail -n 20 /var/log/mail.log
Jan  4 10:31:22 mail postfix/smtpd[3122]: connect from mx.remote[198.51.100.77]
Jan  4 10:31:23 mail postfix/smtpd[3122]: NOQUEUE: reject: RCPT from mx.remote[198.51.100.77]: 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table; ...

Interpretación: Si los logs muestran conexiones, DNS probablemente está bien. El error indica desajuste en lookup de destinatario/auth/db.

Segundo: ¿SMTP acepta pero no entrega?

• Busca correo encolado pero sin entregar.
• Revisa LMTP/entrega local y logs de Dovecot LDA/LMTP.
• Comprueba permisos del sistema de archivos en vmail.

cr0x@server:~$ sudo postqueue -p | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9F8E7D6C5B      1043 Thu Jan  4 10:29:10  sender@example.net
                                         user@example.com

Interpretación: Si la cola crece con destinatarios locales, la tubería de entrega está rota. Es LMTP/socket de Dovecot, permisos o mapas de destinatarios.

Tercero: ¿es IMAP/auth el problema?

• ¿Aumentan fallos de auth? LDAP/SQL, configuración SASL faltante o firewall bloqueando backend de auth.
• ¿IMAP lento? IOPS de disco o índices de Dovecot reconstruyéndose.

cr0x@server:~$ sudo doveadm auth test alice@example.com 'CorrectHorseBatteryStaple'
passdb: alice@example.com auth succeeded
extra fields:
  user=alice@example.com

Interpretación: La prueba de auth exitosa señala que no es problema de LDAP/contraseña. Si los clientes siguen fallando, mira mismatch de TLS/hostname o clientes antiguos intentando otro puerto.

Cuarto: ¿es el almacenamiento el villano oculto?

• Iowait alto, fsync lento, pool saturado—Maildir hace esto visible rápido.
• Comprueba agotamiento de inodos.

cr0x@server:~$ iostat -xm 2 3
Device            r/s     w/s   rMB/s   wMB/s  %util  await
nvme0n1          12.1   210.3    0.3     8.7   98.9   45.2

Interpretación: %util cerca de 100 y await alto significan que el almacenamiento está saturado. IMAP se sentirá “caído” mientras servicios están técnicamente arriba.

Decisión: Reduce carga (limita concurrencia), mueve índices a almacenamiento más rápido o escala IOPS. No sigas culpando a Postfix; solo está ahí.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Algunos remitentes entregan al servidor antiguo durante horas

Causa raíz: Registros MX en caché o remitente que ignora TTL bajos; cambiaste TTL demasiado tarde o algunos resolvers lo ignoran.

Solución: Mantén el servidor antiguo disponible. O bien difiere entrante con 4xx para que remitentes reintenten y sigan el nuevo MX más tarde, o reenvía temporalmente al servidor nuevo.

2) Síntoma: Los usuarios ven mensajes duplicados tras la migración

Causa raíz: UID/UIDVALIDITY de IMAP cambió por reinicio de metadata del buzón o conversión de formato sin preservar estado.

Solución: Prefiere dsync. Preserva metadata de Dovecot (índexes, GUIDs) cuando sea posible. Si ya está roto, aísla buzones afectados y resíncroniza limpiamente con guía para resetear caché del cliente.

3) Síntoma: “Autenticación fallida” en todas partes justo después del corte

Causa raíz: Servidor nuevo apuntando a base DN LDAP equivocada, falta config SASL o firewall bloqueando backend de auth.

Solución: Usa doveadm auth test y revisa logs SASL. Valida conectividad de red hacia LDAP/SQL desde el host nuevo.

4) Síntoma: SMTP acepta correo pero nunca llega a buzones

Causa raíz: Transporte de entrega Postfix mal configurado (ruta de socket LMTP incorrecta) o permisos/UID de vmail desajustados.

Solución: Verifica virtual_transport/mailbox_transport de Postfix y socket LMTP de Dovecot. Confirma propiedad y que first_valid_uid coincida con UID real de vmail.

5) Síntoma: El correo saliente va a spam o es rechazado después de la migración

Causa raíz: SPF no incluye nueva IP, DKIM no firma, PTR faltante o reputación fría de IP.

Solución: Publica SPF que incluya ambas IPs; asegura firmado DKIM; configura PTR y HELO para coincidir; escala salidas gradualmente si es posible.

6) Síntoma: IMAP está “arriba” pero resulta dolorosamente lento

Causa raíz: Cuello de botella de IOPS en almacenamiento, reindexado de Dovecot o antivirus/filtro de contenido consumiendo CPU/disco.

Solución: Revisa iostat, carga y conteo de procesos de Dovecot. Mueve índices a almacenamiento rápido, ajusta límites de procesos y evita indexado completo durante la ventana de corte.

7) Síntoma: 550 aleatorio “User unknown” para usuarios válidos

Causa raíz: Mapas de destinatario no cargados, credenciales SQL obsoletas o diferencias en sensibilidad a mayúsculas; a veces falta dominio en virtual_mailbox_domains.

Solución: Compara mapas Postfix viejo/nuevo y recarga. Prueba búsquedas directamente (SQL/LDAP) y verifica listas de dominios.

Tres micro-historias corporativas (cómo sale mal y cómo sale bien)

Micro-historia 1: El incidente por una suposición equivocada

Asumieron que bajar el TTL del registro MX significaba “todos cambiarán en cinco minutos”. Fue una suposición ordenada, del tipo que haces cuando tratas mayormente con DNS interno y descubrimiento de servicios en Kubernetes.

El corte fue a las 19:00. Cambiaron MX, vieron correo entrante golpear el servidor nuevo y declararon victoria. A las 21:30, un ejecutivo senior reenvió una queja de cliente: “Enviamos una actualización de contrato urgente hace dos horas. ¿Lo recibisteis?” Los logs del servidor nuevo no mostraban nada. Los logs del servidor antiguo sí.

Resultó que varias organizaciones asociadas usaban resolvers que ignoraron el nuevo TTL (o simplemente tenían la respuesta antigua en caché). Esos remitentes siguieron entregando al MX antiguo. Mientras tanto, el equipo ya había puesto el Postfix antiguo en “rechazar todo” con un 5xx porque querían forzar el tráfico al nuevo. SMTP hizo lo que SMTP hace: los remitentes rebotaron inmediatamente. Algunos de esos rebotes nunca llegaron a bandejas humanas porque… sí, su correo también estaba en flujo.

La solución no fue exótica. Cambiaron el servidor antiguo a diferir temporalmente con 4xx, así los remitentes encolaron y reintentaron. También añadieron un relay controlado desde el antiguo al nuevo para unas IPs de socio críticas. En un día todo se estabilizó.

La lección: no confundas “TTL bajo” con “internet obedeció”. Para seguridad en el corte, trata el servidor antiguo como capa de compatibilidad al menos por un ciclo completo de TTL más “gente que no cuida TTL”.

Micro-historia 2: La optimización que salió mal

Otra compañía decidió acelerar la migración ejecutando jobs rsync paralelos por dominio. Diez dominios, diez rsync, todos a la vez. Parecía eficiente en la pizarra y aterrador en iostat.

El servidor nuevo tenía CPUs rápidas y “SSD decentes”, así que esperaban que aguantara la carga. Pero las migraciones Maildir no son grandes escrituras secuenciales; son millones de creaciones de pequeños archivos, actualizaciones de metadata y tormentas de fsync. Los SSD evidenciaron latencias altas, los índices de Dovecot empezaron a expirar y las entregas de Postfix se acumularon porque escribir en disco era lento.

El equipo respondió añadiendo más concurrencia. Este es el error clásico: tratar un cuello de botella de almacenamiento como si fuera bound por CPU. La latencia empeoró. El servidor no cayó; estaba tan lento que los clientes reintentaban y amplificaban la carga. Una estampida autoinfligida.

Se recuperaron haciendo lo contrario de lo que instintivamente querían: redujeron la concurrencia de rsync a un job, activaron limitación de tasa y programaron la sincronización masiva fuera del horario laboral. Movieron el almacenamiento de índices de Dovecot a NVMe local rápido y mantuvieron el almacenamiento de correo en la matriz grande. Arquitectura aburrida, de repente excelente.

La lección: cuando creas millones de archivos, “más rápido” suele significar “menos concurrencia”. Tu cuello de botella es I/O de metadata, no el ancho de banda.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización tenía una política: toda migración debe incluir un plan de rollback por escrito y un simulacro de rollback en vivo para un buzón. La gente se quejaba de burocracia. También fue la razón por la que dormían tranquilos.

Durante su movimiento de correo, notaron que el saliente desde el servidor nuevo era intermitentemente diferido por un destinatario mayor. El entrante estaba bien. Los usuarios podían leer correo. Pero el saliente era un goteo de tickets “¿por qué no recibieron mi correo?”.

Porque tenían plan de rollback, no entraron en pánico. Simplemente movieron el tráfico de submission de vuelta al servidor antiguo para el saliente mientras mantenían el entrante en el nuevo. SPF ya autorizaba ambas IPs, las claves DKIM eran consistentes y el hostname cliente no había cambiado. Los usuarios casi no notaron nada excepto que el flujo de correo volvió.

En el día siguiente arreglaron el problema de entregabilidad: mismatch de reverse DNS y un HELO excesivamente estricto. Luego movieron el saliente de vuelta al nuevo servidor de forma controlada. Sin heroísmos. Sin rituales nocturnos de “simplemente reiniciarlo”.

La lección: el trabajo de ingeniería más valioso suele ser el menos glamuroso. Planear rollback no es pesimismo; es competencia.

Preguntas frecuentes

1) ¿Puedo realmente hacer una migración de correo con “cero tiempo de inactividad”?

Puedes acercarte: mínima interrupción visible y sin correo perdido. Pero no puedes detener el caching de DNS ni garantizar el comportamiento de todos los remitentes. Planifica una congelación corta y un periodo de coexistencia.

2) ¿Debería mover MX primero o el hostname de IMAP/submission primero?

En la mayoría de organizaciones: estabiliza IMAP/submission primero (mismo hostname, TLS válido), luego corta MX. Los usuarios notan la caída de IMAP de inmediato; los retrasos SMTP entrantes suelen tolerarse porque SMTP reintenta.

3) ¿Es rsync seguro para Maildir?

Mayormente, si lo haces en dos pasadas y aceptas que cambios concurrentes pueden competir. Para la sincronización final, una congelación corta es más limpia. Si tienes Dovecot en ambos lados, dsync suele ser más seguro para consistencia de metadata.

4) ¿Y el almacenamiento mbox?

Mbox bajo escrituras concurrentes es arriesgado de copiar con rsync porque puedes capturar escrituras parciales o estados de bloqueo extraños. Prefiere migración a nivel de aplicación o convertir a Maildir con procedimiento controlado y ventana de downtime.

5) ¿Necesito migrar índices de Dovecot?

No estrictamente, pero reconstruirlos puede causar I/O pesado y IMAP lento tras el corte. Si puedes migrar índices de forma segura y son compatibles, puede reducir el dolor post-corte. Prueba primero.

6) ¿Cómo manejo el correo que llega al servidor antiguo tras el corte?

O bien difieres con 4xx para que los remitentes reintenten al nuevo MX, o retransmites temporalmente al servidor nuevo. Si retransmites, implementa prevención de bucles y limita el tiempo.

7) ¿Debo mantener la misma clave DKIM o rotarla?

Mantén la misma clave/selector DKIM durante la migración si puedes. Rótala después. La semana de migración no es momento para “mejorar higiene de seguridad” a la vez, a menos que disfrutes modos de fallo combinados.

8) ¿Cuánto tiempo debo mantener el servidor antiguo?

Al menos el tiempo suficiente para cubrir cachés de DNS y sistemas rezagados que envían o entregan al host antiguo. Comúnmente una a dos semanas para organizaciones cautelosas, menos si tienes observabilidad y control completos.

9) ¿Cuál es la causa más común de reportes “mi buzón está vacío”?

Desajustes de permisos/propiedad, mail_location equivocado o mapeo de auth que envía a usuarios a una ruta diferente de la esperada. Menos frecuente: cambios de UIDVALIDITY que confunden al cliente.

10) ¿Cómo sé que es seguro restaurar TTLs altos?

Cuando los logs muestran ingreso insignificante al servidor antiguo, el saliente es estable desde la nueva IP y no ves conexiones cliente rezagadas a endpoints antiguos.

Siguientes pasos (prácticos, no motivacionales)

1. Baja TTLs para MX y hostnames de correo 24–48 horas antes y verifica con dig.
2. Construye el servidor nuevo para que coincida con el comportamiento antiguo: puertos, TLS, auth, dominios, filtros, cuotas.
3. Ejecuta una sincronización masiva, luego una incremental, y mide deltas para predecir la ventana final.
4. Valida con buzones reales y pruebas end-to-end SMTP/IMAP antes de tocar DNS.
5. Corta con una congelación corta, prefiere diferimientos 4xx sobre rechazos permanentes en el servidor antiguo.
6. Monitorea como un profesional: colas, fallos de auth, latencia de almacenamiento y comportamiento DKIM/SPF.
7. Mantén el rollback fácil: servidor antiguo intacto, SPF incluye temporalmente ambas IPs y no borres nada hasta tener una semana tranquila.

Si sigues estos pasos, la migración se vuelve agradablemente aburrida. Y aburrido es el mayor cumplido que le puedes dar a un sistema de correo.