Analisar cabeçalhos de e-mail não entregues (e-mail devolvido)

Analisar cabeçalhos de e-mail não entregues (e-mail devolvido)

Qual é a melhor maneira de analisar os cabeçalhos de e-mails devolvidos (não entregues) que são enviados de volta ao meu servidor e determinar se é uma devolução suave ou definitiva?

Eu só envio e-mails de aceitação para meus usuários, mas ocasionalmente alguns endereços de e-mail ficam obsoletos. Quando um e-mail retorna ao meu servidor, gostaria de descobrir por que ele foi devolvido (suave/forte). Então posso lidar com isso adequadamente em meu banco de dados e/ou sinalizar o usuário para atualizar seu e-mail no próximo login.

Estou usando Ubuntu e Postfix. Implementei com sucesso o VERP com aliases e aliases virtuais. Portanto, e-mails devolvidos têm um caminho de retorno de[e-mail protegido], e posso canalizá-los para um script.

Agora que configurei o VERP, sei para quem o e-mail original foi enviado, mas preciso analisar os cabeçalhos dos e-mails retornados para descobrir se é uma devolução suave ou uma devolução definitiva.

Qual a melhor forma de lidar com isto? Pelo que entendi, nem todos os servidores de e-mail seguem as mesmas regras e os cabeçalhos podem ter vários formatos. Existe algum projeto de código aberto que monitora esse tipo de coisa? Algo simples que eu possa implementar que irá categorizar a maioria das rejeições corretamente?

Estou tentando proteger a reputação do meu servidor de e-mail, então qualquer ajuda será muito apreciada!

Responder1

ComoRFC3463explica, os códigos de status começando com 5 são usados ​​para falhas permanentes e 4 para falhas transitórias persistentes. Em vez de tentar analisar várias mensagens com formatos diferentes, você pode confiar nos logs do servidor e tentar algo assim:

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

Isso encontrará erros permanentes em mail.log (formato Postfix) e fornecerá os endereços e a quantidade de rejeições em cada endereço. Você também pode usar "dsn=4." para obter endereços com erros temporários.

Responder2

Geralmente existem dois tipos de saltos

  1. Os saltos causados ​​pordiretorejeição do servidor de email remoto quando seu postfix entrega o email.
  2. As devoluções causadas pelo servidor remoto (servidor do próximo salto após o seu postfix) não conseguem entregar a mensagem aos destinatários finais.

O primeiro caso já estava cobertoexcelente respostapor Esa Jokinen acima. Sua melhor aposta é analisar o maillog.

O segundo caso foi um caso especial de rebotes. O cenário de exemplo:

  • Você envia e-mail com destinatário[e-mail protegido]paramail.exemplo.comservidor.
  • Em mail.example.com,[e-mail protegido]foi apelidado de[e-mail protegido]e deve ser encaminhado paramail.exemplo.net.
  • Algum diamail.exemplo.netrejeite a sua mensagem entãomail.exemplo.comdeve enviar devoluções para o seu servidor.
  • Infelizmente o maillog no seu servidor terá "dsn=2" porquemail.exemplo.comjá aceitou a mensagem, mas não conseguiu encaminhá-la paramail.exemplo.net.

Aqui está o exemplo do segundo tipo de e-mail devolvido. Existe uma regra de encaminhamento do servidor de e-mail do Yahoo[e-mail protegido]->[e-mail protegido]. Infelizmente, o servidor de e-mail de example.net rejeitou a mensagem :(

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]

Nesse caso, seu único método é analisar a mensagem de devolução. Infelizmente não existe um formato de rejeição padrão, então você deve analisar o corpo e determinar a rejeição causada.

A lista de verificação de recursos da análise de rejeição do postfix:

  1. Verifique se o endereço VERP era válido. Você não deseja analisar mensagens inválidas.
  2. Analise o corpo, determine se eles são uma rejeição suave ou forte.

Para o segundo recurso, você pode pesquisar no Google alguma mensagem de rejeição comum. O exemplo é estebounce-regex-list.xmlporJakub Liska.


Esa Jokinen fezum bom ponto no comentário abaixosobre esses dois tipos de rejeição. Se o seu objetivo é manter a reputação do servidor, lidar com o primeiro tipo de rejeição deve ser suficiente. O segundo salto foi sobre como limpar suas listas. Portanto, e-mails mortos devem ser apagados, liberando assimalgunsrecursos em seu servidor.

Alguns gerenciadores de listas de discussão, como PHPlist e Mailman, também lidam com esse problema de rejeição ao analisar o corpo do email, pois não têm recursos para analisar o maillog.

informação relacionada