Fallas de inicio de sesión IMAP en Dovecot: dónde falla la autenticación y cómo arreglarlo

Cómo funciona realmente la autenticación IMAP en Dovecot (y dónde falla)

La autenticación de Dovecot es una tubería. Tu cliente habla IMAP con el servicio IMAP. Ese servicio entrega las credenciales al servicio auth de Dovecot. Auth consulta uno o más backends passdb para verificar el secreto, luego uno o más backends userdb para mapear el usuario a UID/GID/home/ubicación del correo. Después el proceso IMAP intenta abrir el buzón con esas credenciales y permisos del sistema de ficheros. Si cualquier etapa falla, el usuario experimenta lo mismo: “Inicio de sesión fallido.” Por eso no puedes solucionar esto por corazonadas.

Las etapas que debes tener claras

1. Etapa de red/TLS: el cliente llega al servidor; TLS negocia si se requiere.
2. Etapa de protocolo IMAP: el cliente envía LOGIN/AUTHENTICATE; el servidor ofrece mecanismos (PLAIN, LOGIN, SCRAM, OAUTHBEARER, etc.).
3. Etapa de auth de Dovecot: el proceso auth (y sus workers) ejecuta las comprobaciones de passdb.
4. Etapa de mapeo de usuario: userdb resuelve UID/GID/home/ruta del correo; se pueden inyectar campos extra opcionales (cuota, espacios de nombres, ACLs).
5. Etapa de acceso al buzón: Dovecot abre el almacenamiento de correo (Maildir, mdbox, sdbox, etc.), adquiere locks y lee índices.

Estás buscando la primera etapa que falla. Todo lo que viene después es daño colateral.

Una opinión que vale la pena adoptar: trata las fallas de autenticación como un problema de observabilidad primero, y de configuración segundo. No arreglas lo que no puedes ver.

Una cita para mantener la honestidad: “La esperanza no es una estrategia.” — Gen. Gordon R. Sullivan

Broma corta #1: Los bugs de autenticación son como las cebollas: tienen capas, y hacen llorar a alguien. Normalmente al de guardia.

Guía de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Este es el camino más corto hacia la causa raíz cuando fallan los inicios de sesión IMAP. Ejecútalo en orden. No te saltes pasos porque “ya lo sabes”. Así es como los incidentes pasan de molestos a épicos.

Primero: confirma qué está fallando realmente (TLS, auth o buzón)

• Revisa los logs en busca de la línea de error canónica (auth failed vs. userdb vs. permisos de buzón).
• Reproduce con una ruta de cliente conocida buena (doveadm auth test y una comprobación IMAP con openssl s_client).

Segundo: aísla la tubería de auth de Dovecot (passdb/userdb)

• Usa doveconf -n para ver la configuración activa (no lo que crees que desplegaste).
• Prueba passdb (verificación de contraseñas) y prueba userdb (UID/GID/home/mail).
• Observa fallos de workers (timeouts, permisos del socket de auth, conectividad SQL/LDAP).

Tercero: valida el acceso al almacenamiento como el usuario mapeado

• Confirma el UID/GID que Dovecot elige y si ese usuario puede leer el almacenamiento de correo.
• Busca errores de lock/índice que se hacen pasar por problemas de inicio de sesión (especialmente con mdbox y almacenamiento tipo NFS).

Si haces solo estos tres pasos, resolverás la mayoría de tickets “IMAP login failed” con menos drama y menos rituales de “reiniciemos todo”.

Hechos interesantes y contexto histórico (breve, útil y algo nerd)

