Puede ocurrir un rechazo del tamaño de un mensaje antes de que el servidor receptor evalúe toda la autenticación del mensaje. También puede aparecer después de que un servidor ascendente haya aceptado un mensaje y un salto posterior aplique un límite menor. Diagnosticar la condición de tamaño en el salto de rechazo en lugar de tratar cada rechazo permanente como un SPF, DKIM o DMARC defecto.
Distinguir el tamaño de la política y el almacenamiento
RFC 3463 define X.3.4 como un mensaje demasiado grande para el sistema receptor y X.2.3 como una longitud de mensaje que excede un límite administrativo para el buzón. Estos difieren del buzón X.2.2 lleno. Lea el diagnóstico completo porque los productos pueden agregar sus propios límites, unidades y texto explicativo. Una etiqueta genérica "552" por sí sola no establece la restricción configurada exacta. RFC 3463 secciones 3.3 y 3.4.
Los fallos de autenticación se refieren a identidades, firmas o políticas más que al número de octetos del mensaje. Reducir el tamaño no es una reparación DKIM ; cambiar el contenido firmado puede invalidar una firma, por lo que un reemplazo autorizado debe pasar por el flujo de trabajo de firma normal. Por el contrario, autorizar otra IP en SPF no aumenta el tamaño del mensaje permitido al destinatario. Mantenga las dos investigaciones separadas a menos que evidencia independiente demuestre que ambas están fallando.
Lea correctamente la capacidad TAMAÑO anunciada
La extensión SMTP TAMAÑO permite que un servidor anuncie soporte y, opcionalmente, un tamaño máximo de mensaje en su EHLO respuesta. Un cliente de apoyo puede proporcionar un tamaño estimado con CORREO DE, permitiendo el rechazo antes de transmitir el mensaje completo. TAMAÑO sin un número no transmite información máxima fija; TAMAÑO 0 indica explícitamente que no hay ningún máximo fijo vigente. Ninguno garantiza la aceptación. El procesamiento posterior y otros lúpulos aún pueden imponer limitaciones. RFC 1870 secciones 3 y 4.
Para RFC 1870 TAMAÑO, cuente los octetos de mensajes, incluidos los finales de línea CRLF, los encabezados, la estructura MIME y el contenido codificado, pero excluya el punto de terminación de DATOS y los bytes de relleno de puntos adicionales. No cuente sólo el archivo adjunto. La codificación Base64 expande los datos binarios y los saltos de línea y las partes del mensaje circundantes agregan más bytes. Ver RFC 2045 sección 6.8. Las interfaces del proveedor pueden mostrar unidades redondeadas de manera diferente. Registre los octetos medidos y el límite exacto anunciado o documentado en lugar de comparar dos etiquetas "MB" inexplicables.
Comparar variantes controladas
Cree dos variantes autorizadas que se diferencien solo en el contenido relevante para el tamaño. Conserve los tamaños serializados más pequeños y más grandes y la etapa SMTP de cada resultado. Un par ilustrativo podría contener el mismo texto breve explicativo, con un archivo adjunto grande reemplazado por un enlace de archivo aprobado con acceso controlado. No asuma que el enlace de un archivo es adecuado para material confidencial o que el destinatario tiene acceso.
La sección 4.5.3.1 RFC 5321 requiere compatibilidad con un tamaño de mensaje de al menos 64 KB octetos, incluidos los encabezados. El siguiente límite de 100.000 octetos está por encima del mínimo del protocolo y no es una configuración recomendada por el proveedor.
Para una verificación aritmética hipotética, supongamos que el mismo punto final anuncia TAMAÑO 100000. Un mensaje supuesto de 115.900 octetos excede ese límite en 15.900 octetos; un reemplazo supuesto de 20.100 octetos está 79.900 octetos por debajo de él. El primero se puede rechazar en MAIL FROM; el segundo es elegible para procesamiento posterior pero no se garantiza su aceptación. Estos números son inventados, no mediciones ni resultados SMTP ejecutados. No describen el límite máximo de vinculación de ningún proveedor.
Reparar la restricción relevante más estrecha
Pregúntele al propietario del sistema de rechazo si el tamaño es un límite de servicio intencional o una configuración controlada por la organización. Si la necesidad empresarial se puede satisfacer con un archivo más pequeño, utilice esa ruta en lugar de aumentar los límites en todo el sistema de correo. Si se autoriza un cambio de límite, considere el consumo de recursos, el escaneo de malware y la compatibilidad descendente antes de aplicarlo.
No sigas intentando volver a intentar el mismo contenido rechazado permanentemente sin cambios. Confirme que el original no fue aceptado en otro salto o para otro destinatario, luego envíe el reemplazo aprobado con una relación clara con el intento anterior. Preservar sus propios identificadores de mensajes y colas. Un mensaje nuevo es un nuevo evento de entrega, incluso si el usuario lo considera como el mismo archivo adjunto.
Cierre con el tamaño del mensaje medido, el límite de rechazo identificado y el resultado del intento corregido. Deje la ubicación de la bandeja de entrada y el acceso de los destinatarios al contenido vinculado como comprobaciones independientes.
Separar el límite de la solución alternativa
- Medida: cuente el mensaje serializado completo utilizando la definición de TAMAÑO, no solo el archivo adjunto.
- Localizar: capture el salto de rechazo, la etapa de comando, el diagnóstico y el límite aplicable.
- Reparación: elija un mensaje más pequeño aprobado o un método de entrega con acceso controlado.
- Vuelva a verificar: registre el tamaño del reemplazo y el resultado por destinatario; no asuma que todos los límites posteriores coinciden.
- Cerrar: confirma el acceso del destinatario por separado de la aceptación SMTP .