Un código de estado mejorado es una pista estructurada, no un informe de incidente completo. “5.7.1” puede limitar la investigación hacia la seguridad o la política, pero no puede identificar al propietario de la política, la ruta afectada o el cambio de configuración correcto por sí solo. Mantenga el diagnóstico completo junto al código durante la resolución de problemas.
Lea los tres componentes
RFC 3463 define códigos de estado mejorados con componentes de clase, asunto y detalle. La clase distingue éxito, fracaso transitorio persistente y fracaso permanente. Las categorías de temas distinguen áreas como direcciones, estado del buzón, enrutamiento y seguridad o política. El detalle estrecha la condición dentro de ese tema. La respuesta SMTP ordinaria de tres dígitos sigue siendo parte de la evidencia. RFC 3463.
No trate el número final como un identificador de error global. El significado depende del código mejorado completo y del registro aplicable o de la documentación del proveedor. Un sistema receptor también puede devolver prosa útil sin un código mejorado. Si las clases básica y mejorada parecen inconsistentes, conserve los bytes exactos e investigue el comportamiento del proveedor en lugar de reescribir silenciosamente el registro.
Separe las respuestas SMTP de los informes de entrega
Se produce una respuesta SMTP durante una conversación. Una notificación de estado de entrega puede informar resultados más adelante y puede describir a varios destinatarios. RFC 3464 define campos que incluyen destinatario final, acción, estado, MTA remoto y código de diagnóstico. Lea los bloques por destinatario de forma independiente; un fracaso no prueba que todos los destinatarios hayan fracasado. RFC 3464 sección 2.
Acción y Estado responden a diferentes preguntas. Acción: falló significa que el informe MTA ha detenido los intentos para ese destinatario. Estado: 4.2.2 aún puede describir la causa transitoria del buzón lleno después de que se agoten los reintentos; fallido más un estado 4.xx es válido en un DSN, no una respuesta SMTP inconsistente. Por ejemplo, un artículo vencido con esos campos no se reanudará automáticamente simplemente porque regresa la capacidad. Verifique la cola real antes de autorizar cualquier reemplazo. Ver RFC 3464 sección 2.3.3.
Un asunto de rebote legible por humanos es útil para la clasificación, pero puede omitir los campos decisivos. Obtenga el informe legible por máquina o el registro de envío cuando sea posible. Mantenga el servidor de informes separado del servidor remoto y distinga la marca de tiempo de un informe de la marca de tiempo del comando SMTP fallido.
Leer un bloque de destinatario hipotético
Supongamos que un registro de envío registra RCPT TO para missing@example.test seguido de 550 5.1.1. Un bloque de destinatario DSN ilustrativo podría contener Final-Recipient: rfc822; missing@example.test , Acción: fallida, Estado: 5.1.1, MTA remoto: dns; mx.example .prueba y código de diagnóstico: smtp; 550 5.1.1 No existe tal usuario. Estos son valores de campo inventados, no una transacción ejecutada ni un informe MIME completo.
La acción fallida es definitiva para este destinatario, mientras que el diagnóstico apunta a abordarlo. No establece por qué la dirección no está disponible ni qué pasó con otros destinatarios. Obtenga esas respuestas de sus propios bloques y registros confiables. Destinatario final, Acción y Estado son campos obligatorios por destinatario; El MTA remoto y el código de diagnóstico son condicionales u opcionales. Su ausencia no es permiso para inventar un host rechazante o un texto de error.
Para detalles registrados desconocidos, consulte el actual Registro de estado mejorado IANA y la especificación citada, luego la explicación actual del proveedor. RFC 3463 proporciona el marco, no una lista exhaustiva de todos los códigos posteriores.
Convierta el código en una hipótesis comprobable
Para un código de direccionamiento, confirme la dirección deseada y el comportamiento del sistema receptor. Para obtener un código de enrutamiento, inspeccione el siguiente salto fallido y la configuración de ruta. Para un código de seguridad o política, identifique el requisito nombrado y su propietario. Evite comenzar con un cambio DNS preferido y luego interpretar cada respuesta como apoyo al mismo.
Registre una hipótesis, la evidencia que predice y la prueba autorizada más pequeña. Un mensaje corregido debe compararse con el original en la ruta y clase de destinatario correspondientes. Preservar un resultado contradictorio como evidencia útil en lugar de forzarlo a incluirlo en la explicación original. Los paquetes de escalada deben incluir marcas de tiempo, respuesta exacta, alcance afectado y cambios ya probados, con el contenido del mensaje y los datos personales minimizados. Una búsqueda de código es el comienzo del diagnóstico, no su finalización.
Cree un paquete de escalada útil
- Identidad: conserva los identificadores del mensaje y la cola, el destinatario del sobre fallido y el alcance afectado.
- Cronograma: envío de registros, intento fallido y llegada del informe por separado.
- Diagnóstico: incluya los campos exactos de respuesta SMTP , etapa de comando y DSN por destinatario.
- Propiedad: distinguir el sistema de notificación del sistema de rechazo, con evidencia para cada uno.
- Siguiente paso: indicar una causa comprobable, el cheque autorizado más pequeño y cualquier evidencia contradictoria. Minimizar los datos personales.