• IMAP precede a las pilas modernas de “identidad”. IMAP creció con autenticación simple usuario/contraseña; añadir OAuth es un cambio tardío en su ciclo de vida.
• Dovecot se popularizó en parte por su cuidado con el almacenamiento de correo. Rendimiento e integridad de buzones fueron diferenciadores importantes frente a servidores IMAP antiguos.
• CRAM-MD5 existe porque las contraseñas en texto claro daban miedo incluso en los 90. También recuerda que “seguro legado” puede ser una “liabilidad moderna”.
• STARTTLS en IMAP (puerto 143) es históricamente común en empresas. Pero TLS implícito en 993 es operacionalmente más sencillo porque menos middleboxes lo manipulan.
• El auth de Dovecot está dividido en procesos master/auth/workers. Esa separación reduce el radio de explosión: un worker que cae no debería tumbar todo tu servicio IMAP.
• Maildir vs mdbox no es solo preferencia. Cambia el comportamiento de locking, patrones de índice y modos de fallo (especialmente en almacenamiento en red).
• “userdb” no es opcional en la práctica. Incluso cuando passdb tiene éxito, un mapeo userdb malo puede hacer que los inicios de sesión fallen o que los errores de apertura de correo parezcan problemas de auth.
• Desajustes de UID/GID son un clásico tras migraciones. Servidores antiguos y nuevos discrepan en IDs numéricos, y los maildirs no se preocupan por tus sentimientos.

Tareas prácticas: comandos, salida esperada y decisiones (12+)

Estas son tareas probadas en campo que puedes ejecutar bajo presión. Cada una incluye: el comando, qué significa la salida y qué decisión tomas a continuación.

Task 1: Confirmar que Dovecot está realmente en ejecución y escuchando

cr0x@server:~$ systemctl status dovecot
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled)
     Active: active (running) since Mon 2026-01-03 09:12:19 UTC; 2h 3min ago
...

Significado: Si no está activo, no tienes un “problema de auth”, tienes un “servicio caído”.

Decisión: Si aparece inactive/failed, inspecciona journalctl -u dovecot antes de reiniciar. Si está activo, sigue adelante.

cr0x@server:~$ ss -lntp | egrep ':143|:993'
LISTEN 0 100 0.0.0.0:143 0.0.0.0:* users:(("dovecot",pid=1123,fd=45))
LISTEN 0 100 0.0.0.0:993 0.0.0.0:* users:(("dovecot",pid=1123,fd=46))

Significado: Los puertos están enlazados. Si falta 993, fallan clientes TLS-only. Si falta 143, fallan despliegues STARTTLS.

Decisión: Igualar lo que esperan los clientes. No adivines; verifica la configuración del cliente o la línea base conocida.

Task 2: Leer las últimas 200 líneas de log de Dovecot como humano

cr0x@server:~$ journalctl -u dovecot -n 200 --no-pager
Jan 03 10:58:12 mail dovecot[22144]: imap-login: Disconnected (auth failed, 1 attempts): user=<alice@example.com>, method=PLAIN, rip=203.0.113.50, lip=192.0.2.10, TLS, session=<...>
Jan 03 10:58:14 mail dovecot[22144]: auth: passwd-file(alice@example.com,203.0.113.50): unknown user

Significado: El servicio IMAP reporta “auth failed”; el servicio auth dice “unknown user.” Eso no es una contraseña mala; es una falla de búsqueda.

Decisión: Enfócate en la configuración de passdb/userdb y la normalización de identidad (nombres de usuario, dominios), no en los hashes de contraseña.

Task 3: Volcar la configuración efectiva de Dovecot (no la que crees que desplegaste)

cr0x@server:~$ doveconf -n
auth_mechanisms = plain login
disable_plaintext_auth = yes
mail_location = maildir:/var/vmail/%d/%n/Maildir
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
ssl = required

Significado: Esta es la verdad con la que Dovecot se está ejecutando. doveconf -n muestra overrides y valores resueltos.

Decisión: Si la configuración no coincide con lo esperado, detente. Arregla el despliegue/gestión de configuración primero; depurar la configuración equivocada es arte performativo.

Task 4: Probar auth sin clientes IMAP (verificación de passdb)

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

Significado: La verificación de contraseña funciona. Si IMAP aún falla, la ruptura probablemente sea TLS, desajuste de mecanismo SASL, mapeo userdb o acceso al buzón.

Decisión: Ejecuta una consulta userdb después, y reproduce vía IMAP con logs de depuración.

cr0x@server:~$ doveadm auth test alice@example.com 'wrongpassword'
passdb: alice@example.com auth failed

Significado: Esa es una falla real de contraseña. Ahora revisas hashing, corrección de la consulta SQL o el proveedor de identidad upstream si aplica.

