Por qué PowerMTA categoriza los bounces numéricamente
Las respuestas SMTP vuelven de los servidores de correo receptores como cadenas de texto. El texto es legible por humanos, a veces idiosincrásico y muchas veces inconsistente entre proveedores. Gmail dice una cosa; Outlook dice otra; un ISP pequeño en Brasil dice una tercera. Tratar esas cadenas directamente es frágil. PowerMTA resuelve el problema parseando la respuesta y asignando un código de categoría: un entero pequeño que resume qué tipo de fallo ocurrió, sin importar cómo lo formuló el destinatario.
La categoría se escribe en el accounting log como el campo bounceCat. Combinada con el tipo de bounce (Hard, Soft, Block, Admin, Undetermined), le da una superficie estable contra la cual escribir reglas de supresión y análisis de reputación. Su código mira el entero; PowerMTA maneja la complejidad de parseo de texto.
El campo bounceCat está disponible en los tipos de registro del accounting log b (notificaciones de bounce generadas al sender original) y d (intentos de entrega que resultaron en una respuesta final no-2xx). Configúrelo en la lista record-fields de su directiva <acct-file> para incluirlo en el output CSV que su pipeline de supresión y analítica lee.
La tabla completa de categorías de bounce
PowerMTA define aproximadamente veinte categorías distintas. Han sido estables a través de las versiones major, incluyendo PowerMTA 5.x. La tabla de abajo es la referencia canónica, con orientación de acción añadida.
Estrategia de supresión por tipo de bounce
El tipo de bounce le dice si el fallo es permanente, temporal, o señaliza algo distinto. La regla de supresión correcta depende del tipo, no solo del código numérico.
Hard bounces (10, 30, 90)
Suprimir inmediatamente en la primera ocurrencia. El destinatario no recibió este mensaje y no recibirá los futuros. Continuar enviando daña la reputación. La latencia bounce-a-supresión debe medirse en minutos, no en horas.
Admin bounces (25, 80)
Suprimir inmediatamente. El código 25 (admin failure) significa que la propia configuración de PowerMTA evitó la entrega: un match de política interna, una bounce rule, un rate cap. El código 80 (solicitud de suscripción) es metadata administrativa, no un problema de entrega.
Soft bounces (20, 21, 22, 23, 24, 40, 60, 70, 100)
PowerMTA reintenta automáticamente con exponential backoff. La supresión debería entrar solo después de un umbral: una regla común es suprimir tras cinco soft bounces consecutivos en treinta días. Los bounces de mailbox-full (22) y los DNS failures (21) merecen monitoreo más cercano; un destinatario cuyo buzón ha estado lleno dos meses es efectivamente un hard bounce.
Eventos Block (50, 51, 52, 53, 54)
Estos son los códigos operativamente más importantes para trabajo activo de entregabilidad. Un evento Block señaliza que el ISP receptor tomó una decisión de filtrado. La dirección del destinatario está bien; el mensaje o el sender falló un filtro. Suprimir al destinatario es la respuesta equivocada. Investigar la causa (contenido, reputación de IP, autenticación) es la correcta.
Si su tasa de Block en un solo ISP receptor excede el 1% de los intentos hacia ese ISP en una hora, tiene un incidente activo de reputación. Pause el tráfico hacia ese ISP, revise Postmaster Tools y SNDS, identifique la causa, arréglela y reanude.
Undetermined (1)
PowerMTA no pudo parsear la respuesta. Tratar como soft. Si la tasa supera unos pocos puntos porcentuales, muestree las respuestas SMTP originales (también logueadas) y considere si necesita un patrón custom de bounce-categorizer en su configuración PMTA.
Leer bounceCat desde el accounting log
Una configuración típica de accounting que incluye la categoría de bounce se ve así en /etc/pmta/config:
records b,d
record-fields b type,timeQueued,timeLogged,orig,rcpt,header_Message-Id,jobId,vmta,bounceCat,dsnStatus,dsnDiag
record-fields d type,timeQueued,timeLogged,orig,rcpt,header_Message-Id,jobId,vmta,bounceCat,dsnStatus,dsnDiag,delay,dlvSourceIp
rolling-period hourly
max-size 1G
</acct-file>
Cada fila del CSV resultante va a contener el valor bounceCat como una de sus columnas. Su pipeline de listas de supresión lee el CSV (o lo sigue en near-real-time vía tail) y aplica sus reglas. Para operaciones de alto volumen, el CSV se mete a una cola y lo procesan workers; para operaciones más pequeñas, un cron job que corra cada cinco minutos es suficiente.
Categorización de bounces y reputación del sender
Los datos de bounces son una de las señales más fuertes disponibles para gestión proactiva de reputación. Tres patrones para monitorear semanalmente:
- Tendencia de tasa de hard bounces. Una tasa de hard bounces creciente a lo largo de semanas señaliza decay de calidad de la lista. Por encima de 2% sostenido, tiene un problema de higiene de lista que va a cascadear hacia problemas de reputación en los ISPs grandes.
- Distribución de eventos Block por ISP. Plotee los eventos Block agrupados por dominio receptor. Un pico en un ISP es un incidente de reputación localizado; una subida uniforme entre muchos ISPs es un problema del lado del sender (IP, contenido, autenticación).
- Bloques por contenido spam (52) por plantilla o campaña. Si puede correlar la categoría de bounce con la plantilla que generó el mensaje (vía el campo
jobId), puede identificar qué contenido genera filtrado y ajustar antes de lanzar la siguiente variante.
Para contexto más amplio sobre el stack de entregabilidad que usa estas señales, vea nuestros planes PowerMTA gestionado, la auditoría de entregabilidad, y el resto del blog técnico.
¿Necesita procesamiento de bounces implementado?
Nuestros planes PowerMTA gestionado incluyen categorización de bounces en tiempo real, supresión automatizada y reportes semanales de tendencia. Si su setup actual pierde bounces o los procesa lento, podemos auditar la configuración.