Correo: Buzón lleno — prevenirlo y recuperarlo sin problemas

noviembre 27, 2025 • febrero 3, 2026 • Lectura: 26 min • Views: 6

¿Te fue útil?

“Buzón lleno” es el tipo de fallo que parece menor hasta que bloquea la firma de un contrato, hace perder un restablecimiento de contraseña,
o rebota facturas durante una semana sin que nadie lo note. Nadie se fija en el primer rebote. La gente sí nota el tercer mensaje “Te escribí dos veces”.

Lo peor: los incidentes por buzón lleno suelen ser prevenibles. Lo segundo peor: cuando ocurren, el “arreglo rápido” equivocado
puede convertir un problema de almacenamiento en una pérdida de datos. Evitemos ambos.

Qué significa realmente “buzón lleno” (protocolo vs realidad de almacenamiento)

“Buzón lleno” suena simple. No lo es. Dependiendo del sistema, puede significar:

Cuota de usuario excedida (el plugin de cuota IMAP dice “no más”).
Backend de almacenamiento del buzón lleno (disco, dataset, volumen LVM, agotamiento de inodos).
Límite interno del almacén de mensajes (límites por carpeta, topes por buzón, políticas de tamaño máximo por mensaje).
El destinatario alcanzó el límite de su proveedor (no puedes arreglarlo; solo comunicar).
Fallas temporales mal reportadas (algunos MTAs rebotan con “buzón lleno” cuando el problema real es entrega/LMTP).

La distinción operacional que importa: ¿esto es un rechazo en tiempo SMTP (5xx/4xx durante la entrega) o un
diferimiento/cola que se acumula? El rechazo es doloroso para el remitente pero limpio para tus servidores.
El diferimiento es cómo terminas con una cola de correo que se hincha hasta convertirse en un incidente de almacenamiento.

Dónde aparece en el flujo

Pipeline típico: recepción SMTP (Postfix/Exim/Exchange) → cola → entrega local (LMTP/LDA) →
almacenamiento del buzón (Maildir/mbox/dbox, base de datos de Exchange) → acceso IMAP.

“Buzón lleno” puede originarse en el agente de entrega local (cuota) o en el sistema de ficheros (ENOSPC, EDQUOT, ENFILE, agotamiento de inodos),
y luego burbujear hasta el lado SMTP como motivo de rebote.

Si solo aprendes una cosa: trata “buzón lleno” como un problema de almacenamiento + política, no solo de correo.
La parte de correo es solo donde se hace visible.

Una cita para mantenerte honesto

Werner Vogels (idea parafraseada): Construyes el servicio, lo operas — la responsabilidad operacional pertenece a quienes lo construyen.

Datos interesantes y breve historia (porque este problema es más antiguo que tu pager)

Dato 1: El formato clásico mbox almacena un buzón entero en un solo fichero; un archivo enorme puede hacer que las fallas por “lleno” sean más catastróficas y lentas de reparar.
Dato 2: Maildir se diseñó en parte para evitar problemas de bloqueo de mbox usando un fichero por mensaje; cambia el recuento de ficheros/inodos por concurrencia más segura.
Dato 3: Los códigos de error SMTP tempranos establecieron el patrón: fallos permanentes (5xx) vs transitorios (4xx). “Buzón lleno” suele mapear a 552 o 452 según la política.
Dato 4: El agotamiento de inodos es un “disco lleno” real incluso cuando df muestra espacio libre—los servidores con mucho Maildir descubren esto por las malas.
Dato 5: Algunos sistemas de correo implementan cuotas en la capa de aplicación (Dovecot, límites de Exchange), no en el sistema de ficheros. Por eso el almacenamiento puede estar bien mientras falla la entrega.
Dato 6: Las extensiones IMAP QUOTA existen para que los clientes muestren a los usuarios que están cerca del límite. Muchas organizaciones no las habilitan y luego se preguntan por qué los usuarios se sorprenden.
Dato 7: El marketing de “buzón ilimitado” suele ocultar un límite práctico: tamaño máximo de adjunto, retención o throttling. El buzón no es infinito; los folletos sí.
Dato 8: El backscatter (rebotes a remitentes falsificados) era común cuando los MTAs aceptaban el correo y luego fallaban. Rechazar en SMTP es más limpio y considerado.

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

Estás de guardia. Alguien dice: “El correo está rebotando; buzón lleno.” No divagues. Haz esto.

Primero: determina alcance y si es cuota vs almacenamiento

¿Es un solo usuario o muchos? Revisa logs para ver si fallan varios destinatarios o un buzón repetidamente.
¿El servidor está realmente sin espacio o sin inodos? Revisa uso de sistema de ficheros y uso de inodos.
¿La cola del MTA está creciendo? Si crece rápido, puedes estar convirtiendo un problema de buzón en un fallo del servidor.

Segundo: identifica dónde falla la entrega

¿Rechazo SMTP en RCPT/DATA? Mira los logs de Postfix y los códigos de estado (552/452 vs “unknown” genérico).
¿Error LMTP/LDA? Dovecot normalmente emite mensajes de cuota claros, y puedes validar con doveadm.
¿Error del sistema de ficheros? ENOSPC/EDQUOT en logs significa que tu problema es la aplicación del almacenamiento, no la política de correo.

Tercero: elige la válvula de alivio menos destructiva

Si es sistema de ficheros lleno: libera espacio de forma segura (rotar logs, limpiar spool de correo diferido con cuidado, ampliar volumen). No borres archivos de correo al azar primero.
Si es cuota de usuario: aumenta la cuota temporalmente o fuerza limpieza/archivado (con consentimiento/política del usuario), luego entrega el backlog.
Si es destinatario remoto: evita tormentas de reintentos; ajusta tiempos de cola y comunica. Tus discos no deben pagar por la cuota de otro proveedor.

Broma #1: Los buzones son como los cajones de la cocina—nadie sabe qué hay dentro, pero de algún modo nunca cabe una cosa más.

Tareas prácticas: comandos, salidas y decisiones (12+ acciones reales)

Los comandos abajo asumen un servidor Linux con Postfix + Dovecot y almacenamiento Maildir.
Si usas Exchange o un servicio en la nube, muchas ideas aún aplican: revisa el store, revisa cuotas, revisa la cola y luego remedia con el menor riesgo de datos.

Task 1: Confirmar el error en los logs de correo (y si es por usuario)

cr0x@server:~$ sudo grep -E "quota|mailbox full|552 |452 |over quota|EDQUOT|ENOSPC" /var/log/mail.log | tail -n 20
Jan 04 10:12:19 mx1 postfix/lmtp[28177]: 3C1A12A0B3: to=<alex@example.com>, relay=imap1[10.0.2.10]:24, delay=2.1, delays=0.2/0.01/0.3/1.6, dsn=5.2.2, status=bounced (host imap1[10.0.2.10] said: 552 5.2.2 <alex@example.com> Quota exceeded (in reply to RCPT TO command))
Jan 04 10:12:20 mx1 postfix/qmgr[1123]: 3C1A12A0B3: removed

Qué significa: DSN 5.2.2 más “Quota exceeded” apunta a una cuota de aplicación en el lado de entrega (a menudo Dovecot).

Decisión: No amplíes el disco todavía. Valida la cuota del usuario, determina si es un buzón o una política que afecta a muchos.

Task 2: Comprobar uso de disco en el punto de montaje de almacenamiento de correo

cr0x@server:~$ df -hT /var/mail /var/vmail
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   80G   79G  1.1G  99% /
/dev/sdb1      xfs   2.0T  1.3T  700G  66% /var/vmail

Qué significa: El sistema raíz está casi lleno; /var/vmail está bien. Si la cola de Postfix o los logs viven en /, puedes fallar entregas aun con espacio en los buzones.

Decisión: Trátalo como un incidente de infraestructura: libera/expande la FS root inmediatamente, luego vuelve a comprobar el flujo de correo.

Task 3: Comprobar agotamiento de inodos (la broma favorita de Maildir)

cr0x@server:~$ df -ih /var/vmail
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sdb1        64M    63M   850K   99% /var/vmail

Qué significa: Funcionalmente te has quedado sin espacio porque te quedaste sin inodos. Maildir crea muchos ficheros pequeños; eso es normal… hasta que deja de serlo.

Decisión: Necesitas alivio de inodos: borrar/expirar correo según política, mover correo frío a un archivo, o rehacer con más inodos (a menudo significa nuevo sistema de ficheros o backend diferente).

Task 4: Comprobar tamaño de la cola de Postfix (¿se acumula el daño?)

cr0x@server:~$ mailq | tail -n 5
-- 10954 Kbytes in 1423 Requests.

Qué significa: 1423 mensajes en cola no es necesariamente fatal, pero es un mal síntoma. Si la cola crece, tu “problema de un buzón” se está volviendo “retraso de correo para todos”.

Decisión: Si el crecimiento de la cola lo causan pocos destinatarios, considera mapas de transporte temporales o retenciones para evitar tormentas de reintentos mientras arreglas cuotas/almacenamiento.

Task 5: Identificar los principales destinatarios en la cola

cr0x@server:~$ sudo postqueue -p | awk '/^[A-F0-9]/{id=$1} /to=

Qué significa: Unos pocos destinatarios dominan. Eso es o bien un problema de cuota para esos buzones o un patrón de spam/volumen.

Decisión: Arregla esos buzones primero, o cuarentenéalos para proteger el resto del sistema.

Task 6: Confirmar el estado de cuota de Dovecot para un usuario

cr0x@server:~$ sudo doveadm quota get -u alex@example.com
Quota name=User quota Type=STORAGE Value=5120M Limit=5120M %
Quota name=User quota Type=MESSAGE Value=98234 Limit=0 %

Qué significa: La cuota de almacenamiento está exactamente en el tope (5120M usados de 5120M). El conteo de mensajes es ilimitado (Limit=0).

Decisión: O aumentas la cuota temporalmente o aplicas limpieza/archivado. Prefiere limpieza respaldada por política sobre “subirla para siempre”.

Task 7: Localizar carpetas y ficheros más grandes en un Maildir (triaje rápido)

cr0x@server:~$ sudo du -h --max-depth=2 /var/vmail/example.com/alex/Maildir | sort -h | tail -n 10
1.2G    /var/vmail/example.com/alex/Maildir/.Sent
2.6G    /var/vmail/example.com/alex/Maildir/.Archive
5.1G    /var/vmail/example.com/alex/Maildir

Qué significa: Dos carpetas concentran la mayor parte del uso. Esto es buena noticia: puedes dirigir la limpieza sin explorar todo el buzón.

Decisión: Coordina con el usuario (o sigue la política de retención) para archivar/purgar primero Sent/Archive.

Task 8: Encontrar mensajes inusualmente grandes (a menudo adjuntos)

cr0x@server:~$ sudo find /var/vmail/example.com/alex/Maildir -type f -size +50M -printf "%s %p\n" | sort -nr | head
104857612 /var/vmail/example.com/alex/Maildir/cur/1704361234.M12345P6789.mx1,S=104857612:2,
73400612  /var/vmail/example.com/alex/Maildir/.Sent/cur/1704300044.M22222P1111.mx1,S=73400612:2,

Qué significa: Tienes mensajes de más de 50MB en el buzón. Son candidatos prioritarios para limpieza por el usuario o archivado automatizado.

Decisión: Si la política lo permite, mueve mensajes grandes/antiguos a un archivo. No borres a lo loco; la gente guarda PDFs “importantes” en el correo como si fuera un archivador.

Task 9: Recalcular y reparar la cuota de Dovecot (tras limpieza/movidas)

cr0x@server:~$ sudo doveadm quota recalc -u alex@example.com

cr0x@server:~$ sudo doveadm quota get -u alex@example.com
Quota name=User quota Type=STORAGE Value=4032M Limit=5120M %

Qué significa: La contabilidad de cuota ahora refleja la realidad. Sin esto, Dovecot puede seguir rechazando entregas aunque hayas liberado espacio.

Decisión: Si la entrega sigue rebotando, estás ante otro límite (sistema de ficheros, regla de cuota distinta, o backend de almacenamiento separado).

Task 10: Comprobar aplicación de cuotas en sistema de ficheros (EDQUOT) vs cuota de Dovecot

cr0x@server:~$ sudo dmesg | tail -n 20
[123456.789012] XFS (sdb1): Quotacheck needed: Please turn quotas off and on again.
[123457.001122] XFS (sdb1): User quota exceeded. UID: 5000

Qué significa: Las cuotas del sistema de ficheros están activas y se están aplicando. Dovecot puede estar inocente; el kernel está diciendo “no”.

Decisión: Corrige la política de cuotas a nivel kernel (auméntala, cambia el mapeo o repara el estado de cuotas), no solo la configuración de Dovecot.

Task 11: Verificar la ruta de transporte LMTP/LDA y los códigos de error

cr0x@server:~$ sudo postconf -n | egrep "^(myhostname|mydestination|virtual_transport|mailbox_transport|home_mailbox|virtual_mailbox_domains|virtual_mailbox_base|smtpd_recipient_restrictions)"
myhostname = mx1.example.net
virtual_transport = lmtp:imap1:24
virtual_mailbox_domains = example.com
virtual_mailbox_base = /var/vmail

Qué significa: El correo se entrega a Dovecot por LMTP. Eso es bueno: Dovecot producirá errores específicos de cuota y Postfix los mostrará.

Decisión: Concéntrate en la configuración de cuota de Dovecot y en la salud del almacenamiento de buzones, no en rarezas de mailbox_command.

Task 12: Inspeccionar logs de Dovecot por comportamiento del plugin de cuota

cr0x@server:~$ sudo grep -E "Quota|quota|overquota|mailbox.*full" /var/log/dovecot.log | tail -n 30
Jan 04 10:12:19 imap1 dovecot: lmtp(alex@example.com)<28177>: Error: quota: Quota exceeded (mailbox for user is full)
Jan 04 10:13:02 imap1 dovecot: imap(alex@example.com)<29001>: Disconnected: Logged out in=512 out=2048

Qué significa: Dovecot está rechazando explícitamente por cuota. Eso es concluyente.

Decisión: Aplica alivio de cuota (limpieza o aumento temporal), luego observa cómo se vacía la cola de Postfix.

Task 13: Vaciar o reencolar correo de forma segura tras arreglar la restricción

cr0x@server:~$ sudo postqueue -f

cr0x@server:~$ sudo postqueue -p | tail -n 5
-- 842 Kbytes in 97 Requests.

Qué significa: La cola se está vaciando y reduciendo. Si no se reduce, las entregas siguen fallando y debes volver a comprobar la razón del error.

Decisión: Si ves diferimientos repetidos para el mismo usuario, para y arregla la causa raíz; no abuses de los reintentos.

Task 14: Confirmar salud de servicios (IMAP/LMTP) tras cambios

cr0x@server:~$ sudo systemctl status dovecot --no-pager
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-01-04 09:55:22 UTC; 38min ago

Qué significa: Dovecot está en ejecución. Esto no prueba que las cuotas estén correctas, pero elimina “servicio caído” como culpable.

Decisión: Si el estado está inestable o fallando, revisa disco lleno en logs/runtime dirs, errores de configuración y ficheros TLS.

Task 15: Comprobar si el almacén de correo mantiene correo borrado (expunge/retención)

cr0x@server:~$ sudo doveadm mailbox status -u alex@example.com messages vsize deleted INBOX
messages=12450 vsize=3120M deleted=840

Qué significa: Hay muchos mensajes borrados que siguen ocupando espacio (común según comportamiento de clientes o ajustes del servidor).

Decisión: Ajusta la política de expunge o ejecuta un job de expunge según reglas de retención. “El usuario lo borró” no siempre significa “recuperamos disco”.

Recuperación limpia (sin liarla)

La recuperación es un problema de secuencia. Si haces pasos en el orden equivocado creas nuevos fallos:
índices corruptos, rebotados permanentes, o una cola de MTA que se come el filesystem root.

Caso A: El sistema de ficheros del servidor está lleno (o agotado de inodos)

Este es el urgente porque se propaga. Cuando el disco está lleno, todo empieza a fallar: entregas, logging, handshakes TLS que no pueden escribir estado,
incluso cachés de autenticación. Tu objetivo es la estabilidad primero, luego la “corrección del correo”.

Detener la hemorragia: si la cola es masiva y está creciendo, considera restringir entrada de correo temporalmente (limites de tasa, ajustes de greylisting, o failover de MX externo si lo tienes). Si no tienes un plan, al menos asegúrate de poder escribir logs.
Liberar espacio de forma segura: rotar/comprimir logs, limpiar paquetes viejos, borrar ficheros temporales. Evita borrar archivos del store de correo primero; es más lento, arriesgado y políticamente explosivo.
Si son inodos: identifica directorios con recuentos locos de ficheros (Maildir cur/new/tmp, cuarentena de spam) y aplica limpieza guiada por políticas (retención en junk, no en INBOX). Expandir inodos suele significar reconstruir el sistema de ficheros; trátalo como proyecto, no como hazaña a las 3 a.m.
Confirmar recuperación de servicios: Postfix, Dovecot, antivirus/milter y cualquier daemon de políticas.
Vacia la cola con cautela: una vez que la restricción desaparezca, vacía y monitoriza tasas de error. Un vaciado de cola puede parecer un DDoS contra tus nodos IMAP si no tienes cuidado.

Caso B: La cuota de un usuario está llena