Decisión: No toques permisos del sistema de ficheros todavía. No te has ganado ese desvío.

Task 5: Probar el mapeo userdb (UID/GID/home/ubicación del correo)

cr0x@server:~$ doveadm user alice@example.com
field	value
uid	vmail
gid	vmail
home	/var/vmail/example.com/alice
mail	maildir:/var/vmail/example.com/alice/Maildir

Significado: Dovecot sabe dónde debería vivir el buzón y con qué usuario/grupo lo accederá.

Decisión: Si UID/GID faltan o son incorrectos, corrige la consulta userdb o el mapeo estático. Si parecen correctos, valida el sistema de ficheros a continuación.

Task 6: Validar conectividad SQL y las consultas exactas que ejecuta Dovecot

cr0x@server:~$ doveadm -Dv auth test alice@example.com 'CorrectHorseBatteryStaple'
...
sql(alice@example.com): query: SELECT username, password FROM users WHERE username = 'alice@example.com'
sql(alice@example.com): result: username=alice@example.com password={BLF-CRYPT}$2y$10$...
passdb: alice@example.com auth succeeded
...
sql(alice@example.com): query: SELECT home, uid, gid FROM users WHERE username = 'alice@example.com'
sql(alice@example.com): result: home=/var/vmail/example.com/alice uid=vmail gid=vmail

Significado: Puedes ver consultas reales y resultados. Esto es oro cuando tu configuración SQL “se ve bien” pero no lo está.

Decisión: Si las consultas no devuelven filas, arregla el esquema/cláusula where/normalización del nombre de usuario. Si son lentas, revisa la latencia DB e índices.

Task 7: Comprobar la salud de los auth workers y timeouts

cr0x@server:~$ journalctl -u dovecot --no-pager | egrep 'auth-worker|timeout|BUG|panic' | tail -n 30
Jan 03 10:41:02 mail dovecot[1128]: auth-worker(21987): Error: sql(alice@example.com): Connection timed out
Jan 03 10:41:02 mail dovecot[1128]: auth: Error: auth-worker exited unexpectedly

Significado: Tus fallas de auth están en cascada desde timeouts de dependencias. El DB/LDAP es el incidente real.

Decisión: Trátalo como una caída de dependencia: revisa la alcanzabilidad DB, límites de pool, TLS hacia el DB y políticas de red.

Task 8: Reproducir un inicio de sesión IMAP manualmente sobre TLS para separar protocolo/TLS de internos de Dovecot

cr0x@server:~$ openssl s_client -connect 127.0.0.1:993 -crlf -quiet
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a login alice@example.com "CorrectHorseBatteryStaple"
a OK [CAPABILITY IMAP4rev1 SASL-IR ...] Logged in

Significado: TLS funciona y el login IMAP tiene éxito desde localhost. Si usuarios remotos aún fallan, probablemente tienes problemas de firewall/NAT/intercepción TLS o restricciones del mecanismo en el cliente.

Decisión: Compara la ruta remota con la local. Revisa certificados, SNI y si un balanceador de carga termina TLS correctamente.

cr0x@server:~$ openssl s_client -connect 127.0.0.1:993 -crlf -quiet
* OK Dovecot ready.
a login alice@example.com "wrongpassword"
a NO [AUTHENTICATIONFAILED] Authentication failed.

Significado: Ahora tienes una reproducción clara de una falla de auth real. Los logs deberían alinearse con esta sesión.

Decisión: Habilita debug de auth dirigido y vuelve a probar una vez, no por una hora.

Task 9: Comprobar rápidamente la validez y cadena del certificado TLS

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mail.example.com
issuer=CN = Example Issuing CA
notBefore=Dec 15 00:00:00 2025 GMT
notAfter=Mar 15 23:59:59 2026 GMT

Significado: Si el certificado está caducado o el CN/SAN es incorrecto, muchos clientes fallarán antes de que comience la autenticación.

Decisión: Arregla el certificado y la cadena primero. No “soluciones alternativas” con auth en texto claro en 2026.

Task 10: Verificar permisos del socket de auth (común al integrar SASL de Postfix también)

