BounceHandling

Aus Melin DokuWiki

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

[bearbeiten] Bounce Mails (Rückläufer)

Neu: Die Bounce Management Troubleshooter Checkliste

[bearbeiten] Bounce Mails (Rückläufer)

Fast jedes Mailing erzeugt Rückläufer, sogennante Bounces: Unzustellbare Mails, Eingangsbestätigungen, Antworten der Leser, Abmeldemails - um nur einige zu nennen.

Melin unterscheidet dabei zwischen Hard- und Soft-Bounces:

  • Hard Bounces sind Mails die gar nicht erst ausgeliefert werden können, z.B. weil die Empfänger-Domain nicht existiert (Beispiel: joe@yaho.o). Mails an diese Art von Adressen verlassen das Melin-System gar nicht erst.
  • Die zweite Gruppe sind Soft-Bounces (Beispiel: joe@melin.de): Hier kann die Mail verschickt werden, diese kommt jedoch wieder zurück weil der Benutzer "joe" nicht bekannt ist. In diesem Fall spricht man von einer Soft-Bounce-Mail.

Für beide Fälle gibt es in Melin einen Workflow der jedoch an unterschiedlichen Stellen ansetzt:

  • Hard Bounces werden schon beim Versand erkannt und verlassen den Melin-Server nicht, da der SMTP-Server diese gar nicht annimmt. Bei jedem Fehlversuch wird in SITE-DIR/demon/smtperror eine XML-Datei generiert. Die dort liegenden Dateien werden anschließend von einem Workflow, z.B. M3 Hardbounce, eingelesen und verarbeitet.
  • Soft-Bounce werden zugestellt und kommen dann irgendwann wieder zurück. Damit Melin diese verarbeiten kann muß zuerst ein Bounce Mail Account über die Melin-Weboberfläche definiert werden - ein POP3- oder IMAP-Account - der von Melin regelmäßig abgerufen wird und auf dem die Rückläufer ankommen. Dieser Account wird von einem Application-Server-Prozess (Pop3 Retriever) alle fünf Minuten überprüft, sobald darin E-Mails vorhanden sind werden die Daten in die Tabelle BOUNCE_TEMP umkopiert. Zu diesem Zeitpunkt noch ohne Klassifizierung, diese wird durch einen Workflow hinzugefügt.

Der Pop3 Retriever-Prozess ist vom Workflow unabhängig, damit er immer aktiv ist, egal ob der Workflow aktiv ist oder nicht. Ziel ist, die Postfächer konstant zu leeren damit diese nicht überlaufen können und die Mails spätestens fünf Minuten nach eintreffen in der Datenbank zu haben damit sie über die Nutzeroberfläche eingesehen werden können.

Der Workflow M3 Softbounce liest diese aus der Datenbank ein und klassifiziert die Mail nach Inhalt. Durch die Klassifizierung wird die Bounce in die Tabelle BOUNCE_MAILS verschoben. Auf der Nutzeroberfläche erscheint sie in einer der vorkonfigurierten BounceMail-Ordner. Je nach Typ der Bounce-Mail wird der Benutzer falls erfoderlich gelöscht oder ein interner Mitarbeiter benachrichtigt.

Ablaufdiagramm des Bounce-Handling-Prozesses
Ablaufdiagramm des Bounce-Handling-Prozesses


[bearbeiten] Vorbereitung

Das Melin Bounce-Management benötigt mindestens eine E-Mail-Adresse die via POP3 oder IMAP abgerufen werden kann, unabhängig davon wie viele Absenderadressen verwendet werden.

In der Versandvorlage (CMS Template oder XML-Datei) müssen drei Felder festgelegt werden die für die Bounce-Bearbeitung relevant sind:

  • M_FROM ist die Absender-Emailadresse die der Empfänger sieht, an diese Adresse gehen manuelle Antworten wenn ein Empfänger antwortet. Diese Adresse muss natürlich existieren und entweder das Postfach einer realen Person sein oder auch ein von Melin überwachtes Postfach.
  • M_SENDER ist der Klartext-Name der als Absender angezeigt wird
  • M_ENVELOPE_FROM ist der sogenannte Return-Path (enspricht dem Feld "errors-to") oder eben "Envelope-From" - eine Adresse an die alle automatisch generierten Rückläufer gehen. Diese Adresse sollte in jedem Fall eine Melin-Bounce-Mail-Adresse sein. Wenn kein M_ENVELOPE_FROM angegeben ist, so wird die M_FROM-Adresse verwendet.

