Analizar encabezados de correo no entregados (correo devuelto)

9

¿Cuál es la mejor manera de analizar los encabezados del correo electrónico devuelto (no se puede entregar) que se envía de vuelta a mi servidor y determinar si se trata de un rechazo suave o duro?

Solo envío correos electrónicos de suscripción voluntaria a mis usuarios, pero ocasionalmente algunas direcciones de correo electrónico quedan obsoletas. Cuando un correo electrónico se devuelve a mi servidor, me gustaría saber por qué se devolvió (suave / duro). Entonces puedo tratarlo adecuadamente en mi base de datos y / o marcar al usuario para que actualice su correo electrónico la próxima vez que inicie sesión.

Estoy usando Ubuntu y Postfix. He implementado con éxito VERP con alias y alias virtuales. Por lo tanto, los correos electrónicos devueltos tienen una ruta de retorno de [email protected] , y puedo canalizarlos a un script.

Ahora que tengo la configuración VERP, sé a quién se envió el correo electrónico original, pero necesito analizar los encabezados de correo devueltos para determinar si es un rebote suave o un rebote duro.

¿Cuál es la mejor manera de manejar esto? Según tengo entendido, no todos los servidores de correo cumplen las mismas reglas, y los encabezados pueden tener una variedad de formatos. ¿Hay algún proyecto de código abierto que haga un seguimiento de este tipo de cosas? ¿Algo simple que pueda implementar que clasifique la mayoría de los rebotes correctamente?

Estoy tratando de proteger la reputación de mi servidor de correo, por lo que cualquier ayuda es muy apreciada.

email email-server email-bounces Ricardo
fuente

Respuestas:

9

Como explica RFC3463 , los códigos de estado que comienzan con 5 se usan para fallas permanentes y 4 para fallas transitorias persistentes. En lugar de intentar analizar varios mensajes con diferentes formatos, puede confiar en los registros del servidor e intentar algo como esto:

grep " dsn=5." /var/log/mail.log | grep -o -P " to=<(.+?)>" | sort | uniq -c

Esto encontrará errores permanentes de mail.log (formato Postfix) y dará las direcciones y la cantidad de rebotes en cada dirección. También puede usar "dsn = 4". para obtener direcciones con errores temporales.

Esa Jokinen
fuente
Gracias esa! No me di cuenta de que Postfix tenía esa información en el registro de correo. ¿Es esta la solución que usas? ¿Le parece que postfix clasifica los rebotes dsn = 5 correctamente? He leído que algunos servidores de correo no cumplen con RFC. Así que pensé que podría ser necesaria una solución más complicada. ¿Cuál ha sido tu experiencia? Esto parece una buena solución si podemos probar postfix para hacerlo bien :-)
Richard
Guión realmente útil: ¡gracias! Receta aquí para una alternativa al indicador grep's -P (para usuarios de Mac, etc.): unix.stackexchange.com/a/437694/275762 grep " dsn=5." /var/log/mail.log | pcregrep -o1 " to=<(.+?)>" | sort | uniq -c
Peter M.
8

Generalmente hay dos tipos de rebotes

  1. Los rebotes causados ​​por el rechazo directo del servidor de correo remoto cuando su postfix entrega el correo electrónico.
  2. Los rebotes causados ​​por el servidor remoto (servidor del siguiente salto después de su postfix) no pueden entregar el mensaje a los destinatarios finales.

El primer caso ya estaba cubierto por la excelente respuesta de Esa Jokinen arriba. Su mejor apuesta es analizar el registro de correo.

El segundo caso fue un caso especial de rebotes. El escenario de ejemplo:

  • Envía un correo electrónico con el destinatario [email protected] al servidor mail.example.com .
  • En mail.example.com, [email protected] tenía un alias [email protected] y debe reenviarse a mail.example.net .
  • Algún día mail.example.net rechazará su mensaje, por lo que mail.example.com debe enviar devoluciones a su servidor.
  • Lamentablemente, el registro de correo de su servidor tendrá "dsn = 2" porque mail.example.com ya aceptó el mensaje pero no pudo reenviarlo a mail.example.net .