cr0x@server:~$ ls -l /var/spool/postfix/private/auth
srw-rw---- 1 postfix dovecot 0 Jan  3 10:12 /var/spool/postfix/private/auth

Significado: El socket existe y es escribible por Postfix. Propiedad/modo erróneos causan fallos SASL para SMTP, y a veces la gente lo confunde con problemas IMAP.

Decisión: Si los permisos son incorrectos, arregla service auth { unix_listener ... } y recarga Dovecot.

Task 11: Confirmar que la ruta del buzón mapeada existe y es accesible

cr0x@server:~$ getent passwd vmail
vmail:x:5000:5000::/var/vmail:/usr/sbin/nologin

cr0x@server:~$ sudo -u vmail test -d /var/vmail/example.com/alice/Maildir && echo OK || echo NO
OK

Significado: El buzón existe y el usuario en tiempo de ejecución puede verlo. Si esto falla, Dovecot puede autenticar la contraseña pero aún así negar el inicio de sesión o fallar justo después.

Decisión: Corrige propiedad/permisos, o corrige el mapeo userdb para que Dovecot apunte a la ubicación real.

Task 12: Buscar casos que “parecen auth” pero son corrupción de buzón/índice o errores de lock

cr0x@server:~$ journalctl -u dovecot --no-pager | egrep 'Permission denied|Corrupted|Mailbox is locked|Index' | tail -n 40
Jan 03 11:02:31 mail dovecot[23102]: imap(alice@example.com): Error: open(/var/vmail/example.com/alice/Maildir/dovecot.index) failed: Permission denied

Significado: Auth puede estar bien; la apertura del buzón falla. Los usuarios lo experimentan como “no puedo iniciar sesión” porque la sesión se cierra inmediatamente después del login o durante SELECT INBOX.

Decisión: Arregla ACLs/propiedad del sistema de ficheros. Luego considera reconstruir índices si es necesario (con cuidado).

Task 13: Activar debug de auth dirigido (de forma segura) para capturar la ruptura exacta

cr0x@server:~$ sudo doveconf -n | egrep 'auth_debug|auth_verbose|mail_debug'

cr0x@server:~$ sudo sed -i 's/^#\?auth_verbose.*/auth_verbose = yes/' /etc/dovecot/conf.d/10-logging.conf
cr0x@server:~$ sudo sed -i 's/^#\?auth_debug.*/auth_debug = yes/' /etc/dovecot/conf.d/10-logging.conf
cr0x@server:~$ sudo systemctl reload dovecot

Significado: Has incrementado la visibilidad de auth. Hazlo brevemente en producción; puede filtrar metadata en los logs.

Decisión: Reproduce una vez, captura las líneas relevantes y luego desactívalo.

Task 14: Validar el comportamiento de PAM al usar usuarios del sistema (común en sistemas pequeños)

cr0x@server:~$ doveconf -n | egrep 'passdb|pam'
passdb {
  driver = pam
}

cr0x@server:~$ sudo tail -n 50 /var/log/auth.log
Jan 03 11:11:10 mail dovecot: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=203.0.113.50  user=bob

Significado: PAM está rechazando el login. La falla puede ser contraseña incorrecta, cuenta bloqueada, política de expiración o el orden de módulos PAM.

Decisión: Revisa el estado de la cuenta y la pila PAM. No “arregles” Dovecot cuando PAM está haciendo exactamente lo que se le pidió.

Dónde falla la autenticación: modos de fallo por etapa

Etapa 1: Red y TLS (fallos que parecen “auth”)

Los clientes a menudo confunden conectividad y autenticación en el mismo error visible para el usuario. Tu trabajo es separarlos.

• Firewall/NAT: Algunos usuarios tienen éxito, otros fallan. Revisa security groups y allowlists por geo/IP.
• Desajuste en el handshake TLS: Clientes antiguos requieren cifrados legacy; servidores modernos los rechazan. O un middlebox termina TLS y lo re-encripta con un certificado distinto.
• Desajuste SNI/certificado: Implementaciones multi-dominio fallan si el cliente llega con el nombre incorrecto o el proxy no pasa SNI.

