Analyser les en-têtes de courrier non remis (courrier rebondi)

Quelle est la meilleure façon d'analyser les en-têtes des e-mails renvoyés (non distribuables) qui sont renvoyés à mon serveur et de déterminer s'il s'agit d'un rebond logiciel ou dur?

J'envoie uniquement des e-mails d'adhésion à mes utilisateurs, mais parfois certaines adresses e-mail deviennent obsolètes. Lorsqu'un e-mail rebondit sur mon serveur, je voudrais savoir pourquoi il a rebondi (doux / dur). Ensuite, je peux le traiter de manière appropriée dans ma base de données et / ou signaler à l'utilisateur de mettre à jour son e-mail lors de la prochaine connexion.

J'utilise Ubuntu et Postfix. J'ai réussi à implémenter VERP avec des alias et des alias virtuels. Les e-mails renvoyés ont donc un chemin de retour de bounce+OrigEmailAddress@example.com , et je peux les diriger vers un script.

Maintenant que j'ai la configuration VERP, je sais à qui l'e-mail d'origine a été envoyé, mais je dois analyser les en-têtes de courrier retournés pour déterminer s'il s'agit d'un rebond doux ou d'un rebond dur.

Quelle est la meilleure façon de gérer cela? Si je comprends bien, tous les serveurs de messagerie ne respectent pas les mêmes règles, et les en-têtes peuvent avoir une variété de formats. Existe-t-il un projet open source qui assure le suivi de ce type de choses? Quelque chose de simple que je peux implémenter qui catégorisera correctement la majorité des rebonds?

J'essaie de protéger la réputation de mon serveur de messagerie, donc toute aide est très appréciée!

Comme l' explique la RFC3463 , les codes d'état commençant par 5 sont utilisés pour les défaillances permanentes et 4 pour les défaillances transitoires persistantes. Au lieu d'essayer d'analyser plusieurs messages avec différents formats, vous pouvez vous fier aux journaux du serveur et essayer quelque chose comme ceci:

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

Cela trouvera des erreurs permanentes dans mail.log (format Postfix) et donnera les adresses et le nombre de rebonds sur chaque adresse. Vous pouvez également utiliser "dsn = 4". pour obtenir des adresses avec des erreurs temporaires.

Il existe généralement deux types de rebonds

1. Les rebonds causés par le rejet direct du serveur de messagerie distant lorsque votre suffixe remet l'e-mail.
2. Les rebonds causés par le serveur distant (serveur de saut suivant après votre suffixe) ne parviennent pas à remettre le message aux destinataires finaux.

Le premier cas a déjà été couvert par l' excellente réponse d'Esa Jokinen ci-dessus. Votre meilleur pari est d'analyser maillog.

Le deuxième cas était un cas spécial de rebonds. Le scénario d'exemple:

• Vous envoyez un e-mail avec le destinataire fakemail@example.com au serveur mail.example.com .
• Dans mail.example.com, fakemail@example.com était alias à realmail@example.net et doit être transféré vers mail.example.net .
• Un jour, mail.example.net rejette votre message, donc mail.example.com doit envoyer des rebonds à votre serveur.
• Malheureusement, maillog sur votre serveur aura "dsn = 2" car mail.example.com a déjà accepté le message mais n'a pas réussi à le transmettre à mail.example.net .

Voici l'exemple du deuxième type de courrier électronique rebondit. Il existe une règle de transfert du serveur de messagerie Yahoo myuser@yahoo.com -> myuser@example.net . Malheureusement, le serveur de messagerie d'exemple.net rejette le message :(

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]

Dans ce cas, votre seule méthode consiste à analyser le message de rebonds. Malheureusement, il n'y a pas de format de rebond standard, vous devez donc analyser le corps et déterminer le rejet causé.

La liste de contrôle des fonctionnalités de votre analyse de rebond postfix:

1. Vérifiez si l'adresse VERP était valide. Vous ne voulez pas analyser un message invalide.
2. Analyser le corps, déterminer s'il s'agit d'un rejet doux ou dur.

Pour la deuxième fonctionnalité, vous pouvez rechercher sur Google un message de rejet commun. L'exemple est ce bounce-regex-list.xml de Jakub Liska .

Esa Jokinen a fait un bon point dans le commentaire ci-dessous à propos de ces deux types de rebond. Si votre objectif est de conserver la réputation du serveur, le traitement du premier type de rebond devrait suffire. Le deuxième rebond concernait le nettoyage de vos listes. Les e-mails morts doivent donc être effacés, libérant ainsi des ressources sur votre serveur.

Certains gestionnaires de listes de diffusion tels que PHPlist et Mailman traitent également ce problème de rebond avec l'analyse du corps de l'e-mail car ils n'ont pas de ressources pour analyser le maillog.