Aquí es donde muchos equipos se ponen descuidados. Puedes “resolverlo” subiendo cuotas para siempre, que es como arreglar una tubería con fugas comprando un sótano más grande.
A veces lo haces—temporalmente—para que el negocio funcione. Pero hazlo explícitamente temporal.

Validar la autoridad de la cuota: ¿es Dovecot, cuota de sistema de ficheros, límite de Exchange o política cloud?
Confirmar uso real: mide tamaños de carpetas e identifica los mayores culpables (Sent, Archive, “Projects_2016_FINAL_FINAL”).
Aplicar alivio con trazabilidad: o bien purga según política de retención (preferible borrar basura/spam primero) o aumenta la cuota con ticket y fecha de expiración.
Recalcular cuotas/índices: no te saltes este paso. La contabilidad incorrecta genera llamadas “borré 2GB, ¿por qué sigue lleno?”.
Entregar backlog: vacía la cola y confirma que el correo entrante nuevo funciona.

Caso C: El buzón del destinatario remoto está lleno (no es tu servidor)

Tu trabajo es proteger tu infraestructura y ser un buen ciudadano SMTP.

Confirmar DSN remoto: si ves 552 5.2.2 del MX remoto, acepta la realidad. No puedes ssh al buzón de ellos.
Evitar reintentos infinitos: configura tiempos de vida de cola sensatos. No retengas correo semanas a menos que la política lo requiera y el almacenamiento esté dimensionado para ello.
Comunicar: notifica al remitente que el destinatario está sobre cuota. Ofrece alternativas: dirección alternativa, reenviar más tarde, usar un método de transferencia de ficheros.
Si es un partner recurrente: considera limitar reintentos o implementar una cola/transport separado para ese dominio para que un socio no llene tus discos.

Prevención seria: cuotas, monitorización, retención y diseño de almacenamiento

La prevención es donde decides si “buzón lleno” es una molestia rara o un simulacro trimestral.
Las mejores configuraciones hacen difícil fallar y fácil recuperarse.

Elige el modelo de cuotas intencionalmente (y documéntalo)

Tienes tres modelos comunes:

Cuotas en la aplicación (Dovecot, Exchange): flexibles por usuario/grupo, visibles para clientes, buena experiencia cuando QUOTA está habilitado.
Cuotas en el sistema de ficheros (XFS/ext4 project/user quotas): fuerte aplicación, funciona incluso si la app de correo se porta mal, pero mapear usuarios a UIDs/proyectos debe ser disciplinado.
Cuotas por dataset (datasets ZFS, volúmenes LVM por tenant): excelentes para aislamiento multi-dominio; aun así, combínalas con cuotas por usuario para equidad.

Opinión: usa cuotas a nivel de aplicación para usuarios y límites por dataset/volumen para controlar radio de blast. Confiar en una sola capa es cómo te llevas sorpresas.

Exponer el estado de cuotas a los usuarios (o ellos te lo expondrán a ti)

Si los clientes pueden mostrar “estás al 95%”, los usuarios se autocorrigen. Si no pueden, llenan el buzón hasta que tu MTA empieza a rebotar correo como si fuera 1999.

Habilita el reporte IMAP QUOTA donde esté soportado y asegúrate de que tu webmail lo muestre claramente. Esto no es mimar; es descarte de carga.

Políticas de retención: la palanca aburrida que funciona

Los buzones se llenan porque las organizaciones no deciden para qué sirve el correo. ¿Es canal de comunicación o sistema de registro?
Si es sistema de registro, construye un archivo con búsqueda y retención legal. Si es comunicación, la retención debe ser finita.

Consejo práctico: aplica retención corta en Trash, Junk y en adjuntos grandes primero. Nadie te demanda por borrar spam.

Ingeniería de almacenamiento: dimensiona para la realidad, no para la esperanza

El almacenamiento de correo crece como el moho: despacio, luego de golpe, y luego está en sitios que no sabías que existían.
Diseña el almacenamiento teniendo en cuenta:

Capacidad (obvio) y inodos (menos obvio, más doloroso).
Patrones IOPS: muchos ficheros pequeños, peso en metadata; picos de latencia salen como tickets “IMAP lento”, no como alertas de almacenamiento.
Snapshots/backups: tu “correo borrado” puede seguir en snapshots. Genial para recuperación, confuso para planificación de capacidad.
Separación de responsabilidades: mantén spool/cola/logs fuera del root si puedes; llenar root es un incidente multi-servicio.

Monitorización que realmente previene incidentes

Alertar en “disco 95%” es el comienzo, no el final. Para prevenir buzones llenos, vigila:

Espacio en sistema de ficheros y inodos para store de correo, spool y logs.
Tamaño de la cola de Postfix y distribución de antigüedad de la cola (correo diferido viejo es síntoma).
Distribución de margen de cuota (cuántos usuarios están >90%).
Tasa de crecimiento de buzones principales (cuenta comprometida enviando/recibiendo floods, o un flujo de trabajo que vuelca adjuntos).
Tasas de códigos de error (picos en 552/452, fallos LMTP, EDQUOT/ENOSPC en logs).

Broma #2: Si tu monitorización solo te dice “disco lleno”, felicitaciones—has construido un libro de historia muy ruidoso.

Tres mini-historias corporativas desde el frente

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

Una compañía mediana migró de un servidor de correo antiguo a una arquitectura “adecuada” dividida: MX corriendo Postfix, nodos IMAP con Dovecot,
y un NAS separado para /var/vmail. Hicieron la migración con cuidado, probaron logins, pruebas de envío y recepción. Todo en verde.

Dos semanas después, empezaron a rebotar facturas. No todas—solo algunos buzones de alto volumen: finanzas, operaciones de ventas, y una asistente ejecutiva que vivía en el correo.
Los rebotes decían “Quota exceeded”. Todos asumieron que el volumen de almacenamiento estaba lleno, porque eso es lo que “buzón lleno” suena. El storage estaba al 40%.

El culpable real fue una regla de cuota por defecto heredada de una plantilla en Dovecot: 5GB por usuario. En el servidor antiguo, las cuotas eran efectivamente ilimitadas,
aplicadas solo por tamaño de disco. En el nuevo, las cuotas eran reales. Los usuarios habían acumulado correo durante una década, y la nueva política fue como una trampilla.

La recuperación fue directa: subir cuotas temporalmente para los buzones afectados, habilitar visibilidad de cuotas en webmail,
y desplegar retención para Junk/Trash más un flujo de archivado básico para finanzas. La lección dolió más que el incidente:
las cuotas son comportamiento de producto, no solo un ajuste de almacenamiento. Si las cambias, cambias el servicio.

Mini-historia 2: La “optimización” que salió mal

Otra organización decidió “optimizar almacenamiento” activando compresión agresiva y deduplicación en el volumen de correo.
La idea no era mala: los adjuntos se repiten, el correo es principalmente texto, y a los CFOs les encantan las gráficas de capacidad bajando.

Al principio pareció una victoria. Luego llegó el lunes con el coro familiar: búsquedas IMAP lentas, correo nuevo tardío,
y la cola de correo creciendo lentamente. Las alertas saltaron por tamaño de cola, no por uso de disco. Así que el equipo miró la configuración de Postfix, porque allí estaba el dolor.

El problema fue metadata y latencia. Las cargas de trabajo Maildir hacen muchas lecturas/escrituras pequeñas y operaciones de directorio. La capa de almacenamiento “optimizada” encareció
esas operaciones, especialmente durante compactación. Los usuarios no vieron “latencia de storage”; vieron “el correo está roto.”
Mientras tanto, los diferimientos temporales mantenían mensajes más tiempo en cola, lo que incrementó el churn de disco y empeoró la compactación.

La solución no fue heroica: bajar las configuraciones más agresivas, programar mantenimiento pesado en fuera de horas, y establecer salvaguardas:
alarmas de edad máxima de cola, monitorización de latencia por volumen, y un disco de spool separado para que el crecimiento de cola no asfixiara todo el sistema.
La moraleja: si tu “optimización” cambia las colas de latencia, no es optimización—es un nuevo modo de fallo.

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

Una empresa regulada gestionaba su propio correo. No por gusto—por cumplimiento. Su stack de correo era poco glamuroso:
Postfix, Dovecot, Maildir, snapshots periódicos y una política de retención aplicada por reglas del servidor.

Una tarde, un buzón alcanzó cuota durante una ventana de descubrimiento legal. La asistente ejecutiva entró en pánico, porque el correo nuevo rebotaba y el ejecutivo viajaba.
Pero el equipo tenía dos hábitos aburridos: las cuotas eran visibles en webmail y un informe diario listaba buzones por encima del 85% con sus carpetas principales.

En vez de adivinar, abrieron el informe, encontraron la carpeta culpable (.Sent) y aplicaron una acción preaprobada:
mover correo más antiguo que un umbral al buzón de archivo (aún searchable, aún conforme), luego recalcular cuotas.
Las entregas se reanudaron, la cola se vació y nadie tocó el sistema de ficheros.

No pasó nada “emocionante”, que es el mayor cumplido que puedes dar a una práctica operativa.
Lo aburrido salvó el día porque fue repetible, autorizado y medible.

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

1) Síntoma: Los rebotes dicen “buzón lleno”, pero el disco tiene espacio

Causa raíz: Cuota a nivel de aplicación (Dovecot/Exchange) alcanzada; el disco no es el limitador.
Solución: Revisa estado de cuotas, tamaños de carpetas y reglas de cuota. Limpieza o aumento temporal, luego recalcula cuotas/índices.

2) Síntoma: Uso de disco parece bien, pero todo falla con “No space left on device”

Causa raíz: Agotamiento de inodos o un montaje distinto (root, spool, logs) está lleno.
Solución: df -ih y revisa todos los mounts relevantes. Libera inodos (purga spam/cuarentena, aplica retención). Mueve spool/logs fuera de root.

3) Síntoma: El usuario borra correo y sigue sobre cuota

Causa raíz: Correo borrado no expunged, contabilidad de cuota obsoleta, o movido a otra carpeta que sigue contabilizando.
Solución: Recalcula cuota; revisa conteos de borrados; ajusta ajustes de expunge; asegura que el cliente realmente expunge (especialmente en IMAP).

4) Síntoma: La cola crece rápidamente, entregas siguen reintentando

Causa raíz: Diferimientos transitorios (4xx) desde el backend de entrega, a menudo por latencia de almacenamiento, IMAP sobrecargado o timeouts de daemons de políticas.
Solución: Identifica destinatarios/dominios dominantes; arregla capacidad del backend; aplica throttling; evita reintentos indefinidos; aisla tráfico problemático.

5) Síntoma: Solo fallan los adjuntos grandes; los correos pequeños se entregan

Causa raíz: Límite de tamaño en SMTP o en el store del buzón; a veces mal reportado como “lleno”.
Solución: Confirma límites de tamaño en MTA y agente de entrega; comunica alternativas; no subas límites sin considerar riesgo de almacenamiento y abuso.

6) Síntoma: Tras liberar espacio, Dovecot sigue rechazando con errores de cuota

Causa raíz: El plugin de cuota usa índices cacheados; hay discrepancia entre estado del sistema de ficheros y la base de cuotas.
Solución: Recalcula cuota; si es necesario, repara índices con cuidado y en tráfico bajo. Valida permisos y propiedad también.

7) Síntoma: Solo un dominio o tenant está “lleno”, los demás bien

Causa raíz: Cuota de dataset/proyecto a nivel de dominio; aislamiento multi-tenant actuando.
Solución: Revisa límites y uso del dataset, no solo cuotas de usuario. Aumenta asignación de dominio o aplica retención/archivado por tenant.

Listas de verificación / plan paso a paso

Checklist A: Cuando suena la alerta (15 minutos para estabilidad)

Confirma si los fallos son locales o remotos (logs, códigos de error y relays).
Revisa df -h y df -ih en root, spool y store de correo.
Revisa tamaño de cola y crecimiento (mailq ahora, y otra vez en 5 minutos).
Encuentra principales destinatarios en cola; decide si aislarlos.
Si disco/inodos son críticos: libera espacio seguro primero (logs/temp), no borrar el store de correo.
Si es cuota: obtén estado de cuota; identifica carpetas principales; aplica limpieza aprobada por política o aumento temporal.
Recalcula cuotas/índices.
Vacía la cola y monitoriza tasa de errores; confirma que nuevas entregas entran.

Checklist B: Recuperación limpia sin pérdida de datos

Antes de borrar nada: confirma qué cuenta para la cuota (Sent/Archive/Junk/Trash).
Prefiere mover a archivo sobre borrar cuando importe el cumplimiento.
Documenta cambios: ajustes de cuota, acciones de retención, cualquier modificación manual del buzón.
Valida acceso de usuario tras la remediación (login IMAP, lista de carpetas, llegada de correo nuevo).
Confirma que los rebotes paran y la cola diferida se vacía.
Relleno posterior: si mensajes se rebotaron permanentemente, coordina estrategia de reenvío.

Checklist C: Trabajo de prevención que paga cada mes

Define cuotas por rol (ejecutivos, buzones compartidos, cuentas de servicio) y publica la política.
Habilita visibilidad de cuotas en clientes/webmail.
Establece retención para Junk/Trash; define estrategia para adjuntos.
Monitorea disco, inodos y distribución de edad de la cola.
Separa spool/logs del filesystem root.
Prueba recuperación trimestralmente: simula exceder cuota, confirma alertas y exactitud del runbook.

FAQ (las preguntas que hacen justo después de arreglarlo)

1) ¿Por qué el remitente recibió un rebote en lugar de un retraso?

Porque la ruta de entrega devolvió un fallo permanente (5xx) como 552/5.2.2. Los fallos permanentes suelen generar rebotes.
Los fallos transitorios (4xx) causan reintentos y encolamiento.

2) ¿“Buzón lleno” debería ser 4xx o 5xx?

Si esperas que la condición se libere pronto (ventana temporal), 4xx puede ser razonable. La mayoría de condiciones de cuota se tratan como 5xx porque
el servidor está rechazando explícitamente almacenamiento. Ten cuidado: 4xx fomenta tormentas de reintentos y crecimiento de cola.

3) Los usuarios borraron correo pero la cuota no cambió. ¿Mienten?

No necesariamente. La eliminación IMAP a menudo marca mensajes como borrados hasta que se expunge. Además, la contabilidad de cuota puede estar obsoleta.
Recalcula cuota y verifica comportamiento de expunge en el servidor.

4) ¿Es seguro borrar ficheros directamente desde Maildir?

Puede ser seguro si sabes exactamente lo que haces, pero rara vez es la mejor primera opción. Prefiere herramientas del servidor (doveadm) o jobs de retención controlados.
La eliminación manual arriesga inconsistencias en índices y comportamientos extraños para el usuario.

5) ¿Por qué el uso de inodos es tan importante en servidores de correo?

Maildir almacena cada mensaje como un fichero separado. Cientos de miles de correos equivalen a cientos de miles de inodos.
Si te quedas sin inodos, el sistema no puede crear ficheros nuevos—aun cuando queden gigabytes libres.

6) ¿Puedo simplemente aumentar cuotas y listo?

Puedes, y a veces debes (temporalmente). Pero si lo haces como respuesta por defecto, conviertes un problema de usuario en un problema de crecimiento de almacenamiento.
Empareja aumentos de cuota con retención y archivado, o repetirás el incidente con números mayores.

7) ¿Cómo evito que un buzón llene la cola de Postfix?

Identifica destinatarios dominantes y considera retenciones temporales o transportes separados para objetivos problemáticos.
El objetivo es controlar el radio de blast: proteger el resto de tu pipeline de entrega mientras arreglas la restricción.

8) ¿Cuál es la forma más limpia de manejar adjuntos grandes?

No trates al correo como almacenamiento de objetos. Define límites sensatos de adjuntos y proporciona una vía aprobada de intercambio de ficheros.
Si el cumplimiento requiere retención, archiva adjuntos en un sistema diseñado para ello, con indexación y gestión de ciclo de vida.

9) ¿Por qué al liberar espacio no se arregló inmediatamente la entrega?

Porque el sistema de entrega puede usar estado cacheado de cuota/índices, o la cola de Postfix sigue reintentando lentamente.
Recalcula cuota, vacía la cola y observa logs para la razón actual del fallo.

10) ¿Cómo demostramos que no perdimos correo durante el incidente?

Compara estado de la cola antes/después, verifica rebotes generados, revisa logs por entregas exitosas y valida integridad de buzones.
Si tienes journaling o tracking de mensajes, úsalo para confirmar recepción de extremo a extremo.

Conclusión: pasos prácticos siguientes

Los incidentes por buzón lleno no son glamorosos, pero son previsibles. Eso es buena noticia: los fallos previsibles son los que puedes diseñar para evitar.

Elige una estrategia de cuotas (cuotas de app + límites por dataset es una combinación sólida) y documéntala como parte del producto.
Instrumenta las señales correctas: disco, inodos, edad de cola, distribución de margen de cuota y códigos de error de entrega.
Construye un hábito de recuperación seguro: libera espacio seguro primero, arregla el limitador real, recalcula cuotas/índices, luego vacía colas y verifica.
Haz real la retención y el archivado: especialmente para Junk/Trash y adjuntos. Aquí vive la mayor parte del “crecimiento misterioso”.

Si no haces otra cosa, implementa la guía de diagnóstico rápido y las listas de verificación anteriores. La próxima vez que aparezca “buzón lleno”, lo arreglarás en minutos—
y no tendrás que explicarle a finanzas por qué el servidor de correo se comió a sí mismo.