Arregla TLS primero. Desactivar requisitos de TLS para “dejar que entren usuarios” es como quitar los frenos para que el coche vaya más rápido cuesta abajo.

Etapa 2: Negociación de mecanismos IMAP

Dovecot anuncia mecanismos vía CAPABILITY. Los clientes eligen según la política. Los patrones de desajuste son previsibles:

• disable_plaintext_auth = yes sin TLS: el cliente intenta PLAIN/LOGIN sin cifrado y es rechazado.
• Mecanismos eliminados: desactivaste LOGIN y el cliente no puede hacer PLAIN con SASL-IR, o no puede usar SCRAM. Resultado: “authentication failed” pero en realidad “sin mecanismo compatible”.
• OAuth/OAUTHBEARER: clientes modernos pueden intentar OAUTHBEARER primero; si tu backend está medio configurado, verás retrocesos confusos.

Etapa 3: fallo de passdb (problemas reales de autenticación)

passdb es donde se verifica el secreto. Las fallas suelen ser:

• Usuario no encontrado: la consulta SQL/LDAP no devuelve filas. Causas comunes: filtro incorrecto, dominio equivocado, formato de usuario inesperado, espacios finales o sensibilidad a mayúsculas.
• Desajuste de hash de contraseña: esquema de hash distinto (bcrypt vs SHA512-CRYPT), campo de consulta equivocado o que el hash almacenado fue “útilmente” re-codificado.
• Fallo de dependencia: timeouts DB, fallos TLS en LDAP, problemas DNS, agotamiento del pool de conexiones.

Etapa 4: fallo de userdb (te autenticaron, ahora no puedes convertirte en usuario)

Este es el asesino silencioso. passdb dice sí, userdb dice “no sé quién eres” y la sesión muere.

• UID/GID faltantes: Dovecot no puede determinar con qué usuario ejecutarse, o usa valores por defecto que no coinciden con la propiedad del buzón.
• Ruta home/mail equivocada: userdb apunta a una ruta inexistente, o un servidor usa /var/mail/vhosts mientras otro usa /var/vmail.
• Sobrescrituras por usuario mal aplicadas: inyectas el campo mail o ajustes de namespace por usuario y accidentalmente rompes un subconjunto.

Etapa 5: fallo de acceso al buzón (auth tuvo éxito, la realidad se negó)

Signos clásicos: los usuarios “inician sesión” pero enseguida se desconectan, o no se puede seleccionar INBOX, o solo algunas carpetas funcionan.

• Permisos del sistema de ficheros: UID/GID incorrectos, falta del bit de ejecución en directorios, ACLs no aplicadas o denegación de SELinux/AppArmor.
• Problemas de índice y lock: índices corruptos, timeouts de lock o almacenamiento que no respeta semántica de locking POSIX.
• Comportamiento del plugin de cuota: advertencias o fallos duros de cuota que impiden appends; algunos clientes interpretan eso como “problemas de login”.

Broma corta #2: Si “arreglaste” IMAP reiniciando Dovecot, felicidades—has descubierto el equivalente TI de apagarlo y volverlo a encender.

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

1) Síntoma: “Authentication failed” inmediatamente para todos los usuarios

Causa raíz: backend passdb inaccesible (SQL/LDAP caído, fallo DNS, TLS hacia el DB roto), o los auth workers no pueden conectar.

Solución: Confirma con doveadm -Dv auth test y logs que muestren timeouts. Restaura conectividad DB/LDAP, revisa reglas de firewall y verifica credenciales en dovecot-sql.conf.ext.

2) Síntoma: Solo fallan usuarios remotos; pruebas desde localhost funcionan

Causa raíz: intercepción/proxy TLS mal configurado, desajuste SNI o diferencias en políticas de red (WAF, geo-blocking).

Solución: Compara openssl s_client desde un host remoto, verifica la cadena del certificado y asegúrate de que el proxy pase SNI y ALPN como se espera.

3) Síntoma: “Unknown user” para usuarios que existen

Causa raíz: normalización de nombre de usuario errónea: el cliente envía alice pero la BD guarda alice@example.com, o viceversa; o el stripping de dominio se agregó/quitó durante la migración.

