Analysieren Sie nicht zugestellte E-Mail-Header (zurückgesendete E-Mails).

Was ist der beste Weg, um die Header von zurückgesendeten (unzustellbaren) E-Mails, die an meinen Server zurückgesendet werden, zu analysieren und festzustellen, ob es sich um einen weichen oder einen harten Absprung handelt?

Ich sende nur Opt-In-E-Mails an meine Benutzer, aber gelegentlich sind einige E-Mail-Adressen veraltet. Wenn eine E-Mail auf meinen Server zurückspringt, möchte ich herausfinden, warum sie zurückgeschickt wurde (weich / hart). Dann kann ich in meiner Datenbank angemessen damit umgehen und / oder den Benutzer markieren, um seine E-Mail bei der nächsten Anmeldung zu aktualisieren.

Ich benutze Ubuntu und Postfix. Ich habe VERP erfolgreich mit Aliasen und virtuellen Aliasen implementiert. So haben zurückgesendete E-Mails den Rückweg bounce+OrigEmailAddress@example.com , und ich kann sie an ein Skript weiterleiten .

Nachdem ich VERP eingerichtet habe, weiß ich, an wen die ursprüngliche E-Mail gesendet wurde, aber ich muss die zurückgegebenen E-Mail-Header analysieren, um herauszufinden, ob es sich um einen weichen oder einen harten Sprung handelt.

Was ist der beste Weg, um damit umzugehen? Soweit ich weiß, spielen nicht alle Mailserver nach denselben Regeln, und Header können verschiedene Formate haben. Gibt es ein Open-Source-Projekt, das diese Art von Dingen verfolgt? Etwas Einfaches, das ich implementieren kann und das die meisten Bounces richtig kategorisiert?

Ich versuche, den Ruf meines Mailservers zu schützen, daher ist jede Hilfe sehr willkommen!

Wie in RFC3463 erläutert, werden Statuscodes, die mit 5 beginnen, für dauerhafte Fehler und 4 für dauerhafte vorübergehende Fehler verwendet. Anstatt zu versuchen, mehrere Nachrichten mit unterschiedlichen Formaten zu analysieren, können Sie sich auf Serverprotokolle verlassen und Folgendes versuchen:

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

Dadurch werden dauerhafte Fehler in mail.log (Postfix-Format) gefunden und die Adressen und die Anzahl der Bounces für jede Adresse angegeben. Sie können auch "dsn = 4" verwenden. um Adressen mit temporären Fehlern zu erhalten.

Im Allgemeinen gibt es zwei Arten von Bounces

1. Die Bounces, die durch die direkte Ablehnung des Remote-Mail-Servers verursacht werden, wenn Ihr Postfix die E-Mail übermittelt.
2. Die vom Remote-Server (Next-Hop-Server nach Ihrem Postfix) verursachten Bounces können die Nachricht nicht an die endgültigen Empfänger übermitteln.

Der erste Fall wurde bereits durch eine ausgezeichnete Antwort von Esa Jokinen oben abgedeckt . Ihre beste Wette ist das Parsen von Maillog.

Der zweite Fall war ein Sonderfall von Bounces. Das Beispielszenario:

• Sie senden eine E-Mail mit dem Empfänger fakemail@example.com an den Server mail.example.com .
• In mail.example.com, fakemail@example.com wurde aliased realmail@example.net und muss weitergeleitet werden mail.example.net .
• Eines Tages lehnt mail.example.net Ihre Nachricht ab, sodass mail.example.com Bounces an Ihren Server senden muss.
• Leider hat maillog auf Ihrem Server "dsn = 2", da mail.example.com die Nachricht bereits akzeptiert hat, sie jedoch nicht an mail.example.net weiterleiten konnte .

Hier springt das Beispiel des zweiten Typs E-Mails. Es gibt eine Weiterleitungsregel für den Yahoo-Mailserver myuser@yahoo.com -> myuser@example.net . Leider lehnt der Mailserver von example.net die Nachricht ab :(

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]

In diesem Fall besteht Ihre einzige Methode darin, die Bounces-Nachricht zu analysieren. Leider gibt es kein Standard-Bounces-Format, daher müssen Sie den Body analysieren und die verursachte Zurückweisung ermitteln.

Die Feature-Checkliste für Ihr Postfix-Bounce-Parsing:

1. Überprüfen Sie, ob die VERP-Adresse gültig war. Sie möchten keine ungültigen Nachrichten analysieren.
2. Analysieren Sie den Körper und stellen Sie fest, ob es sich um eine weiche oder harte Ablehnung handelt.

Für die zweite Funktion können Sie einige allgemeine Ablehnungsnachrichten googeln. Das Beispiel ist diese bounce-regex-list.xml von Jakub Liska .

Esa Jokinen hat im folgenden Kommentar einen guten Punkt zu diesen beiden Sprungtypen gemacht. Wenn es Ihr Ziel ist, die Server-Reputation beizubehalten, sollte es ausreichen, den ersten Bounce-Typ zu verwenden. Beim zweiten Sprung ging es darum, Ihre Listen zu bereinigen. Daher sollten tote E-Mails gelöscht werden, um einige Ressourcen auf Ihrem Server freizugeben.

Einige Mailinglisten-Manager wie PHPlist und Mailman beschäftigen sich auch mit diesem Bounce-Problem beim Parsen des E-Mail-Körpers, da sie keine Ressourcen zum Parsen des Maillogs haben.