Analizar encabezados de correo no entregados (correo devuelto)

¿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 bounce+OrigEmailAddress@example.com , 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.

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.

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 fakemail@example.com al servidor mail.example.com .
• En mail.example.com, fakemail@example.com tenía un alias realmail@example.net 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 myuser@yahoo.com -> myuser@example.net . 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: noreply-myuser=yahoo.com@example.org
Delivered-To: noreply-263462085117-1425506829-myuser=yahoo.com@example.org
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 <noreply-263462085117-1425506829-myuser=yahoo.com@example.org>; 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: MAILER-DAEMON@yahoo.com
To: noreply-263462085117-1425506829-myuser=yahoo.com@example.org
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.

<myuser@example.net>:
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.