Solución: Decide un formato canónico de nombre de usuario. Actualiza auth_username_format de Dovecot y las consultas SQL/LDAP en consecuencia. Verifica con salida de debug que muestre la consulta.

4) Síntoma: Algunos usuarios pueden iniciar sesión; otros no; el patrón coincide con un dominio

Causa raíz: bug de mapeo multi-dominio: manejo de %d en mail_location, fila de dominio faltante en la BD, o desajuste de proxy/virtual host.

Solución: Ejecuta doveadm user user@domain para los dominios afectados y compara las rutas home/mail resueltas.

5) Síntoma: El inicio de sesión tiene éxito, luego desconexión inmediata o “Mailbox doesn’t exist”

Causa raíz: userdb apunta a una ruta de buzón incorrecta; o permisos de almacenamiento niegan a Dovecot la lectura de índices.

Solución: Valida los campos con doveadm user, luego prueba el acceso al directorio con sudo -u vmail. Corrige propiedad y rutas.

6) Síntoma: Funciona un tiempo, luego auth empieza a hacer timeouts bajo carga

Causa raíz: saturación de auth workers: límites de conexiones DB, coste de hashing de contraseñas alto, o latencia LDAP. Los workers de auth se encolan.

Solución: Mide latencia DB, añade índices, ajusta tamaños de pool y considera cachear con cuidado. Aumenta procesos de auth solo después de confirmar que el backend puede soportarlo.

7) Síntoma: “Plaintext authentication disallowed”

Causa raíz: disable_plaintext_auth = yes mientras clientes intentan LOGIN/PLAIN sin TLS, a menudo por no usar STARTTLS.

Solución: Forzar TLS implícito en 993 o asegurar que STARTTLS esté habilitado y los clientes configurados para usarlo. No relajes la seguridad para acomodar clientes rotos sin un plan.

8) Síntoma: Tras la migración, las contraseñas de todos “dejaron de funcionar”

Causa raíz: desajuste de esquema de hash, o el campo DB se transformó (truncado, cambio de codificación, espacios añadidos).

Solución: Confirma los esquemas de hash que Dovecot soporta y el formato almacenado. Prueba un usuario con doveadm auth test y confirma que el prefijo del hash retornado coincide con el esquema esperado.

Tres micro-historias corporativas de producción

Incidente causado por una suposición incorrecta: “Es solo la contraseña”

La avalancha de tickets empezó un lunes por la mañana, lo cual ya es un crimen. Una oficina regional no podía iniciar sesión en IMAP después de un “cambio rutinario de seguridad”. El relato de la mesa de ayuda era claro: “Las contraseñas no funcionan.” Así que la primera respuesta fue predeciblemente desordenada: reseteos, más reseteos y algunos reseteos ejecutivos por si acaso.

En el lado del correo, nada estaba obviamente caído. Dovecot funcionaba bien. SQL era alcanzable. doveadm auth test tuvo éxito para varios usuarios. Ahí es cuando la historia cambia: no son las contraseñas. Es la ruta del cliente.

Resultó que el “cambio rutinario de seguridad” fue una política de inspección TLS aplicada al proxy saliente de esa oficina. El proxy re-firmaba certificados con una CA interna que las máquinas Windows confiaban, pero varios clientes móviles no. Esos clientes fallaban el handshake TLS y mostraban “error de autenticación” porque el UX de la app decidió que era lo suficientemente cercano.

La solución no estuvo en Dovecot. La solución fue: dejar de interceptar IMAPS, o desplegar la CA en los dispositivos que la necesitan, y hacer la política explícita. La lección importante: si el inicio de sesión IMAP local funciona pero el remoto falla, no estás depurando autenticación—estás depurando la ruta entre el usuario y el puerto.

Además, deja de resetear contraseñas como herramienta diagnóstica. Destruye la señal y entrena a la organización para resolver problemas técnicos con ritual.

Optimización que salió mal: “Subamos workers de auth”

Un entorno diferente tenía fallos intermitentes de inicio de sesión en horas pico. Los logs de Dovecot mostraban timeouts de auth hablando con el backend SQL. Alguien notó que Dovecot tenía procesos auth configurables y decidió “aumentar paralelismo” como optimización. Subieron más workers y declararon victoria tras cinco minutos calmados.

