☰

Analizar encabezados de correo no entregados (correo devuelto)

tag-icon • tag-icon email email-server email-bounces
Analizar encabezados de correo no entregados (correo devuelto)

¿Cuál es la mejor manera de analizar los encabezados de los correos electrónicos rebotados (que no se pueden entregar) que se envían a mi servidor y determinar si se trata de un rebote 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 rebota en mi servidor, me gustaría saber por qué rebotó (soft/hard). Luego puedo manejarlo 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. Implementé VERP con éxito con alias y alias virtuales. Entonces los correos electrónicos devueltos tienen una ruta de retorno de[correo electrónico protegido]y puedo canalizarlos a un script.

Ahora que tengo configurado VERP, sé a quién se envió el correo electrónico original, pero necesito analizar los encabezados de correo devueltos para determinar si se trata de 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 siguen las mismas reglas y los encabezados pueden tener una variedad de formatos. ¿Existe algún proyecto de código abierto que realice un seguimiento de este tipo de cosas? ¿Puedo implementar algo simple que categorice correctamente la mayoría de los rebotes?

Estoy intentando proteger la reputación de mi servidor de correo, por lo que cualquier ayuda será muy apreciada.

Respuesta1

ComoRFC3463Como explica, los códigos de estado que comienzan con 5 se utilizan para fallas permanentes y 4 para fallas transitorias persistentes. En lugar de intentar analizar varios mensajes con diferentes formatos, puedes 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 proporcionará las direcciones y la cantidad de rebotes en cada dirección. También puedes utilizar "dsn=4". para obtener direcciones con errores temporales.

Respuesta2

Generalmente hay dos tipos de rebotes.

  1. Los rebotes causados ​​pordirectorechazo 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 sufijo) no logra entregar el mensaje a los destinatarios finales.

El primer caso ya estaba cubierto porexcelente respuestapor Esa Jokinen arriba. Lo mejor que puede hacer es analizar el registro de correo.

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

  • Envías un correo electrónico con el destinatario.[correo electrónico protegido]acorreo.ejemplo.comservidor.
  • En correo.ejemplo.com,[correo electrónico protegido]tenía el alias de[correo electrónico protegido]y debe remitirse acorreo.ejemplo.net.
  • Algún díacorreo.ejemplo.netrechaza tu mensaje entoncescorreo.ejemplo.comdebe enviar rebotes a su servidor.
  • Lamentablemente, el registro de correo en su servidor tendrá "dsn=2" porquecorreo.ejemplo.comya aceptó el mensaje pero no pudo reenviarlo acorreo.ejemplo.net.

Aquí el ejemplo del segundo tipo de correo electrónico rebotado. Hay una regla de reenvío en el servidor de correo de Yahoo.[correo electrónico protegido]->[correo electrónico protegido]. Desafortunadamente 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]

En este caso, su único método es analizar el mensaje de rebote. Desafortunadamente no existe un formato de rebote estándar, por lo que debes analizar el cuerpo y determinar el rechazo causado.

La lista de verificación de funciones de su análisis de rebotes de Postfix:

  1. Compruebe si la dirección VERP era válida. No desea analizar mensajes no válidos.
  2. Analizar el cuerpo, determinar si son rechazos blandos o duros.

Para la segunda función, puedes buscar en Google algún mensaje de rechazo común. El ejemplo es esterebote-regex-list.xmlporJakub Liska.

Esa Jokinen hizoun buen punto en el comentario a continuaciónsobre estos dos tipos de rebote. Si su objetivo es mantener la reputación del servidor, entonces debería ser suficiente lidiar con el primer tipo de rebote. El segundo rebote fue sobre limpiar tus listas. Por lo tanto, los correos electrónicos muertos deben borrarse y así liberarse.algunorecursos en su servidor.

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

información relacionada