Aquí el ejemplo del segundo tipo devuelve el correo electrónico. Hay una regla de reenvío del servidor de correo de Yahoo [email protected] -> [email protected] . Lamentablemente, el servidor de correo de example.net rechaza el mensaje :(

From MAILER-DAEMON  Thu Mar  5 05:07:26 2015
Return-Path: <>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from nm21-vm7.bullet.mail.gq1.yahoo.com (nm21-vm7.bullet.mail.gq1.yahoo.com [98.136.217.54])
        (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
        (No client certificate requested)
        by mx.example.org (Postfix) with ESMTPS id D6365565FC
        for <[email protected]>; Thu,  5 Mar 2015 05:07:25 +0700 (WIT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=bounce; t=1425506842; bh=zk/tWZNl6c36dmlPDmakM9ekK8cHVJANXMmSdsbkcWc=; h=From:To:Date:Subject:From:Subject; b=Im95h1qTg6qN3yUI7vF1fXtJ0SbUnzv8rUPwLbpNwxGPN2p8wfosXJzQgJ3nzr4L4ZQ50P2d9E9U4jEUNtnyi7nlFd5kKbtiVuda4H56h1PFnt+7wSpgHcd5Irs/lLODumb6ZZSEpCOWttcB9+JLaDfEUUPjGcbR+xww4XeH5Eo=
From: [email protected]
To: [email protected]
Date: Wed, 04 Mar 2015 22:07:22 -0000
Subject: Failure Notice
X-Yahoo-Newman-Property: bmbounce

Sorry, we were unable to deliver your message to the following address.

<[email protected]>:
Remote host said:
550 5.1.1 User unknown
 [RCPT_TO]

Para este caso, su único método es analizar el mensaje de rebotes. Desafortunadamente, no hay un formato de rebotes estándar, por lo que debe analizar el cuerpo y determinar el rechazo causado.

La lista de verificación de características de su análisis de rebote postfix:

  1. Verifique si la dirección VERP era válida. No desea analizar un mensaje no válido.
  2. Analiza el cuerpo, determina si son rechazo suave o duro.

Para la segunda característica, puedes buscar en Google algún mensaje de rechazo común. El ejemplo es este bounce-regex-list.xml de Jakub Liska .

Esa Jokinen hizo un buen punto en el comentario a continuación sobre estos dos tipos de rebote. Si su objetivo es mantener la reputación del servidor, entonces tratar con el primer tipo de rebote debería ser suficiente. El segundo rebote fue sobre limpiar tus listas. Por lo tanto, se debe borrar el correo electrónico muerto, liberando así algunos recursos en su servidor.

Algunos administradores de listas de correo como PHPlist y Mailman también se ocupan de este problema de rebote al analizar el cuerpo del correo electrónico ya que no tienen recursos para analizar el registro de correo.

masegaloeh
fuente
1
Esta solución es útil y más exhaustiva si es necesario manejar también los correos enviados automáticamente a otra dirección. Sin embargo, si el objetivo es proteger la reputación del servidor de correo, manejar los rechazos directos debería ser suficiente. Los administradores de la MTA de reenvío deben eliminar reenvíos y listas de correo obsoletos (para proteger su reputación y evitar tráfico innecesario). Después de eso estamos de vuelta en el caso uno. OP debería usar esta solución si la cantidad de rebotes secundarios es significativa. Lo que alguna vez requiere menos esfuerzo.
Esa Jokinen
@masegaloeh, gracias por la información! ¡Ni siquiera había considerado esa situación de reenvío como una posibilidad! Por ahora, me preocupa principalmente proteger el representante de mi servidor de correo, pero si aumentan los rebotes, esto puede ser muy útil.
Richard