Bei der Adresse M_ENVELOPE_FROM gibt es zwei Varianten, die kleine Lösung bei der für alle Empfänger dieselbe Absenderadresse verwendet wird, und die große Lösung mit VERP, bei der in der Absenderadresse noch Zusatzinformationen codiert werden. Beide Varianten haben Vor- und Nachteile.

[bearbeiten] Mailserver Konfiguration

Melin unterscheidet zwischen Hardbounces und Softbounces. Der Mailserver (MTA) sollte so konfiguriert sein daß Mails an nicht existente Domains direkt abgelehnt werden. Damit kann Melin schon direkt beim Versand die defekten Adressen aussortieren und man muss nicht warten bis die ggf. nach einigen Tagen eventuell wieder aus dem Nirvana zurückkommen. Viele Mailserver sind schon so konfiguriert, beim Postfix zum Beispiel muss in die main.cf die Zeile

smtpd_recipient_restrictions = reject_unknown_recipient_domain,reject_unverified_recipient,permit_mynetworks,reject_unauth_destination

eingefügt werden. Über die Oberfläche verschickt man zum Test eine Vorschau-Email an eine nicht existente Domain, zum Beispiel seb@xxxmelin.de. Im Logfile erscheint dann:

[DMN 2010-02-14 14:46:57] [LBBW_M4UniversalMailing] [Send localhost    ] Debug Template dump written to................... temp/last_mailing.txt
[DMN 2010-02-14 14:46:57] [LBBW_M4UniversalMailing] [Send localhost    ] User seb@xxxmelin.de is not known in MMDB. Cannot get personal data!
[DMN 2010-02-14 14:46:57] [LBBW_M4UniversalMailing] [Send localhost    ] M_IS_MULTIPART flag is set.
[DMN 2010-02-14 14:46:58] [LBBW_M4UniversalMailing] [Send localhost    ] error (51-sending) javax.mail.SendFailedException: Invalid Addresses;   nested exception is: 	class com.sun.mail.smtp.SMTPAddressFailedException: 450 4.1.2 <seb@xxxmelin.de>: Recipient address rejected: Domain not found ! Sending seb@xxxmelin.de a 2. time...
[DMN 2010-02-14 14:46:58] [LBBW_M4UniversalMailing] [Send localhost    ] SMTP trouble notification (51b, Hardbounce) /var/kunden/lbbw/melin/msite/demon/smtperror/err1266155218099.xml for seb@xxxmelin.de
[DMN 2010-02-14 14:46:58] [LBBW_M4UniversalMailing] [Send localhost    ] snd email seb@xxxmelin.de fails!


[bearbeiten] VERP

VERP macht sich zu nutze daß POP3 und IMAP-Postfächer so codiert werden können daß sie alle Zeichen nach einem Plus ignorieren. So kommt zum Beispiel eine Mail an info@melin.de und info+test1234@melin.de im selben Postfach an. Dieses Feature ist weitgehend unbekannt, kann aber in allen gängigen POP3/IMAP-Servern aktiviert werden. Melin unterstützt VERP indem es Mailings mit individuellen M_ENVELOPE_FROM Absenderadressen erzeugen kann.

Das Versandplugin (MMDB Emailsender ) ist schon darauf vorbereitet die Absenderadresse zu dynamisieren, dabei werden folgende Platzhalter im Feld M_ENVELOPE_FROM ersetzt:

Platzhalter Bedeutung
MAILING_ID Die Mailing ID
NEWSLETTER_ID Die Verteilerliste / NEWSLETTER_ID
SYSTEM_CUSTOMER_ID Die ID des Empfängers (SYSTEM_CUSTOMER_ID)
CLIENT_ID Die CLIENT_ID dieses Mailings

Das Gegenstück ist ist das Bounce-Verarbeitungsplugin (MMDB BounceSorter) das diese Werte aus einer Bouncemail extrahieren kann. Damit das funktioniert stehen folgende Formate zur Verfügung:

Muster-Absenderadresse M_ENVELOPE_FROM
newsletter@melin.de newsletter@melin.de
newsletter+N4-ID2593574-C4r@melin.de newsletter+NNEWSLETTER_ID-IDSYSTEM_CUSTOMER_ID-CCLIENT_ID@melin.de
newsletter+N4-ID2593574-ML0011@melin.de newsletter+NNEWSLETTER_ID-IDSYSTEM_CUSTOMER_ID-MLMAILING_ID@melin.de
newsletter+N4-ID2593574-ML0011-C4@melin.de newsletter+NNEWSLETTER_ID-IDSYSTEM_CUSTOMER_ID-MLMAILING_ID-CCLIENT_ID@melin.de

Welche Variante man wählt hängt davon ab welche Ergebnisse man in den Statistiken haben möchte. Wenn die Bounces zu jedem einzelnen Mailing ausgewiesen werden müssen, so geht nur ein Format das die MAILING_ID enthält. Reicht es die Bounces auf der Oberfläche einem Verteiler zuzuordnen, so reichht eine Lösung die nur die NewsletterID und den Empfänger (in Form der SYSTEM_CUSTOMER_ID enthält.

Je konstanter die Absenderadresse ist, umso höher sind die Chancen beim Empfänger nie in einem Bulk/Spam-Ordner zu landen, andererseits reduziert sich dadurch die Möglichkeit der genaueren Auswertung. Die Empfehlung ist: wenn sich jemand damit konstant beschäftigt und die Zahlen in Melin beobachtet, dann kann man sie erheben, wenn absehbar ist daß sowiso niemand mit den Auswertungen arbeitet (im Sinne von Optimierung des Mailings), dann reicht ein einfacher Absender.

[bearbeiten] Bearbeiten von BounceMails

Die Bearbeitung von Soft-Bounce gliedert sich in zwei Teile:

  • Abrufen der BounceMail vom POP3-Server und umkopieren in die Datenbank
  • Bearbeiten durch den Workflow

[bearbeiten] Serverprozess zum Abrufen aktivieren

Der erste Schritt bei der BounceMail-Bearbeitung ist, daß die BounceMails abgerufen werden.

Die Funktionalität des BounceMails-Abrufens ist als Servlet im Tomcat Application Server enthalten und kann unter "Workflow" / "Serverprozesse" an- und ausgeschaltet werden. Bei einer Neuinstallation ist diese Funktion ausgeschaltet, zu Beginn sollte also überprüft werden ob der Abruf dort aktiviert ist.

Bei aktivierten BounceMail-Abrufen wird eine grüne Lampe dargestellt. Der obere Link verzweigt zur Liste der Bouncemail-Accounts, der untere zeigt das Logfile an
Bei aktivierten BounceMail-Abrufen wird eine grüne Lampe dargestellt. Der obere Link verzweigt zur Liste der Bouncemail-Accounts, der untere zeigt das Logfile an


Bei aktivierten BounceMail-Abrufen wird eine grüne Lampe dargestellt.

Zur Kontrolle werden Logfile-Ausgaben geschrieben. Liegen zur Zeit keine BounceMails vor, so wird alle fünf Minuten ein Statuseintrag geschrieben damit überprüft werden kann ob der Daemon aktiv ist.

  • Melin 3: Die Log-Datei kann im Menü "Workflow" / "Serverprozesse" / "BounceMail Listener" - "Serverlog überprüfen" eingesehen werden.
  • Melin 2: Die Ausgabe wird in TOMCAT/logs/catalina.out geschrieben
> 2006-01-02 22:39:59 POP3ListenerService: Startup complete.
> 2006-01-02 22:59:13 POP3ListenerService: Mail Subject is:  Juergen_Wegener_ist_nicht_im_Hause
> 2006-01-02 22:59:13 POP3ListenerService: Getting 32
> 2006-01-02 22:59:13 POP3ListenerService: Mail Subject is:  AW: Ihr BONUS Newsletter 02/2006
> 2006-01-02 22:59:13 POP3ListenerService: Getting 31

[bearbeiten] POP3-Account einrichten

Die POP3-Accounts werden im Menü "Bounce Mails" / "Bounce Accounts" definiert. Um einen neuen Eintrag hinzuzufügen klickt man auf den Button links unten.

Drei konfigurierte BounceAccounts. Ein Klick auf das grüne Icon links zeigt die eingegangenen BounceMails an. Ist das Icon noch orange, bedeutet dies daß noch keine BounceMails auf diesem Account verarbeitet wurden.
Drei konfigurierte BounceAccounts. Ein Klick auf das grüne Icon links zeigt die eingegangenen BounceMails an. Ist das Icon noch orange, bedeutet dies daß noch keine BounceMails auf diesem Account verarbeitet wurden.


Es werden nur BounceMails von aktivierten Accounts abgerufen, der erste Button der Dreiergruppe rechts muß daher auf "Aktiv" stehen (oberes Beispiel). Inaktive Einträge werden nicht abgerufen. Nach dem aktivieren eines Eintrags kann man durch einen Klick auf den Link "Logfile" überprüfen ob Fehler beim Abruf auftreten (ab Melin 3). Es können bis zu 5 Minuten vergehen bis neue Mails abgrufen werden und ein Fehler bemerkt wird.

[bearbeiten] Abrufkontrolle

Ist mindestens ein Bounce-Account eingerichtet und aktiv, so kann man im Menü "Warteschlangen" die Arbeitsweise kontrollieren.

Verbindungskontrolle
Verbindungskontrolle


Wenn Verbindungsfehler bestehehen, so werden diese unter "Warteschlange" angezeigt. Ist dort eine Zahl > 0 zu sehen, so befinden sich noch Mails im Postfach die nicht abgerufen wurden. Durch einen Klick auf die Zahl lassen sich die Mails anzeigen. DIe Liste in "Puffer" zeigt die Mails die bereits abgerufen wurden aber noch nicht einsortiert wurden.

[bearbeiten] Der Workflow

Zur leichteren Wartbarkeit empfiehlt es sich, die Bearbeitung von Soft- und Hardbounces in einem Workflow zusammenzufassen. Teil der Standardinstallation ist der Workflow TUTORIALBounceMail

BounceMail Workflow zur automatisierten Bearbeitung von Soft- und Hardbounces
BounceMail Workflow zur automatisierten Bearbeitung von Soft- und Hardbounces


  • HardBounces werden alle 30 Sekunden ausgelesen und verarbeitet.
  • Der Ordner für SoftBounces wird alle fünf Minuten überprüft und alle neuen XML-Dateien verarbeitet

im Logfile des Workflow-Daemons läßt sich der Fortgang beobachten wenn BounceMails eingehen:

2006-01-03 02:27:26 DEBUG root.FO.7   - [TUTORIALBounceMail] BounceSorter: AutoReply: VR IllerRothGünz: BONUS-Newsletter vom 23.12.2005
2006-01-03 02:27:26 DEBUG root.FO.7   - [TUTORIALBounceMail] BounceSorter: Vacation: Abwesenheitsnotiz: BONUS-Newsletter vom 23.12.2005
2006-01-03 02:27:26 DEBUG root.FO.7   - [TUTORIALBounceMail] BounceSorter: Undelivered: Undelivered Mail Returned to Sender
2006-01-03 02:27:26 DEBUG root.FO.7   - [TUTORIALBounceMail] BounceSorter: not_assigned - searching for trained equivalents (Bernhauser Bank eG - Rück-Antwort)
2006-01-03 02:27:26 DEBUG root.FO.7   - [TUTORIALBounceMail] BounceSorter: reassigned to 54301 (AutoReply) by training

Der BounceSorter gibt schon im Logfile an wie die Mail Klassifiziert wurde.

[bearbeiten] Zuordnung

Die meisten BounceMails erkennt der BounceSorter automatisch. Eingehende Mails bei denen die automatische Erkennung fehlschlägt werden in einen Ordner "Manuelle Zuordnung" gelegt.

Interface zur manuellen Zuordnung von Mails
Interface zur manuellen Zuordnung von Mails


Damit das System optimal arbeitet empfiehlt es sich, regelmäßig den Ordner "Manuelle Zuordnung" aufzurufen und die darin befindlichen Mails zuzuordnen. Dadurch wird der BounceSorter trainiert und kann Mails in Zukunft besser zuordnen. Zur vereinfachten Bearbeitung gibt es ab Melin 3 die Möglichkeit, nach einer manuellen Zuordnung die neue Trainingsregel direkt auf alle noch in "Manuelle Zuordnung" verblienenen Mails anzuwenden. Dadurch verringert sich die Zahl schneller auch schon für ältere Mails.

[bearbeiten] Erweitern und Ändern des Servlets

Der Code des Servlets zum Abrufen der BounceMails liegt im Verzeichnis DOC-ROOT/melin/WEB-INF/classes/services in der Datei POP3ListenerService.java Um dieses neu zu compilieren existriert ein fertiges UNIX-Script:

./servster.sh POP3ListenerService

Das Script befindet sich im Ordner DOC-ROOT/melin/WEB-INF/classes.

[bearbeiten] FAQ

[bearbeiten] Welche Datenbank wird verwendet um die BounceMails abzulegen?

Die Datenbank ergibt sich aus der MMDB-Definiton des Superusers SITE-DIR/demon/config/centraldb.xml

[bearbeiten] Wo werden Attachements abgelegt die an einer Mail anhängen?

Attachements liegen im Ordner SITE-DIR/services/attachement.

[bearbeiten] Wie sieht das XML einer BounceMail nach dem Abruf aus bevor diese vom Workflow erfasst wird?

SITE-DIR/services/bounces/XML-Datei

[bearbeiten] Die Klassifizierung erfolgt in Kategorien. Welche Kategorien gibt es?

Alle Bounce-Mails werden einer der folgenden Kategorien zugeordnet. Wird keine Zuordnung erkannt, erhält die Bounce-Mail den Code C04892 (Zuordnung Manuell Erforderlich). CRM-Systeme können die Bounce-Mails entweder direkt aus der Datenbank auslesen (Tabelle BOUNCE_MAILS oder über den Webservice darauf zugreifen. Wichtig für einen Abgleich sind nur die Kategorien die eine Aktion auslösen (z.B. Abmeldung oder manuelle Bearbeitung bei einer Anfrage zum Beispiel)

Code Bedeutung Löst Aktion aus
C55779 Abwesenheitsnachricht (automatische Antwort des Emfpfängers)
C14360 Abmeldung (Empfänger antwortet manuell auf den Newsletter und wünscht Abmeldung, ggf. Automatisch durch Abmeldebutton in Google und Hotmail) *
C12650 Account gesperrt (Adresse wird nach einiger Zeit deaktiviert wenn das Problem dauerhaft besteht)
C79351 Adresse Fehlerhaft (Adresse dauerhaft defekt) *
C10801 Unzustellbar (Adresse dauerhaft defekt) *
C19748 Spamfilter (Empfänger hat die Mail als Spam markiert)
C02428 Anfrage (manuelle Antwort des Emfpfängers) *
C18152 Beschwerden (manuelle Antwort des Emfpfängers) *
C52199 Bestellung (manuelle Antwort des Emfpfängers) *
C12292 AutoReply (Empfänger hat automatisch geantwortet, z.B. Eingangsbestätigung)
C04892 Zuordnung manuell (Bounce nicht erkannt)
C74497 Supportanfrage (manuelle Antwort des Emfpfängers) *
C13204 Mailbox voll (Adresse wird nach einiger Zeit deaktiviert wenn das Problem dauerhaft besteht)
C54301 Weitergeleitete Mail (Empfänger hat bei sich eine Weiterleitung konfiguriert die nicht funktioniert)
C94321 Unbekannter User (Adresse dauerhaft defekt) *
C95556 Änderungsmail (Emfpängeradresse hat sich geändert)
C16607 Testmails
C70393 Virusmail (Empfänger verschickt Viren an Adressen die auf dem Empfänger-PC gespeichert sind)

Die Kategorie HARDBOUNCE kann optional angelegt werden und sammelt ausschließlich Hardbounces.

[bearbeiten] Troubleshooter

  • Im Logfile steht nicht, auch im catalina.out steht nichts: Prüfen Sie die Datei DOC-ROOT/melin/WEB-INF/web.xml - wird der Context dort definiert wie folgt:
<listener>
 <listener-class>services.POP3ListenerService</listener-class>
</listener>
  • Es werden keine Mails abgerufen. Die Fehlermeldung für falsche Zugangsdaten sehen wie folgt aus:
> 2006-01-02 22:08:18 POP3ListenerService: POP3 CONN ERROR:javax.mail.AuthenticationFailedException: 
    Too few arguments for the pass command. 
> 2006-01-02 22:08:18                      Debug info   Name: mailservice.de
> 2006-01-02 22:08:18                      Debug info  Login: nl 
> 2006-01-02 22:08:18                      Debug info Server: mailservice.de
> 2006-01-02 22:08:18                      Debug info Client: 4

Prüfen Sie auf der Oberfläche unter "Bounce Mails" / "Warteschlange" ob hier eine korrekte Verbindung angezeigt wird oder ein Verbindunsproblem besteht.