Mit der Zunahme der E-Mail-Nutzung in regulatorischen Umgebungen habe ich beschlossen, dass es Zeit ist, ein neues Projekt zu starten, das all dies mit Codebeispielen zusammenführt, wie man den E-Mail-Body und alle zugehörigen Daten speichert.
Vor etwa einem Jahr schrieb ich einen Blog darüber, wie man Kopien von E-Mails zur Archivierung und Ansicht abrufen kann, doch griff ich nicht auf die tatsächliche Speicherung der E-Mail oder der zugehörigen Daten zurück, und kürzlich schrieb ich einen Blog über die Speicherung aller Ereignisdaten (d. h. wann die E-Mail gesendet wurde, Öffnungen, Klicks, Bounces, Abmeldungen usw.) einer E-Mail zum Zwecke der Prüfung, entschied mich jedoch, keinen unterstützenden Code zu erstellen.
Mit dem Anstieg der E-Mail-Nutzung in regulierten Umgebungen habe ich entschieden, dass es Zeit ist, ein neues Projekt zu starten, das all dies mit Code-Beispielen zusammenführt, wie der E-Mail-Inhalt und alle zugehörigen Daten gespeichert werden können. Im nächsten Jahr werde ich weiterhin an diesem Projekt arbeiten, mit dem Ziel, eine funktionierende Speicher- und Anzeigeanwendung für archivierte E-Mails und alle Protokollinformationen, die von SparkPost erzeugt werden, zu erstellen. SparkPost verfügt über kein System, das den E-Mail-Inhalt archiviert, doch macht es den Aufbau einer Archivierungsplattform relativ einfach.
In dieser Blog-Serie werde ich den Prozess beschreiben, den ich durchlaufen habe, um den E-Mail-Inhalt auf S3 (Amazon’s Simple Storage Service) und alle relevanten Protokolldaten in MySQL zu speichern, um eine einfache Querverweisung zu ermöglichen. Für Produktionsarchivierungssysteme, die robuste Datenbanksicherungsstrategien erfordern, sollten Sie einen umfassenden PostgreSQL Backup- und Wiederherstellungsprozess implementieren, um sicherzustellen, dass Ihre Archivdaten ordnungsgemäß geschützt sind. Letztendlich ist dies der Ausgangspunkt für den Aufbau einer Anwendung, die eine einfache Suche nach archivierten E-Mails ermöglicht und diese E-Mails zusammen mit den Ereignisprotokolldaten anzeigt. Der Code für dieses Projekt ist im folgenden GitHub-Repository zu finden: https://github.com/jeff-goldstein/PHPArchivePlatform
Dieser erste Eintrag der Blog-Serie wird die Herausforderung beschreiben und eine Architektur für die Lösung entwickeln. Die restlichen Blogs werden Teile der Lösung zusammen mit Codebeispielen im Detail beschreiben.
Der erste Schritt in meinem Prozess war herauszufinden, wie ich eine Kopie der an den ursprünglichen Empfänger gesendeten E-Mail erhalten würde. Um eine Kopie des E-Mail-Inhalts zu erhalten, müssen Sie entweder:
Den E-Mail-Inhalt erfassen, bevor die E-Mail gesendet wird
Der E-Mail-Server speichert eine Kopie
Der E-Mail-Server erstellt eine Kopie für Sie zur Speicherung
Wenn der E-Mail-Server Elemente wie Link-Tracking oder Open-Tracking hinzufügt, können Sie #1 nicht verwenden, da es die Änderungen im Open-/Klick-Tracking nicht widerspiegeln wird.
Das bedeutet, dass entweder der Server die E-Mail speichern oder auf irgendeine Weise eine Kopie dieser E-Mail zur Speicherung anbieten muss. Da SparkPost keinen Speichermechanismus für E-Mail-Inhalte hat, aber eine Möglichkeit bietet, eine Kopie der E-Mail zu erstellen, lassen wir SparkPost eine Duplikat der E-Mail an uns senden, die wir in S3 speichern können.
Dies wird durch die Verwendung von SparkPost’s Archive-Funktion erreicht. SparkPost’s Archive-Funktion gibt dem Absender die Möglichkeit, SparkPost anzuweisen, eine Duplikat der E-Mail an eine oder mehrere E-Mail-Adressen zu senden und die gleichen Tracking- und Open-Links wie das Original zu verwenden. Die SparkPost-Dokumentation definiert ihre Archive-Funktion folgendermaßen:
Empfänger in der Archiver-Liste erhalten eine exakte Kopie der Nachricht, die an die RCPT TO-Adresse gesendet wurde. Insbesondere werden alle kodierten Links, die für den RCPT TO-Empfänger bestimmt sind, in den Archivnachrichten identisch sein
Die einzigen Unterschiede zur RCPT TO-E-Mail sind, dass einige der Header unterschiedlich sein werden, da die Zieladresse für die archivierende E-Mail unterschiedlich ist, aber der Inhalt der E-Mail wird eine exakte Kopie sein!
Wenn Sie eine tiefere Erklärung wünschen, hier ist ein Link zur SparkPost-Dokumentation über das Erstellen von Duplikat- (oder Archiv-)Kopien einer E-Mail.
Als Hinweis erlaubt SparkPost tatsächlich, E-Mails an cc-, bcc- und Archiv-E-Mail-Adressen zu senden. Für diese Lösung konzentrieren wir uns auf die Archiv-Adressen.
* Hinweis * Archivierte E-Mails können NUR beim Einspeisen von E-Mails in SparkPost über SMTP erstellt werden!
Jetzt, da wir wissen, wie man eine Kopie der Original-E-Mail erhält, müssen wir uns die Protokolldaten ansehen, die erzeugt werden, und einige der subtilen Nuancen innerhalb dieser Daten. SparkPost verfolgt alles, was auf seinen Servern passiert, und stellt Ihnen diese Informationen in Form von Nachrichtsereingnissen zur Verfügung. Diese Ereignisse werden 10 Tage lang auf SparkPost gespeichert und können über eine RESTful API namens message-events vom Server abgerufen werden, oder Sie können SparkPost anweisen, diese Ereignisse an eine beliebige Anzahl von Sammelanwendungen zu senden, die Sie wünschen. Der Push-Mechanismus erfolgt über Webhooks und erfolgt in Echtzeit.
Derzeit gibt es 14 verschiedene Ereignisse, die einer E-Mail passieren können. Hier ist eine Liste der aktuellen Ereignisse:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Folgen Sie diesem Link für eine aktuelle Referenzanleitung mit einer Beschreibung jedes Ereignisses sowie der Daten, die für jedes Ereignis freigegeben werden.
Jedes Ereignis hat zahlreiche Felder, die mit dem Ereignistyp übereinstimmen. Einige Felder wie die transmission_id sind in jedem Ereignis zu finden, aber andere Felder könnten spezifischer für das Ereignis sein; zum Beispiel, nur Open- und Klick-Ereignisse haben Geo-Tag-Informationen.
Ein sehr wichtiger Nachrichtsereignis-Eintrag für dieses Projekt ist die transmission_id. Alle Nachrichtsereignis-Einträge für die Original-E-Mail, archivierte E-Mail und alle cc und bcc Adressen werden die gleiche transmission_id teilen.
Es gibt auch einen gemeinsamen Eintrag namens message_id, der die gleiche ID für jeden Eintrag der Original- und Archiv-E-Mail hat. Alle cc oder bcc Adressen werden ihre eigene ID für den message_id Eintrag haben.
Bisher klingt das großartig und ehrlich gesagt ziemlich einfach, aber jetzt kommt der herausfordernde Teil. Denken Sie daran, um die Archiv-E-Mail zu erhalten, lassen wir SparkPost eine Duplikat der Original-E-Mail an eine andere E-Mail-Adresse senden, die einem Posteingang entspricht, auf den Sie Zugriff haben. Aber um diese Lösung zu automatisieren und den E-Mail-Inhalt zu speichern, werde ich eine andere Funktion von SparkPost verwenden, die Inbound Email Relaying heißt. Was das tut, ist, alle an eine bestimmte Domain gesendeten E-Mails zu nehmen und sie zu bearbeiten. Durch das Bearbeiten werden die E-Mails aufgeschlüsselt und es wird eine JSON-Struktur erstellt, die dann über ein Webhook an eine Anwendung geliefert wird. Siehe Anhang A für ein Beispiel-JSON.
Wenn Sie genau hinsehen, werden Sie feststellen, dass im JSON-Struktur vom eingehenden Relay ein sehr wichtiges Feld fehlt; die transmission_id. Während alle ausgehenden E-Mails die transmission_id mit dem gleichen Eintrag haben, die alle Daten der Original-E-Mail, des Archivs sowie cc und bcc Adressen verbindet; hat SparkPost keine Möglichkeit zu wissen, dass die E-Mail, die mit dem eingehenden Prozess erfasst wurde, mit einer der ausgehenden E-Mails verbunden ist. Der eingehende Prozess weiß einfach, dass eine E-Mail an eine bestimmte Domain gesendet wurde und um die E-Mail zu analysieren. Das ist es. Es behandelt jede an diese Domain gesendete E-Mail auf die gleiche Weise, sei es eine Antwort von einem Kunden oder die Archiv-E-Mail, die von SparkPost gesendet wurde.
Der Trick ist also; wie verbinden Sie die ausgehenden Daten mit dem eingehenden Prozess, der gerade die archivierte Version der E-Mail erfasst hat? Was ich beschlossen habe zu tun, ist, eine eindeutige ID im Textkörper der E-Mail zu verstecken. Wie das gemacht wird, liegt bei Ihnen, aber ich habe einfach ein Eingabefeld mit dem versteckten Tag aktiviert erstellt.
Ich habe dieses Feld auch in den Metadatenblock des X-MSYS-API-Headers hinzugefügt, der während der Einspeisung an SparkPost übergeben wird. Dieses versteckte UID wird letztendlich der Klebstoff für den gesamten Prozess sein und ist ein Hauptelement des Projekts und wird in den folgenden Blogposts ausführlich diskutiert.
Jetzt, wo wir das UID haben, das dieses Projekt zusammenfügen wird und verstehen, warum es notwendig ist, kann ich beginnen, die Vision des gesamten Projekts und die entsprechenden Blogeinträge zu entwickeln.
Erfassen und speichern der Archiv-E-Mail zusammen mit einem Datenbankeintrag zum Suchen/Indizieren
Alle Nachrichtsereignisdaten erfassen
Erstellen einer Anwendung zur Anzeige der E-Mail und aller zugehörigen Daten
Hier ist ein einfaches Diagramm des Projekts:
Das erste Code-Release wird den Archivprozess und das Speichern der E-Mail auf S3 abdecken, während die zweite Code-Veröffentlichung das Speichern aller Protokolldaten von Nachrichtsereignissen in MySQL abdecken wird. Sie können die ersten beiden Code-Veröffentlichungen und Blog-Beiträge irgendwann Anfang 2019 erwarten. Wenn Sie Fragen oder Anregungen haben, zögern Sie nicht, diese weiterzuleiten.
Viel Erfolg beim Senden.
– Jeff
Anhang A:
