Límites de tamaño de mensajes de correo: aumentarlos de forma segura sin ser explotados

Qué limita realmente el tamaño del correo (y por qué “simplemente aumentarlo” falla)

El tamaño del mensaje de correo no es un único control. Es una cadena de limitaciones: cliente → servidor de envío → gateway entrante → filtros de contenido → almacén de buzones → gateway saliente → MX remoto.
Si cualquier eslabón rechaza, el remitente recibe un NDR, un rebote o (peor) un aplazamiento silencioso que se convierte en una cola atascada. El truco es identificar qué eslabón es la limitación real y entonces aumentarlo solo hasta donde tu sistema y tu modelo de riesgo lo permitan.

El tamaño que ves no es el tamaño que se envía

Los adjuntos suelen codificarse en base64, lo que añade aproximadamente un 33% de sobrecarga. Luego está la estructura MIME, los encabezados y a veces la recodificación por gateways.
Un “límite de adjunto de 25 MB” a menudo se traduce en algo como un límite de tamaño de mensaje de 33–36 MB en el MTA. Si no lo tienes en cuenta, “lo subes a 30 MB” y sigues bloqueando PDFs de 23 MB que se convierten en 31 MB en la red.

Dónde se esconden los límites

• MUA (cliente): Outlook, clientes móviles y webmail pueden imponer límites en la interfaz o políticas proporcionadas por el servidor.
• Submission (MSA): el endpoint SMTP autenticado puede tener límites más estrictos que el MX entrante.
• MTA: reglas de transporte de Postfix/Exim/Sendmail/Exchange, además de límites por conector.
• Proxies SMTP: balanceadores de carga, terminadores TLS, proxies de correo (y middleboxes “útiles”) pueden limitar el tamaño del cuerpo de la petición o los timeouts.
• Filtrado: antivirus, DLP, sandboxing y filtros antispam pueden rechazar cargas grandes o agotar tiempo en su análisis.
• Almacenamiento de buzones: cuotas por buzón, límites por mensaje y restricciones de base de datos.
• Lado remoto: tu límite de salida no importa si el destino rechaza todo lo superior a 10–25 MB.

Una frase útil para las revisiones de cambios: La esperanza no es una estrategia. — Gene Kranz.

Aquí está la realidad incómoda: aumentar tu límite no garantiza la entrega. Solo garantiza que aceptarás más datos, los retendrás más tiempo y gastarás más CPU y disco antes de saber que el sitio remoto no los aceptará.
Por eso “seguro” trata de controles, observabilidad y vías alternativas, no solo de números mayores.

Datos y contexto histórico que puedes usar en reuniones

Estos son los puntos pequeños y concretos que te ayudan a explicar por qué no puedes convertir el correo en Dropbox.

1. Los adjuntos MIME no formaban parte del diseño original del correo. El correo temprano era mayormente texto plano; MIME llegó después para estandarizar adjuntos y contenido enriquecido.
2. La codificación base64 infla los datos. Los archivos binarios se codifican en texto seguro ASCII para transporte, costando alrededor de un tercio en sobrecarga en casos comunes.
3. “SIZE” es una extensión SMTP, no una garantía. Muchos MTAs anuncian el tamaño máximo en los saludos SMTP, pero los intermedios aún pueden rechazar más tarde.
4. 25 MB se volvió un valor social, no un estándar. Muchos proveedores convergieron alrededor de 10–25 MB porque equilibra usabilidad y riesgo de abuso; es conveniencia operativa con etiqueta.
5. Los mensajes grandes son un riesgo de disponibilidad. Un mensaje gigante puede ocupar el escaneo, crear sesiones SMTP largas e incrementar la latencia de la cola; no es solo “más almacenamiento”.
6. Los almacenes de correo históricamente se optimizaron para muchos ítems pequeños. Muchos mensajes pequeños son la carga normal; los adjuntos gigantes crean patrones de E/S diferentes, comportamiento de compactación y costes de índice.
7. Algunos filtros descomprimen adjuntos. Un zip “pequeño” puede inflarse durante el escaneo; los límites pueden aplicarse al tamaño expandido, no solo a la carga SMTP cruda.
8. Los timeouts importan más a medida que aumenta el tamaño. Un mensaje de 40 MB en una subida cliente lenta puede mantener una transacción SMTP abierta el tiempo suficiente para alcanzar límites por conexión o timeouts de un reverse proxy.

Broma #1: El correo es el único protocolo de transferencia de archivos que te pide perdón mientras falla.

Marco de decisión: ¿deberías aumentar los límites?

Aumentar límites a veces es lo correcto. A veces es la trampa del servicio al cliente. Decide como operador, no como alguien intentando cerrar un ticket.

Cuándo tiene sentido aumentar límites

• Flujos críticos de negocio dependen del correo. Las partes externas no usarán tu portal y no puedes imponer otro canal.
• Tienes controles entrantes fuertes. Filtrado antispam y antimalware moderno, escaneo y limitación de tasa están implementados y monitorizados.
• Tu almacenamiento y sistemas de cola están dimensionados para el peor escenario. “Día normal” no cuenta; necesitas “envío masivo de marketing + incidente + fallos remotos”.
• Puedes tolerar la no entrega para algunos destinatarios. Seguirás alcanzando límites remotos; los usuarios deben aceptar rutas alternativas (enlaces, unidades compartidas, transferencia segura de archivos).

Cuándo aumentar límites es una trampa

• Estás intentando compensar un sistema de compartición de archivos roto. Arregla el intercambio de archivos. El correo no es tu plan de respaldo para herramientas de colaboración.
• No controlas tu reputación saliente. Mensajes más grandes pueden incrementar reintentos, tiempo en cola y comportamiento de puntuación de spam; la entregabilidad puede volverse rara.
• Tu pila de filtrado ya funciona al límite. Si tu sandbox AV está cerca de saturación, cargas más grandes convierten “casi saturado” en “caído”.

Define dos límites, no uno

Los operadores que sobreviven definen límites separados para:

• Entrantes desde Internet (más estrictos; mayor riesgo de abuso).
• Envío autenticado/submission (ligeramente más alto; aún controlado por límites de tasa y políticas de usuario).

Luego crean excepciones para remitentes/receptores o dominios específicos, no una fiesta global de “todos ahora tienen 100 MB”.

Guía rápida de diagnóstico (primer / segundo / tercer chequeo)

Si estás de guardia y alguien grita “los correos grandes fallan”, no te metas en los configs primero. Localiza el cuello de botella.
La jugada ganadora es encontrar el primer componente que conoce la verdad: el componente que devuelve el código SMTP.

Primero: identifica dónde falla (y obtén el código SMTP)

• Pide el texto del rebote / NDR o los encabezados del mensaje. Buscas códigos como 552, 554, 451 más cadenas “message too big”.
• Revisa los logs del MTA para la transacción: ¿rechazaste en el tiempo SMTP DATA, o aceptaste y luego rebotaste?
• Si el remitente es interno, reproduce con swaks o una prueba controlada desde un host conocido.

Segundo: decide si es un límite anunciado, un proxy o un timeout de filtro

• 552 inmediato en DATA: un máximo configurado en el MTA/proxy receptor.
• Aceptado y luego rebota: rechazo por filtro/almacenamiento o resultado del escaneo de contenido.
• Larga espera y luego timeout: timeout de proxy inactivo, acumulación en el escáner de contenido o disco lento.

Tercero: revisa salud de la cola y presión de disco

• Busca crecimiento de colas, mensajes aplazados y tormentas de reintentos.
• Confirma espacio en disco y disponibilidad de inodos; los mensajes grandes pueden crear muchos archivos temporales.
• Revisa iowait; el procesamiento de mensajes grandes suele ser un problema de rendimiento/latencia de disco.

Si no puedes responder “¿dónde falla?” en cinco minutos, no tienes un problema de tamaño de correo; tienes un problema de observabilidad.

Tareas prácticas con comandos, salidas y decisiones (12+)

El objetivo de estas tareas no es memorizar comandos. Es construir una forma repetible de demostrar dónde vive el límite, si tu sistema puede manejar el nuevo tamaño y si los controles anti-abuso siguen funcionando.

Task 1: Confirmar el tamaño máximo de mensaje en Postfix

cr0x@server:~$ postconf message_size_limit
message_size_limit = 10485760

Qué significa la salida: Postfix rechazará mensajes mayores que 10,485,760 bytes (~10 MB) en SMTP DATA.

Decisión: Si vas a subir a “adjuntos de 25 MB”, considera fijar message_size_limit en ~35–40 MB para tener en cuenta la sobrecarga base64/MIME, y valida primero los límites downstream.

Task 2: Comprobar tamaño de buzón y límites de mensaje en Dovecot (común para backends IMAP)

cr0x@server:~$ doveconf -n | egrep 'mail_max_size|quota'
mail_max_size = 0
plugin {
  quota = maildir:User quota
}

Qué significa la salida: mail_max_size = 0 suele significar “sin límite por mensaje impuesto por Dovecot”, pero las cuotas aún aplican vía el plugin de cuota.

Decisión: Si mail_max_size no es cero y está por debajo de tu nuevo objetivo, debes aumentarlo o aceptarás por SMTP y fallarás al entregar al buzón.

Task 3: Identificar el tamaño efectivo anunciado vía SMTP (extensión SIZE)

cr0x@server:~$ swaks --server mx1.example.net --ehlo test.example --quit-after EHLO
=== Trying mx1.example.net:25...
=== Connected to mx1.example.net.
<  220 mx1.example.net ESMTP Postfix
 > EHLO test.example
<  250-mx1.example.net
<  250-SIZE 10485760
<  250-PIPELINING
<  250-STARTTLS
<  250 HELP
=== Connection closed with remote host.

Qué significa la salida: El servidor anuncia un límite de 10 MB vía la extensión SMTP.

Decisión: Si aumentas message_size_limit pero sigues anunciando el tamaño antiguo, los clientes pueden negarse a enviar. Asegura que el SIZE anunciado coincida con tu límite real de recepción.

Task 4: Verificar que Nginx (u otro proxy) no esté limitando rutas SMTP/HTTP de carga

cr0x@server:~$ nginx -T 2>/dev/null | egrep 'client_max_body_size|proxy_read_timeout|proxy_send_timeout'
client_max_body_size 10m;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

Qué significa la salida: Si este Nginx sirve webmail o una API de envío, limita las peticiones a 10 MB y tiene timeouts cortos.

Decisión: Aumenta el tamaño de cuerpo y los timeouts si mensajes grandes atraviesan este proxy, o acepta que los usuarios de webmail seguirán fallando aunque SMTP funcione.

Task 5: Comprobar profundidad de cola de Postfix y mensajes diferidos

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9D2F21C03A*    84231 Mon Jan  4 10:12:41  alerts@example.net
                                         user@example.com
                                         (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
-- 1 Kbytes in 1 Request.

Qué significa la salida: Tienes al menos una entrega diferida por timeouts de conexión remota; la cola no es enorme aquí, pero necesitas la vista completa.

Decisión: Si la cola crece tras aumentar el tamaño, puede que estés aceptando mensajes grandes que no pueden entregarse. Añade política: rechazar temprano para destinos con límites conocidos o proporcionar orientación al usuario.

Task 6: Resumir la cola de Postfix por estado (activo vs diferido)

cr0x@server:~$ postqueue -p | egrep -c '^[A-F0-9]'
42

Qué significa la salida: Hay 42 entradas en cola (recuento aproximado basado en líneas de ID de cola).

Decisión: Si ese número se dispara durante eventos de envíos grandes, necesitas limitación, mejor enrutamiento de entrega o límites salientes más bajos para Internet.

Task 7: Vigilar evidencias en logs de rechazos por tamaño

cr0x@server:~$ sudo journalctl -u postfix --since "30 min ago" | egrep 'message size|too large|552' | tail -n 5
Jan 04 10:14:22 mx1 postfix/smtpd[23144]: NOQUEUE: reject: RCPT from mail.remote.tld[203.0.113.55]: 552 5.3.4 Message size exceeds fixed maximum message size; from=<sender@remote.tld> to=<user@example.com> proto=ESMTP helo=<mail.remote.tld>

Qué significa la salida: El rechazo ocurre en tu demonio SMTP. Es un límite configurado localmente, no un problema del almacenamiento downstream.

Decisión: Aumenta el límite de recepción relevante (y confirma que no falta una configuración más estricta por servicio como submission vs inbound).

Task 8: Confirmar espacio en disco y disponibilidad de inodos (el correo grande estresa ambos)

cr0x@server:~$ df -h /var/spool/postfix /var/mail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       200G  176G   15G  93% /
/dev/sdb1       500G  120G  355G  26% /var/mail

Qué significa la salida: El spool vive en / y está al 93% de uso. Es un fallo de cola esperando ocurrir.

Decisión: Mueve el spool a un sistema de archivos dedicado o amplía la capacidad antes de aumentar límites; los mensajes grandes incrementan significativamente el uso transitorio del spool.

Task 9: Comprobar presión de IO durante la ingestión de mensajes

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (mx1) 	01/04/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.21    0.00    4.12   32.55    0.00   53.12

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
sda              3.00     64.00     0.00   0.00    2.10    21.33  220.00  18432.00    12.00   5.17   45.30    83.78   9.96  98.00

Qué significa la salida: Alto %iowait y utilización cercana al 100% indican que el servidor está limitado por IO. El procesamiento de mensajes grandes amplificará esto.

Decisión: Antes de incrementar límites, arregla IO (almacenamiento más rápido, spool separado, ajustar concurrencia de escaneo). Si no, convertirás un servidor “a veces lento” en uno “casi siempre caído”.

Task 10: Confirmar restricciones de destinatarios en Postfix y separación de autenticación (base anti-abuso)

cr0x@server:~$ postconf -n | egrep 'smtpd_recipient_restrictions|smtpd_client_restrictions|smtpd_tls_security_level|smtpd_sasl_auth_enable'
smtpd_client_restrictions = permit_mynetworks, reject_unknown_client_hostname
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_tls_security_level = may
smtpd_sasl_auth_enable = yes

Qué significa la salida: El relay está restringido (bien), y usuarios autenticados están permitidos. TLS es oportunista (may), lo que puede ser aceptable según la política.

Decisión: Si aumentas tamaños para envío autenticado, mantén límites entrantes anónimos más estrictos. Y asegúrate de no permitir accidentalmente relay abierto en ninguna parte.

Task 11: Detectar huecos en limitación de tasa (conexión y concurrencia de mensajes)

cr0x@server:~$ postconf -n | egrep 'smtpd_client_connection_count_limit|smtpd_client_message_rate_limit|smtpd_client_recipient_rate_limit'
smtpd_client_connection_count_limit = 50
smtpd_client_message_rate_limit = 0
smtpd_client_recipient_rate_limit = 0

Qué significa la salida: El conteo de conexiones está limitado, pero los límites de tasa por mensaje y destinatario están desactivados (0). Si aumentas los tamaños, el abuso puede volverse costoso rápido.

Decisión: Implementa límites de tasa para el inbound anónimo y considera políticas separadas por listener (MX entrante vs submission). Los mensajes más grandes aumentan el coste por mensaje; trátalos como recurso escaso.

Task 12: Medir los mensajes más grandes que ya procesas (chequeo de realidad)

cr0x@server:~$ sudo find /var/spool/postfix/deferred -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -n 5
38912044 /var/spool/postfix/deferred/9/9D2F21C03A
22100412 /var/spool/postfix/deferred/1/1A7B0D11F2
18000210 /var/spool/postfix/deferred/C/C2D11E9AA0
15011401 /var/spool/postfix/deferred/4/45B2A9B1C3
12000877 /var/spool/postfix/deferred/7/7CC9F1022B

Qué significa la salida: Ya tienes ítems de ~39 MB en diferidos. O bien tu límite de ingreso es más alto de lo que crees, o estos crecieron después por manejo interno.

Decisión: No aumentes límites a ciegas. Primero, entiende por qué existen ítems grandes: aceptados antes de un cambio de config, inyectados localmente o provenientes de un listener con caps diferentes.

Task 13: Validar la entrega de extremo a extremo a un proveedor externo conocido (la verdad incómoda)

cr0x@server:~$ swaks --server submission.example.net --port 587 --auth LOGIN --auth-user user@example.com --auth-password 'REDACTED' --tls --to external-test@remote.tld --from user@example.com --attach /tmp/25mb.bin
=== Trying submission.example.net:587...
=== Connected to submission.example.net.
<  220 submission.example.net ESMTP Postfix
 > EHLO mx1.example.net
<  250-submission.example.net
<  250-SIZE 41943040
<  250-STARTTLS
<  250-AUTH PLAIN LOGIN
<  250 HELP
...
<  250 2.0.0 Ok: queued as 3F1A2B9C0D

Qué significa la salida: Submission anuncia ~40 MB y el mensaje fue aceptado y encolado. Esto es solo la mitad de la historia.

Decisión: Rastrea el ID de cola a través de los logs de entrega saliente. Si luego se difiere o rebota por límites remotos, necesitas orientación visible al usuario y posiblemente límites salientes más bajos para destinos en internet.

Task 14: Rastrear ese ID de cola hasta entrega o rebote

cr0x@server:~$ sudo journalctl -u postfix --since "10 min ago" | egrep '3F1A2B9C0D' | tail -n 8
Jan 04 10:20:18 mx1 postfix/qmgr[1022]: 3F1A2B9C0D: from=<user@example.com>, size=35781234, nrcpt=1 (queue active)
Jan 04 10:20:49 mx1 postfix/smtp[24110]: 3F1A2B9C0D: to=<external-test@remote.tld>, relay=mx.remote.tld[203.0.113.10]:25, delay=31, delays=0.2/0.1/10/21, dsn=5.2.3, status=bounced (host mx.remote.tld[203.0.113.10] said: 552 5.2.3 Message size exceeds fixed maximum message size (in reply to end of DATA command))

Qué significa la salida: Tu sistema aceptó e intentó entregar un mensaje de ~35.8 MB, pero el remoto lo rechazó con 552 al final de DATA.

Decisión: Ningún aumento local de límites arregla políticas remotas. Proporciona alternativas: enlaces de compartición, transferencia segura o enrutamiento por dominio específico (si tienes socios confiables con caps más altos).

Task 15: Confirmar rendimiento y acumulación del filtro de contenido (ejemplo con grep de logs tipo Amavis)

cr0x@server:~$ sudo journalctl --since "30 min ago" | egrep 'amavis|clamd|timeout|too large' | tail -n 8
Jan 04 10:18:03 mx1 amavis[1888]: TIMING [abc123]: smb=0.012 (0.012+0.000) out=0.004 (0.004+0.000) m=1.234 (1.221+0.013)
Jan 04 10:18:04 mx1 amavis[1888]: (1888-12) WARN: timed out while scanning, quarantined
Jan 04 10:18:05 mx1 postfix/smtp[24002]: warning: conversation with content-filter.example.net[192.0.2.25] timed out while sending message body

Qué significa la salida: El escaneo agotó tiempo y Postfix agotó tiempo al enviar el mensaje al filtro de contenido. Los mensajes más grandes desencadenarán más de esto.

Decisión: Ajusta timeouts y concurrencia del filtro, escala la capa de filtros o mantén límites conservadores. Tu cuello de botella es el escaneo, no SMTP.

Task 16: Verificar TLS y timeouts de sesión que importan más para cargas grandes

cr0x@server:~$ postconf -n | egrep 'smtp_data_xfer_timeout|smtpd_timeout|smtpd_data_restrictions'
smtp_data_xfer_timeout = 180s
smtpd_timeout = 60s
smtpd_data_restrictions = reject_unauth_pipelining

Qué significa la salida: El timeout de transferencia de datos para salida es 180s; el timeout de sesión entrante es 60s. Subidas grandes desde clientes lentos pueden cortarse.

Decisión: Aumenta timeouts con cuidado en submission (usuarios autenticados) si es necesario, pero mantén el MX entrante más estricto para reducir exposición al abuso y al acaparamiento de recursos.

Controles anti-abuso al aumentar los límites

Cuando aumentas los límites de tamaño, estás incrementando el coste de cada mensaje aceptado: disco, CPU, tiempo de escaneo y ancho de banda de reintentos.
A los atacantes les encantan las operaciones costosas. Les estás ofreciendo un juguete más caro.

Separa zonas de confianza: MX entrante vs submission autenticado

No apliques la misma política a remitentes anónimos de Internet y a empleados autenticados. No son el mismo modelo de amenaza.
Una configuración limpia:

• MX entrante: límite de tamaño más bajo, timeouts estrictos, limitación agresiva de tasa, rechazar temprano.
• Submission (587/465): límite mayor, throttles por usuario, autenticación fuerte, monitoreo ligado a identidad.

Limitación de tasa que realmente importa

Para mensajes grandes, la limitación de tasa no es solo “mensajes por minuto”. Es también:

• Conexiones concurrentes por IP cliente (evita enjambres de subida).
• Entregas concurrentes por dominio (evita tormentas de reintentos a un remoto caído).
• Bytes por unidad de tiempo (muchos MTAs no hacen esto directamente; lo aproximas con límites de sesión y tasa por mensaje).

Rechazos tempranos: lo barato es hermoso

El mejor rechazo es el que haces antes de leer 80 MB en disco y pasarlo por tres escáneres.
Si sabes que un dominio socio solo acepta 10–15 MB, no aceptes 40 MB dirigido allí y luego rebotes. Eso es operativamente descortés.
Usa transport maps o servicios de política para aplicar límites por destino si tu MTA lo soporta.

Controles basados en identidad para salida

Una vez que permites mensajes salientes más grandes, el compromiso de cuentas se vuelve más costoso. Añade:

• Límites diarios por usuario (mensajes y destinatarios).
• Controles por tipo de adjunto (bloquear ejecutables, archivos comprimidos riesgosos).
• Alertas sobre patrones inusuales de envío grande: “Un usuario que nunca envía adjuntos acaba de enviar 60 mensajes de 30 MB cada uno”.

Broma #2: La forma más rápida de aprender que tu límite es demasiado alto es ver a un spammer tratar tu servidor SMTP como una CDN gratuita.

Almacenamiento y rendimiento: el correo grande es un problema de disco con corbata

La mayoría de los incidentes de “aumentamos el límite y el correo se volvió inestable” no son fallos SMTP. Son problemas de recursos:
disco lleno, picos de latencia de IO, timeouts de escáneres, colas hinchadas y luego reintentos que crean más carga. Un clásico bucle de realimentación positiva, solo que con menos gráficos y más ejecutivos enfadados.

Spool vs almacen de correo: sepáralos

La cola/spool de Postfix es un conjunto de trabajo transitorio. Necesita:

• latencia predecible (bajos tiempos de espera),
• espacio disponible (headroom para picos),
• comportamiento fsync rápido (journaling ajustado sensatamente),
• y aislamiento de compactaciones de mailstore y backups.

Si tu spool comparte un sistema de archivos con logs del SO, imágenes de contenedores o “exportaciones temporales de analítica”, estás ejecutando tu servidor de correo sobre sensaciones.
Pon el spool en almacenamiento dedicado, dimensionado para colas diferidas en el peor caso.

Los mensajes grandes cambian el patrón de E/S

El correo pequeño es rico en metadatos: muchos archivos pequeños, búsquedas de directorio, índices. El correo grande añade escrituras y lecturas de alto rendimiento.
Tu sistema ahora necesita ambos: buen rendimiento en metadatos y alto rendimiento en transferencia. En discos giratorios, aquí es donde los sueños mueren.

El escaneo de contenido es el impuesto oculto de CPU/disco

Antivirus y DLP pueden:

• descomprimir archivos (aumentando la carga),
• reensamblar partes MIME,
• ejecutar heurísticas que escalan con el tamaño,
• y mantener mensajes en almacenamiento temporal mientras escanean.

Si aumentas límites, debes tratar la capacidad de escaneo como una dependencia de primera clase. Si no, aceptarás correo y luego te quedarás atascado en tu propia cadena de filtros.

Los timeouts no son “solo red”

Los mensajes grandes aumentan el tiempo en cada fase: subida, traspaso al filtro, escaneo, encolado, entrega. Un timeout que era “seguro” a 10 MB puede ser incorrecto a 40 MB.
Pero no lo soluciones poniendo todos los timeouts enormes. Así permites que sesiones SMTP estilo slowloris acaparen sockets todo el día.
Timeouts estrictos en inbound anónimo, más laxos en submission autenticado—repite hasta que se convierta en política.

Tres microhistorias corporativas (lo que realmente ocurre)

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana operaba una pila de correo de aspecto limpio: gateways entrantes, Postfix, filtrado de contenido y almacenamiento de buzones. Llegaron tickets de soporte: “No podemos enviar archivos de 20–30 MB a clientes.”
El admin de correo subió message_size_limit en los gateways entrantes y lo dio por solucionado. Todos aplaudieron.

Dos días después, las colas salientes crecieron. No era espectacular al principio—solo una subida constante. Entonces llegó el lunes. Los usuarios enviaban adjuntos más grandes a socios, el gateway los aceptaba y la entrega saliente empezó a rebotar con errores 552 de múltiples dominios destinatarios.
Ahora la cola contenía un montón de mensajes grandes e inentregables. Cada reintento generó más ruido en logs, más churn de disco y más confusión.

La suposición equivocada fue simple: “Si aceptamos correo más grande, se entregará.” Internet no firma tu documento de política interna.
Muchos dominios destinatarios aplican límites de 10–25 MB y no negocian. Tu MTA lo descubrirá solo después de leer todo el payload DATA y intentar la entrega.

La solución no fue “subir más límites”. Fue aplicar políticas conscientes del destino y ofrecer una alternativa autorizada para transferencia de archivos.
Terminaron manteniendo límites más altos solo para un puñado de dominios socios confiables (con caps confirmados), mientras el límite general para Internet se mantuvo conservador.

La lección real: no subes un límite; cambias la forma del tráfico. Y la forma del tráfico cambia tus modos de fallo.

Microhistoria 2: La optimización que salió mal

Otra organización intentó ser ingeniosa. Tenían retrasos en el escaneo antivirus, así que “optimizaban” saltándose el escaneo profundo para mensajes por encima de cierto tamaño.
La lógica sonaba pragmática: “Los PDFs grandes de clientes suelen estar bien y escanearlos tarda una eternidad. Reduciremos latencia.”

Funcionó una semana. La latencia del correo bajó. La cola se veía más sana. Entonces sufrieron una campaña que usó adjuntos grandes como vector de entrega—lo suficientemente grandes para evadir su atajo y para ralentizar la revisión manual.
Tras algunos endpoints comprometidos, el equipo de seguridad se involucró, y de repente el equipo de correo revivió toda la reunión de aprobación de cambios, pero con más gente y menos chistes.

La optimización se basaba en una premisa falsa: que “tamaño correlaciona con seguridad”. Los atacantes pueden permitirse bytes. Tú no puedes permitirte confiar.
Los adjuntos grandes son mejores para ocultar cargas y agotar sistemas; no son “probablemente seguros”.

La solución eventual fue aburrida: escalar la capa de escaneo correctamente, mantener la política de escaneo consistente y añadir límites y timeouts sensatos para que un solo mensaje no monopolizara recursos.
También implementaron throttles por remitente para evitar que “una cuenta comprometida envíe 500 adjuntos gigantes” se convierta en un problema de infraestructura.

Microhistoria 3: La práctica correcta y aburrida que salvó el día

Una empresa regulada quiso aumentar el tamaño de mensajes para envíos autenticados porque un proveedor específico solo se comunicaba por correo y rutinariamente enviaba documentos anotados grandes.
El equipo de mensajería hizo algo profundamente poco trendy: lo pusieron en un entorno de pruebas que reproducía la ruta real del correo, incluidos filtros de contenido y cuotas de buzón.

Ejecutaron pruebas de carga: diez envíos concurrentes de 35 MB, luego veinte, luego una carga mixta con correo normal más mensajes grandes.
Vigilaron IO de disco, latencias de filtros, tamaños de cola y rendimiento de escritura en buzones. No asumieron. Midieron.

Durante las pruebas descubrieron un cuello de botella inesperado: un filesystem temporal usado por el escáner DLP tenía una cuota pequeña y opciones de montaje por defecto. Bajo carga de ráfaga se llenó y empezó a fallar escaneos.
En producción esto habría parecido aplazamientos aleatorios de entrega, que es el peor tipo de incidente: lo suficientemente intermitente como para dudarlo.

Arreglaron el dimensionamiento del almacenamiento temporal, separaron el spool y ajustaron throttles por usuario. Cuando al final aumentaron el límite, no pasó nada dramático.
El cambio funcionó, los usuarios recibieron correos más grandes y el equipo de guardia disfrutó del fin de semana.

La práctica que los salvó no fue una herramienta sofisticada. Fue probar de extremo a extremo con cuellos de botella realistas incluidos.

Listas de verificación / plan paso a paso

Plan paso a paso para aumentar límites de forma segura

1. Aclara el requisito de negocio en bytes, no en sensaciones. “Adjuntos de 25 MB” no es un valor técnico. Decide el tamaño objetivo del adjunto y calcula el tamaño en la red con sobrecarga (planifica ~1.35x por base64/MIME).
2. Mapea tu ruta real de correo. Dibuja la cadena: cliente → submission → gateways → filtros → mailstore → salida. Incluye proxies, DLP, archivado, journaling y backups.
3. Encuentra los límites actuales en cada capa. Ajustes de MTA, proxies, filtros, límites de buzón, cuotas, caps de conectores.
4. Elige límites separados por zona de confianza. Cap de MX entrante más bajo; submission autenticado puede ser más alto con controles por usuario.
5. Confirma comportamiento de escaneo y almacenamiento temporal. Conoce dónde se colocan los mensajes grandes durante el escaneo y qué se llena primero (espacio en disco, inodos, RAM, tempfs).
6. Dimensiona la cola (spool). Tamaño de cola en el peor caso: considera fallos remotos donde los mensajes se diferan por horas. Los mensajes grandes hacen que “horas” sea costoso.
7. Implementa limitación de tasa y controles de identidad antes de aumentar tamaño. No despliegues una superficie de ataque mayor sin guardarraíles.
8. Aumenta límites en pequeños incrementos. Ejemplo: 10 MB → 20 MB → 35–40 MB en la red. Observa después de cada paso.
9. Prueba de extremo a extremo con clientes reales y herramientas SMTP. Valida tanto submission como inbound. Valida entrega a dominios externos comunes.
10. Actualiza la guía para usuarios. Explica el “qué hacer cuando rebota”: compartir enlaces, comprimir, opciones de transferencia segura.
11. Añade paneles y alertas específicas para estrés por correos grandes. Cola, distribución de tamaños en cola, timeouts de filtros, IO wait, uso de filesystem temporal.
12. Revisión post-cambio. Busca cambios: aumento del tamaño medio de mensajes, churn en colas, más reintentos, mayor latencia de escaneo.

Checklist go/no-go para la ventana de cambio

• El filesystem del spool tiene al menos 30–40% de espacio libre y latencia de IO saludable bajo carga.
• La capa de filtros de contenido tiene capacidad sobrante; no hay timeouts en logs bajo carga de prueba.
• Los listeners de submission y entrada tienen políticas claramente distintas.
• Los límites de tasa están configurados y probados (incluyendo comportamiento ante falsos positivos).
• Existe monitorización para crecimiento de colas, cuentas diferidas y tendencias de uso de disco.
• Hay un plan de rollback escrito y rápido (revertir config + recargar).
• Comunicaciones a usuarios listas: “Algunos destinatarios externos aún pueden rechazar mensajes por encima de X MB; usa Y en su lugar.”

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

1) Síntoma: Los usuarios aún no pueden enviar adjuntos grandes después de subir Postfix

Causa raíz: El cliente o el servicio de submission aplica un límite menor que tu MX entrante, o un proxy limita el tamaño de la petición.

Solución: Revisa el listener de submission autenticado (587/465) por separado, confirma el SIZE anunciado vía swaks y verifica cualquier client_max_body_size de webmail/proxy o equivalente.

2) Síntoma: El correo se acepta pero rebota horas después

Causa raíz: Dominios remotos rechazan mensajes grandes (552) y tu servidor reintenta hasta rebotar; o el filtro/almacenamiento downstream rechaza tras la aceptación.

Solución: Rastrear IDs de cola. Si el remoto rechaza, aplica límites/guidance por destino. Si componentes internos rechazan, alinea los caps entre filtro y mailstore para rechazar pronto en SMTP.

3) Síntoma: La cola explota tras aumentar el límite

Causa raíz: Aceptas mensajes costosos que no pueden entregarse rápidamente; los reintentos se acumulan. A menudo disparado por fallos externos, rutas malas o throttling remoto.

Solución: Añade control de concurrencia saliente, limitación por dominio y caps conservadores para Internet. Considera tamaños máximos menores para rutas públicas y caps mayores para socios confiables.

4) Síntoma: Errores de “timeout” aleatorios en logs durante envíos grandes

Causa raíz: Timeouts de proxy inactivo, acumulación en el filtro de contenido o saturación de IO de disco causando procesamiento lento.

Solución: Aumenta timeouts solo en paths de submission, escala capacidad de filtros y arregla cuellos de botella de IO. No subas timeouts globalmente; invitarás a acaparamiento de recursos.

5) Síntoma: El disco se llena aunque el volumen medio de correo no cambió mucho

Causa raíz: Unos pocos mensajes grandes pueden consumir espacio de spool desproporcionadamente, especialmente cuando están diferidos o duplicados por pipelines de escaneo/journaling.

Solución: Dimensiona el spool para picos, separa spool y mailstore, monitoriza los ítems más grandes en cola y aplica política para rechazar o desviar correo sobredimensionado temprano.

6) Síntoma: Algunos usuarios pueden enviar correo grande, otros no

Causa raíz: Diferentes endpoints de submission con límites distintos (p. ej., gateways regionales), o diferencias de política por usuario/conector.

Solución: Inventaría todos los listeners y conectores; estandariza la política. Documenta excepciones explícitamente en lugar de descubrirlas por quejas de usuarios.

7) Síntoma: El equipo de seguridad reporta más detecciones de malware tras aumentar límites

Causa raíz: Los adjuntos más grandes amplían la superficie de amenaza; si el escaneo se saltó o los timeouts se aumentaron sin escalar, más contenido riesgoso pasa o queda en cuarentena de forma inconsistente.

Solución: Mantén el escaneo consistente, escala recursos de escaneo, ajusta timeouts con cuidado e implementa políticas por tipo de adjunto y sandboxing donde corresponda.

8) Síntoma: IMAP/webmail se siente lento tras el cambio

Causa raíz: Indexación del mailstore, búsqueda y sincronización del cliente ahora manejan blobs más grandes; la capa de almacenamiento puede estar luchando con amplificación de lectura.

Solución: Revisa la estrategia de almacenamiento e indexación del mailstore, añade caching donde aplique y considera limitar adjuntos grandes incluso si SMTP puede aceptarlos.

FAQ

1) Si fijamos nuestro límite en 100 MB, ¿los socios podrán recibir 100 MB?

No de forma fiable. Muchos dominios remotos rechazarán mucho antes, a menudo alrededor de 10–25 MB. Tu servidor aceptará, encolará, reintentará y luego rebotará.
Si necesitas transferencia garantizada, usa un mecanismo de compartición de archivos y envía un enlace por correo.

2) ¿Cómo traduzco “límite de adjunto” a bytes del MTA?

Planea la sobrecarga base64/MIME. Una regla operativa aproximada: multiplica el tamaño de adjunto deseado por ~1.35 para obtener un objetivo seguro de message_size_limit, luego añade un poco para encabezados y estructura multipart.
Prueba con tipos de archivo reales y clientes; algunos clientes inflan de forma distinta.

3) ¿Deberían inbound y outbound tener el mismo máximo?

No. El entrante desde Internet es de mayor riesgo. El envío autenticado tiene menos riesgo pero aún necesita throttles porque el compromiso de cuentas es real.
Separa límites por listener y aplica controles basados en identidad para la salida.

4) ¿Cuál es el mayor riesgo operativo al aumentar límites?

La explosión de colas y almacenamiento durante fallos de entrega externa. Los mensajes grandes diferidos consumen espacio de spool rápidamente y aumentan el coste de los reintentos.
El segundo mayor riesgo es la saturación/timeouts de la capa de filtros.

5) ¿Por qué vemos “aceptado” y luego un rebote?

La aceptación SMTP significa que tu servidor acordó asumir la responsabilidad de la entrega. No significa que el destinatario lo aceptará.
Además, componentes downstream (filtros, DLP, almacenamiento) pueden rechazar tras la aceptación si sus límites son menores.

6) ¿No podemos simplemente aumentar los timeouts para que los envíos grandes no fallen?

Puedes, pero hazlo selectivamente. Timeouts más largos en inbound anónimo permiten que sesiones lentas acaparen sockets y recursos.
Prefiere timeouts más largos en submission autenticado, junto con límites de conexión y limitación de tasa.

7) ¿Cómo evitamos el abuso si permitimos adjuntos salientes más grandes?

Usa throttles por usuario y por IP, monitoriza anomalías de envíos grandes y aplica políticas por tipo de adjunto. Asegura que la autenticación es fuerte (MFA cuando sea aplicable) y que las cuentas comprometidas no puedan enviar cargas grandes ilimitadas.

8) ¿Qué debemos monitorizar específicamente después de aumentar límites?

Profundidad de cola (activa/diferida), distribución de tamaño de ítems en cola, uso de disco y consumo de inodos en spool/temp, IO wait, timeouts de filtros y tasas de rebote saliente (especialmente 552/5.2.3).
También rastrea volumen de “aceptado y luego rebotado”: esos son fallos costosos.

9) ¿Es mejor rechazar mensajes grandes en tiempo SMTP o aceptar y procesarlos después?

Rechaza temprano siempre que sea posible. El rechazo temprano es barato y honesto. Aceptar y luego fallar malgasta recursos y crea confusión para el usuario.
Alinea límites a lo largo de la cadena para que el primer MTA pueda rechazar con un mensaje claro.

10) ¿Qué le decimos al usuario cuando un destinatario rechaza mensajes grandes?

Dales una política que reconozca la realidad: “Soportamos envío hasta X MB, pero algunos destinatarios solo aceptan Y MB. Usa compartición de archivos aprobada para archivos más grandes.”
Si no provees una alternativa, la crearán ellos y no te gustará.

Conclusión: próximos pasos prácticos

Aumentar los límites de tamaño de mensajes de correo es fácil de hacer y sorprendentemente fácil de lamentar. La versión segura es deliberada: mide cuellos de botella, alinea límites en toda la cadena, añade controles anti-abuso y acepta que Internet público no seguirá tu memo de política interno.

Próximos pasos que puedes ejecutar esta semana

• Inventaria límites de extremo a extremo: submission, MX entrante, proxies, filtros, almacenamiento de buzones, cuotas.
• Realiza dos pruebas controladas: un mensaje grande desde un cliente interno a un buzón interno; otro a un dominio externo común. Rastrea IDs de cola hasta el estado final.
• Arregla tu cuello de botella más probable: espacio/IO del spool, timeouts de filtros o caps desalineados.
• Implementa guardarraíles antes del aumento: límites de tasa, controles por usuario, monitorización de presión por mensajes grandes.
• Aumenta límites en incrementos y vigila métricas como un adulto observando a un niño junto a una escalera abierta.

Si lo haces bien, los usuarios dejarán de quejarse y tus gráficas de cola seguirán siendo aburridas. Aburrido es el mayor cumplido que te pueden dar los sistemas en producción.