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 ungefähr einem Jahr habe ich einen Blog darüber geschrieben, wie man Kopien von E-Mails für Archivierung und Ansicht abruft, aber ich habe nicht darüber gesprochen, wie man die E-Mail oder die zugehörigen Daten tatsächlich speichert, und kürzlich habe ich einen Blog darüber geschrieben, wie man alle Ereignisdaten (d.h. wann die E-Mail gesendet wurde, Öffnungen, Klicks, Bounces, Abmeldungen etc.) bei einer E-Mail speichert, um sie zu überprüfen, habe mich jedoch entschieden, keinen unterstützenden Code zu erstellen.
Mit der Zunahme der E-Mail-Nutzung in regulierten Umgebungen habe ich beschlossen, dass es an der Zeit ist, ein neues Projekt zu starten, das all dies zusammenführt mit Codebeispielen, wie man den E-Mail-Textkörper und alle zugehörigen Daten speichert. Im Laufe des nächsten Jahres werde ich weiterhin an diesem Projekt arbeiten, mit dem Ziel, eine funktionierende Speicher- und Anzeigeanwendung für archivierte E-Mails und alle von SparkPost erzeugten Protokollinformationen zu erstellen. SparkPost hat kein System, das den E-Mail-Textkörper archiviert, aber es macht es relativ einfach, eine Archivierungsplattform zu erstellen.
In dieser Blog-Serie werde ich den Prozess beschreiben, den ich durchlaufen habe, um den E-Mail-Textkörper auf S3 (Amazons Simple Store Service) und alle relevanten Protokolldaten in MySQL zu speichern, um sie leicht zu vergleichen. Für Produktionsarchivierungssysteme, die robuste Datenbank-Backup-Strategien erfordern, sollten Sie die Implementierung eines umfassenden PostgreSQL-Backup- und Wiederherstellungsverfahrens in Betracht ziehen, um sicherzustellen, dass Ihre Archivierungsdaten ordnungsgemäß geschützt sind. Letztendlich ist dies der Ausgangspunkt für die Erstellung einer Anwendung, die eine einfache Suche nach archivierten E-Mails ermöglicht und diese E-Mails dann zusammen mit den Ereignisprotokolldaten anzeigt. Der Code für dieses Projekt kann im folgenden GitHub-Repository gefunden werden: https://github.com/jeff-goldstein/PHPArchivePlatform
Diesen ersten Eintrag der Blog-Serie wird die Herausforderung beschreiben und eine Architektur für die Lösung skizzieren. Der Rest der Blogs wird Teile der Lösung zusammen mit Codebeispielen detailliert beschreiben.
Der erste Schritt in meinem Prozess war herauszufinden, wie ich eine Kopie der E-Mail erhalten würde, die an den ursprünglichen Empfänger gesendet wurde. Um eine Kopie des E-Mail-Textkörpers zu erhalten, müssen Sie entweder:
Den E-Mail-Textkörper einfangen, bevor die E-Mail gesendet wird
Den E-Mail-Server eine Kopie speichern lassen
Den E-Mail-Server dazu bringen, eine Kopie für die Speicherung zu erstellen
Wenn der E-Mail-Server Elemente wie Link-Tracking oder Open-Tracking hinzufügt, können Sie #1 nicht verwenden, da es die Open/Click-Tracking-Änderungen nicht widerspiegeln wird.
Das bedeutet, dass entweder der Server die E-Mail speichern oder irgendwie eine Kopie dieser E-Mail zur Speicherung anbieten muss. Da SparkPost keinen Speichermechanismus für E-Mail-Textkörper hat, aber eine Möglichkeit bietet, eine Kopie der E-Mail zu erstellen, werden wir SparkPost dazu bringen, uns eine Kopie der E-Mail zu senden, die wir auf S3 speichern werden.
Dies geschieht durch die Verwendung der Archivfunktion von SparkPost. Die Archivfunktion von SparkPost gibt dem Absender die Möglichkeit, SparkPost anzuweisen, eine Kopie der E-Mail an eine oder mehrere E-Mail-Adressen zu senden und dieselben Tracking- und Open-Links wie das Original zu verwenden. Die SparkPost-Dokumentation definiert ihre Archivfunktion wie folgt:
Empfänger in der Archivliste 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 Textkörper der E-Mail wird eine exakte Kopie sein!
Wenn Sie eine ausführlichere Erklärung wünschen, hier ist ein Link zur SparkPost-Dokumentation zum Erstellen von doppelten (oder Archiv-)Kopien einer E-Mail.
Als Randbemerkung erlaubt SparkPost tatsächlich das Senden von E-Mails an CC, BCC und Archiv-E-Mail-Adressen. Für diese Lösung konzentrieren wir uns auf die Archiv-Adressen.
* Hinweis * Archivierte E-Mails können NUR erstellt werden, wenn E-Mails über SMTP in SparkPost eingespeist werden!
Da wir nun wissen, wie wir eine Kopie der ursprünglichen E-Mail erhalten können, 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 bietet Ihnen diese Informationen in Form von Nachrichtenereignissen an. Diese Ereignisse werden für 10 Tage auf SparkPost gespeichert und können über eine RESTful-API namens Nachrichtenereignisse vom Server abgerufen werden, oder Sie können SparkPost dazu bringen, diese Ereignissen an eine beliebige Anzahl von Sammelanwendungen zu senden, die Sie wünschen. Der Push-Mechanismus erfolgt über Webhooks und in Echtzeit.
Derzeit gibt es 14 verschiedene Ereignisse, die bei einer E-Mail auftreten 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 einen aktuellen Referenzleitfaden mit Beschreibung zu jedem Ereignis zusammen mit den Daten, die für jedes Ereignis geteilt werden.
Jedes Ereignis hat zahlreiche Felder, die dem Ereignistyp entsprechen. Einige Felder wie die transmission_id sind in jedem Ereignis vorhanden, aber andere Felder können ereignisspezifischer sein; zum Beispiel haben nur Open- und Click-Ereignisse Geotag-Informationen.
Ein sehr wichtiger Eintrag eines Nachrichtenereignisses für dieses Projekt ist die transmission_id. Alle Einträge des Nachrichtenereignisses für die ursprüngliche E-Mail, die archivierte E-Mail und jegliche cc und bcc-Adressen teilen die gleiche transmission_id.
Es gibt auch einen gemeinsamen Eintrag namens message_id , der für jeden Eintrag der ursprünglichen E-Mail und der archivierten E-Mail die gleiche ID haben wird. Jede CC oder BCC-Adresse wird ihre eigene ID für den message_id -Eintrag haben.
Bisher klingt das großartig und ehrlich gesagt ziemlich einfach, aber jetzt kommt der schwierige Teil. Denken Sie daran, um die Archivierungs-E-Mail zu erhalten, lassen wir SparkPost eine Kopie der ursprünglichen E-Mail an eine andere E-Mail-Adresse senden, die einem Postfach entspricht, auf das Sie Zugriff haben. Aber um diese Lösung zu automatisieren und den E-Mail-Textkörper zu speichern, werde ich eine weitere Funktion von SparkPost verwenden, die Inbound Email Relaying genannt wird. Was das macht, ist alle E-Mails, die an eine bestimmte Domain gesendet werden, zu nehmen und sie zu verarbeiten. Durch das Verarbeiten wird die E-Mail auseinandergerissen und eine JSON-Struktur erstellt, die dann über einen Webhook an eine Anwendung geliefert wird. Siehe Anhang A für ein Beispiel JSON.
Wenn Sie sehr genau hinsehen, werden Sie feststellen, dass in der JSON-Struktur des eingehenden Relais ein sehr wichtiges Feld fehlt; die transmission_id. Während alle ausgehenden E-Mails die transmission_id mit demselben Eintrag haben, der alle Daten von der ursprünglichen E-Mail, der Archiviert-, cc- und bcc-Adressen verbindet; hat SparkPost keine Möglichkeit zu wissen, dass die E-Mail, die durch den 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 analysiert die E-Mail. Und das war's. Es wird jede E-Mail, die an diese Domain gesendet wird, gleich behandeln, sei es eine Antwort von einem Kunden oder die Archivierungse-Mail, die von SparkPost gesendet wird.
Also lautet der Trick; wie verbindet man die ausgehenden Daten mit dem eingehenden Prozess, der gerade die archivierte Version der E-Mail erfasst hat? Was ich entschieden habe, ist, eine eindeutige ID im Textkörper der E-Mail zu verstecken. Wie das gemacht wird, liegt an Ihnen, aber ich habe einfach ein Eingabefeld mit dem versteckten Tag eingeschaltet erstellt.
Ich habe dieses Feld auch im Metadatenblock des X-MSYS-API-Headers hinzugefügt, der während der Einspeisung an SparkPost übergeben wird. Dieser versteckte UID wird das Bindeglied des gesamten Prozesses sein und ist ein Hauptbestandteil des Projektes, das in den folgenden Blogbeiträgen eingehend besprochen wird.
Nun, da wir die UID haben, die dieses Projekt zusammenhalten wird und wir verstehen, warum sie notwendig ist, kann ich beginnen, die Vision des gesamten Projekts und der entsprechenden Blogbeiträge zu entwickeln.
Erfassung und Speicherung der Archivierungs-E-Mail zusammen mit einem Datenbankeintrag zur Suche/Indexierung
Erfassung aller Ereignisdaten
Erstellung einer Anwendung, um die E-Mail und alle zugehörigen Daten anzuzeigen
Hier ist ein einfaches Diagramm des Projekts:
Der erste Code wird den Archivprozess abdecken und die E-Mail auf S3 speichern, während der zweite Code die Speicherung aller Protokolldaten von Nachrichtenereignissen in MySQL abdecken wird. Sie können die ersten beiden Code-Drops und Blogeinträge im frühen Jahr 2019 erwarten. Wenn Sie Fragen oder Anregungen haben, lassen Sie sie uns bitte zukommen.
Fröhliches Senden.
– Jeff
Anhang A:
