Una notificación de entrega suele contener varios nombres de servidores, fechas y direcciones. El sistema que envía el informe no es necesariamente el sistema que rechazó el mensaje. Analice sus campos de estado de entrega y correlacione el intento original antes de realizar un cambio DNS o de buzón según la línea de asunto del informe.
Identificar los sistemas remotos y de informes.
RFC 3464 define el formato del cuerpo del estado de entrega. Reporting-MTA identifica el sistema que produce la notificación. El MTA remoto, cuando está presente, identifica un sistema remoto asociado con el intento de entrega informado. Diagnostic-Code puede preservar la respuesta del protocolo remoto. La explicación legible por humanos es útil, pero su prosa no debería reemplazar los campos estructurados. RFC 3464 secciones 2.2 y 2.3.
Registre ambas identidades del sistema y los tiempos reportados. Una retransmisión que aceptó correo de la aplicación podría recibir posteriormente un rechazo de un servidor destinatario y construir el propio DSN. Tratar el nombre del repetidor como el destino de rechazo puede enviar una investigación al administrador equivocado y oscurecer la respuesta SMTP original.
Lea cada bloque de destinatario de forma independiente
Destinatario final identifica el destinatario al que se aplica un bloqueo de estado de entrega. El destinatario original, cuando está presente, puede preservar la identidad de un destinatario anterior. Acción describe la acción de entrega, como fallida o retrasada. El estado lleva un código de estado mejorado. El código de diagnóstico opcional, la fecha del último intento y el reintento hasta que puedan proporcionar un contexto adicional útil, pero no todos los informes los proporcionan.
Cuando el código de diagnóstico está presente, la sección 2.3.6 RFC 3464 interpreta un MTA remoto suministrado como su emisor; sin Remote-MTA, el diagnóstico se atribuye a Reporting-MTA. Esa regla de campo no prueba que nunca se haya producido ningún intento remoto anterior. Corroborar el historial completo con registros confiables.
Un DSN puede incluir múltiples bloques de destinatarios con diferentes acciones y valores de estado. No aplique un error a todos los que aparecen en el encabezado Para o CC original. De manera similar, un campo opcional faltante no es prueba de que el evento correspondiente nunca ocurrió. Preservar la ausencia como desconocida y utilizar evidencia de cola o rastreo para llenar el vacío.
Leer una notificación de vencimiento hipotética
Imagine que relay.example acepta un mensaje y luego recibe 452 4.2.2 Buzón lleno de mx.example cuando intenta la entrega. Una vez que expira su vida útil de entrega configurada, el relé genera un DSN. Un extracto didáctico podría identificar Reporting-MTA: dns; relay.example , MTA remoto: dns; mx.example , Destinatario final: rfc822; recipient@example.test , Acción: fallida, Estado: 5.4.7 y Código de diagnóstico: smtp; 452 4.2.2 Buzón lleno.
Este es un recorrido de campo inventado, no un informe MIME completo ni un intercambio de correo ejecutado. El estado final describe el vencimiento del plazo de entrega, mientras que el diagnóstico conservado describe el último rechazo de capacidad. Los campos responden a diferentes preguntas. Este no es un mapeo preferido universal: RFC 3463 sección 3.5 dice que se devuelva el código de problema de entrega real en lugar de caducar cuando sea posible. Preservar la causa apoyada más específica. RFC 3464 también permite Acción: falló con un estado 4.xx después del informe MTA ha abandonado los intentos; una causa transitoria no significa que el original permanezca en cola.
Para su propio informe, correlacione el envío original, los intentos, la decisión de vencimiento y la llegada del informe por separado. No asuma que los nombres, horarios o campos ilustrativos coinciden con un proveedor. Conserve los campos opcionales que faltan sin llenarlos con valores adivinados.
Correlacionar antes de actuar
Haga coincidir la notificación con el destinatario del sobre original, la hora de envío y los identificadores de cola disponibles. Original-Envelope-Id puede ayudar a la correlación cuando esté presente; un ID de mensaje devuelto es otra pista más que una autenticación suficiente de la notificación en sí. Los informes pueden ser falsificados o causados por falsificaciones. camino de retorno direcciones, por lo que un rebote inesperado no debe desencadenar automáticamente un cambio en la configuración del remitente.
Utilice registros de envío confiables para establecer que la organización realmente envió el mensaje. Evite abrir archivos adjuntos devueltos o seguir solicitudes de credenciales simplemente porque el mensaje parece un rebote. Si no existe ningún envío coincidente, investigue el informe como potencialmente no solicitado o falsificado en lugar de tratarlo como prueba de que la cuenta está comprometida.
Asignar la corrección a la capa derecha.
Un estado de dirección va al buzón o al propietario del contacto. Un problema de ruta o conexión necesita evidencia de transporte. Un diagnóstico de autenticación requiere las identidades reales de los mensajes relevantes y la evaluación de la recepción. Conserve el diagnóstico completo para que el especialista pueda distinguir fallas de apariencia similar.
Después de una corrección aprobada, correlacione cualquier nuevo intento con su propia cola y identificadores de mensajes. No sobrescriba el informe histórico con el resultado posterior. Cerrar la avería original, la reparación y la entrega de sustitución como hechos relacionados pero distintos. Esto preserva un cronograma honesto cuando llega un informe retrasado después de un reenvío exitoso.
Prepare una escalada específica del destinatario
- Correlación: haga coincidir el informe con un envío legítimo utilizando evidencia del destinatario, la hora y la cola.
- Emisor: conserve el Reporting-MTA por separado del Remote-MTA y el emisor de diagnóstico.
- Resultado: preservar la acción, el estado y el código de diagnóstico original sin forzarlos a coincidir.
- Propietario: asigne la capa de error real, no simplemente el remitente del rebote.
- Privacidad: proporcione solo los campos de informe necesarios; no reenvíe contenido de mensajes devueltos no relacionados.