Llegó la hora pico otra vez, y el sistema se cayó con más estrépito. ¿Por qué? Porque la base de datos no era lenta por falta de concurrencia—era lenta por contención. Más auth workers significaron más conexiones SQL concurrentes, lo que causó más contención de locks, consultas más lentas y colas de auth más largas. El servicio de auth no solo falló; falló a lo grande.

La solución eventual fue aburrida y efectiva: añadir el índice correcto para la búsqueda por nombre de usuario, reducir el coste de la consulta y dimensionar el pool de conexiones con intención. El conteo de workers de Dovecot volvió a un valor sensato. El sistema se estabilizó sin teatrillos.

La lección: si tu backend es el cuello de botella, la paralelización no es comida gratis. Es una factura con intereses.

Práctica aburrida pero correcta que salvó el día: “Teníamos una prueba de auth conocida y logs”

Una actualización de clúster de correo introdujo una regresión sutil: un subconjunto de usuarios podía autenticarse pero se desconectaba al acceder a INBOX. El incidente podría haber salido mal rápidamente porque el síntoma parecía falla de auth en las apps. Pero el equipo tenía un hábito que suena aburrido hasta que lo necesitas: una checklist de pre-actualización y post-actualización con pruebas doveadm y un pequeño banco de cuentas sintéticas.

En minutos confirmaron que passdb funcionaba y que el mapeo userdb devolvía valores correctos. Luego usaron una de las cuentas sintéticas para iniciar sesión vía openssl s_client y vieron un error justo después del login: una denegación de permiso de índice en la nueva ubicación de correo. Eso lo acotó a layout/propiedad del sistema de ficheros, no a credenciales.

La causa raíz fue un paso omitido en el despliegue: una rutina de creación de directorios se ejecutó como root y creó nuevos directorios de índices por usuario con propiedad root. Los usuarios existentes tenían directorios antiguos propiedad de vmail, pero los usuarios tocados por el despliegue tenían paths propiedad de root. Clásico split-brain por propiedad.

La solución fue una corrección de propiedad dirigida y un hook de despliegue para crear directorios con UID/GID correctos. Sin reseteos de contraseña. Sin reinicios aleatorios. Solo diagnóstico controlado y un cambio que hizo al sistema menos frágil.

La lección: prueba las cosas aburridas antes de enviar. Es más barato que una llamada de bridge de incidentes donde todos dicen “funcionaba ayer” como si eso fuera una métrica.

Listas de verificación / plan paso a paso (aburrido a propósito)

Plan paso a paso cuando falla el inicio de sesión IMAP

1. Confirma el alcance: ¿un usuario, un dominio, un segmento de red o global?
2. Captura una sola reproducción: hora, nombre de usuario, IP de origen, tipo de cliente y si es 993 o STARTTLS en 143.
3. Revisa logs de Dovecot primero: identifica si dice auth failed, unknown user, userdb missing o permission denied.
4. Ejecuta doveconf -n: verifica que estás depurando la configuración activa.
5. Ejecuta doveadm auth test: confirma el comportamiento de passdb independiente de IMAP.
6. Ejecuta doveadm user: confirma el mapeo userdb y los campos de ubicación del correo.
7. Reproduce vía openssl s_client: valida TLS y la negociación de capacidad/mecanismo IMAP.
8. Revisa dependencias backend: alcanzabilidad SQL/LDAP, timeouts, TLS, credenciales y límites de pool.
9. Verifica permisos del sistema de ficheros como el usuario en tiempo de ejecución: home, maildir y archivos de índice.
10. Activa debug de auth dirigido brevemente si es necesario: reproduce una vez, captura y desactiva debug.
11. Arregla la causa raíz: configuración, backend o permisos—no los síntomas.
12. Verifica con tres rutas: doveadm, IMAPS local y IMAPS remoto.

Checklist operativa para cambios que comúnmente rompen auth

