Analisar cabeçalhos de correio não entregues (correio devolvido)

Question

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

Eu só envio e-mails opt-in para meus usuários, mas ocasionalmente alguns endereços de e-mail ficam obsoletos. Quando um email retorna ao meu servidor, eu gostaria de saber por que ele retornou (soft / hard). Então eu posso lidar com isso de forma adequada no meu banco de dados e / ou sinalizar ao usuário para atualizar seu e-mail quando o login for feito.

Estou usando o Ubuntu e o Postfix. Eu tenho implementado com sucesso o VERP com aliases e alias virtuais. Por isso, os e-mails devolvidos têm um caminho de retorno de [email protected] , e posso enviá-los para um script.

Agora que tenho a configuração VERP, sei para quem o e-mail original foi enviado, mas preciso analisar os cabeçalhos de e-mail retornados para descobrir se é um retorno fácil ou difícil.

Qual é a melhor maneira de lidar com isso? Pelo que entendi, nem todos os servidores de e-mail reproduzem as mesmas regras, e os cabeçalhos podem ter vários formatos. Existe algum projeto de código aberto que rastreie esses tipos de coisas? Algo simples que eu possa implementar irá categorizar a maioria dos bounces corretamente?

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

    

Answer 1

Como RFC3463 explica, os códigos de status iniciados por 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ê poderia 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 de mail.log (formato Postfix) e fornecerá os endereços e a quantidade de devoluções em cada endereço. Você também pode usar "dsn = 4". para obter endereços com erros temporários.

    

Answer 2

Geralmente existem dois tipos de rejeições

1. As rejeições causadas pela rejeição direta do servidor de email remoto quando o postfix entrega o email.
2. As rejeições causadas pelo servidor remoto (servidor do próximo salto após o seu postfix) não entregam a mensagem aos destinatários finais.

O primeiro caso já estava coberto pela excelente resposta de Esa Jokinen acima. Sua melhor aposta é analisar o maillog.

O segundo caso foi um caso especial de rejeições. O cenário de exemplo:

• Você envia um e-mail com o destinatário [email protected] para o servidor mail.example.com .
• Em mail.example.com, [email protected] foi alias para [email protected] e deve ser encaminhado para mail.example.net .
• Algum dia mail.example.net rejeite a sua mensagem, então mail.example.com deve enviar retornos ao seu servidor.
• Infelizmente o maillog em seu servidor terá "dsn = 2" porque mail.example.com já aceitou a mensagem, mas não conseguiu encaminhá-la para mail.example.net .

Aqui, o exemplo do segundo tipo é devolvido por email. Há uma regra de encaminhamento Yahoo mail server [email protected] - > [email protected] . Infelizmente o servidor de email do example.net rejeita 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]

Neste caso, seu único método é analisar a mensagem de rejeições. Infelizmente, não há formato de rejeições padrão, portanto, 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 quer analisar a mensagem inválida.
2. Analise o corpo, determine se eles são rejeição leve ou dura.

Para o segundo recurso, você pode pesquisar no Google alguma mensagem de rejeição comum. O exemplo é este bounce-regex- list.xml por Jakub Liska .

Esa Jokinen fez um bom ponto no comentário abaixo sobre esses dois tipos de rejeição. Se seu objetivo é manter a reputação do servidor, o primeiro tipo de rejeição deve ser suficiente. A segunda rejeição foi sobre a limpeza de suas listas. Então, e-mails mortos devem ser apagados, liberando alguns recursos em seu servidor.

Alguns gerenciadores de lista de discussão, como o PHPlist e o Mailman, também lidam com esse problema de rejeição ao analisar o corpo do email, já que não possuem recursos para analisar o maillog.