• Renovaciones de certificados TLS: verifica notAfter y la cadena antes del despliegue.
• Cambios de esquema DB: verifica que las consultas SQL exactas de Dovecot sigan devolviendo filas.
• Cambios en el formato de nombre de usuario: decide un formato canónico y aplícalo consistentemente.
• Migraciones de almacenamiento: verifica propiedad UID/GID y prueba abrir buzones, no solo auth.
• Cambios de proxy/LB: confirma SNI, terminación vs passthrough y logging de IP de origen.
• Endurecimiento de seguridad: revisa auth_mechanisms y compatibilidad de clientes antes de deshabilitar métodos legacy.

FAQ

1) ¿Por qué Dovecot dice “auth failed” cuando el problema real es TLS?

Muchos clientes mapean cualquier falla de conexión a “autenticación”. Los logs de Dovecot más una prueba con openssl s_client son la forma de separar problemas de handshake TLS de fallas reales de passdb.

2) ¿Cuál es la diferencia entre passdb y userdb, y por qué debería importarme?

passdb responde “¿es válida esta contraseña/token?” userdb responde “¿a qué UID/GID/home/ruta de correo se mapea este usuario?” Necesitas ambos. El éxito de passdb no garantiza que el buzón pueda abrirse.

3) Puedo autenticar con doveadm auth test pero IMAP aún falla. ¿Y ahora?

Prueba TLS y la negociación IMAP con openssl s_client, luego revisa doveadm user y permisos del sistema de ficheros. Este patrón suele significar desajuste de mecanismo/TLS o problemas de acceso al buzón.

4) ¿Qué suele significar “unknown user”?

Tu consulta passdb no devolvió resultados. Causas comunes: cláusula WHERE SQL incorrecta, filtro LDAP equivocado, formato de nombre de usuario (dominio faltante) o problemas de mayúsculas/espacios.

5) ¿Debo habilitar auth_debug en producción?

Brevemente, para una reproducción controlada, sí. Mantenerlo horas encendido, no. Aumenta el volumen de logs y puede filtrar metadata sensible. Enciéndelo, reproduce una vez, captura y apágalo.

6) Los usuarios pueden iniciar sesión pero algunas carpetas fallan o los clientes se desconectan. ¿Es autenticación?

Normalmente no. Eso es problema de apertura de buzón/índice/permisos. Busca “Permission denied”, “Mailbox is locked” y errores de índice en los logs.

7) ¿Cómo sé si mi backend SQL es el cuello de botella?

Los logs de Dovecot mostrarán timeouts SQL o consultas lentas en salida -Dv. Si las fallas de auth se correlacionan con picos de latencia DB, trátalo como un problema de capacidad de la dependencia, no de ajuste de Dovecot.

8) ¿Está bien permitir auth en texto claro para calmar a los usuarios?

No, no como “solución”. Si debes relajar temporalmente la configuración para desbloquear una migración, hazlo con límite de tiempo y plan de reversión. La solución real es asegurar TLS y configurar correctamente los clientes.

9) ¿Cómo diferencio una contraseña mala de un desajuste de esquema de hash?

Con doveadm -Dv auth test puedes ver el hash retornado y si Dovecot reconoce el prefijo del esquema. Si el esquema es erróneo o el hash está malformado, incluso contraseñas correctas fallarán.

Conclusión: próximos pasos prácticos

Cuando fallan los inicios de sesión IMAP en Dovecot, deja de discutir el síntoma y empieza a localizar la ruptura en la cadena. Revisa logs, confirma la configuración activa, prueba passdb y userdb de forma independiente, valida TLS y solo entonces explora permisos de sistema de ficheros e índices.

Próximos pasos que puedes hacer hoy:

• Guarda una versión del runbook de la Guía de diagnóstico rápido y las tareas de comandos anteriores.
• Crea dos cuentas de prueba sintéticas por dominio y automatiza doveadm auth test más un login IMAPS con openssl s_client.
• Baseline y monitoriza latencia de auth (tiempos de respuesta DB/LDAP, timeouts de workers) para ver la falla antes que los usuarios.
• Estandariza el formato de nombre de usuario y documéntalo como si fuera un contrato de API—porque lo es.

Haz eso, y la próxima página “IMAP login failed” será una investigación corta, no un momento de carrera profesional.