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, aber ich ging nicht auf die eigentliche Speicherung der E-Mail oder der zugehörigen Daten ein. Kürzlich schrieb ich einen Blog darüber, wie man alle Ereignisdaten (d.h. wann die E-Mail gesendet, geöffnet, geklickt, gebounced, abgemeldet usw. wurde) bei einer E-Mail für Prüfungszwecke speichert, habe mich jedoch entschieden, keinen unterstützenden Code zu erstellen.
Mit der Zunahme der Nutzung von E-Mails in regulierten 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-Text und alle zugehörigen Daten speichert. Im kommenden Jahr werde ich dieses Projekt weiterentwickeln 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 zum Archivieren des E-Mail-Texts, aber es macht den Aufbau einer Archivierungsplattform relativ einfach.
In dieser Blog-Serie werde ich den Prozess beschreiben, den ich durchlaufen habe, um den E-Mail-Text auf S3 (Amazons Simple Store Service) und alle relevanten Protokolldaten in MySQL für einfache Querverweise zu speichern. Für Produktionsarchivierungssysteme, die robuste Datenbanksicherungsstrategien erfordern, ziehen Sie die Implementierung eines umfassenden PostgreSQL-Sicherungs- und Wiederherstellungsprozesses in Betracht, um Ihre Archivdaten ordnungsgemäß zu schützen. Letztendlich ist dies der Ausgangspunkt für den Aufbau einer Anwendung, die das einfache Suchen in archivierten E-Mails ermöglicht und diese E-Mails zusammen mit den Ereignisprotokolldaten anzeigt. Der Code für dieses Projekt kann im folgenden GitHub-Repository gefunden werden: PHPArchivePlatform auf GitHub
Dieser erste Eintrag der Blog-Serie wird die Herausforderung beschreiben und eine Architektur für die Lösung darlegen. Der Rest der Blogs wird Teile der Lösung zusammen mit Codebeispielen detailliert beschreiben.
Der erste Schritt in meinem Prozess bestand darin, herauszufinden, wie ich eine Kopie der an den ursprünglichen Empfänger gesendeten E-Mail erhalten kann. Um eine Kopie des E-Mail-Texts zu erhalten, müssen Sie entweder:
Den E-Mail-Text erfassen, bevor Sie die E-Mail senden
Den E-Mail-Server dazu bringen, eine Kopie zu speichern
Den E-Mail-Server dazu bringen, für Sie eine Kopie zur 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 würde.
Das bedeutet, dass entweder der Server die E-Mail speichern muss oder Ihnen irgendwie eine Kopie dieser E-Mail zur Speicherung zur Verfügung stellen muss. Da SparkPost keinen Speichermodus für E-Mail-Texte hat, aber eine Möglichkeit bietet, eine Kopie der E-Mail zu erstellen, werden wir SparkPost nutzen, um uns eine E-Mail-Duplikat zu senden, das wir in S3 speichern.
Dies geschieht durch die Nutzung der Archivierungsfunktion von SparkPost. Die Archivierungsfunktion von SparkPost gibt dem Absender die Möglichkeit, SparkPost anzuweisen, ein Duplikat 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 Archivierungsfunktion wie folgt:
Empfänger in der Archivliste erhalten eine exakte Kopie der Nachricht, die an die RCPT TO-Adresse gesendet wurde. Insbesondere werden alle codierten Links, die für den RCPT TO-Empfänger bestimmt sind, in den Archivnachrichten identisch sein.
Die einzigen Unterschiede zur RCPT TO-E-Mail bestehen darin, dass einige der Header unterschiedlich sind, da die Zieladresse für die Archivierungsmail anders ist, aber der Körper 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 Duplikaten (oder Archiv-) Kopien einer E-Mail.
Als Nebenbemerkung erlaubt Ihnen 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 erstellt werden, wenn E-Mails über SMTP in SparkPost eingespeist werden!
Jetzt, da wir wissen, wie wir eine Kopie der ursprünglichen E-Mail erhalten, müssen wir uns die Protokolldaten ansehen, die erzeugt werden, und einige der subtilen Nuancen in diesen Daten. SparkPost verfolgt alles, was auf seinen Servern passiert, und bietet Ihnen diese Informationen in Form von Nachrichtenereignissen 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 beliebige von Ihnen angegebene Sammelanwendungen zu senden. Der Push-Mechanismus erfolgt über Webhooks und wird in Echtzeit durchgeführt.
Derzeit gibt es 14 verschiedene Ereignisse, die bei einer E-Mail auftreten können. Hier ist eine Liste der aktuellen Ereignisse:
Abprallen
Klickverzögerung
Zustellung
Erzeugungsfehler
Erzeugungsablehnung
Erstmaliges Öffnen
InsertionLink Abmeldung
Listenabmeldung
Öffnen
Außerhalb des Bandes
RichtlinienablehnungSpam-Beschwerde
* Folgen Sie diesem Link für einen aktuellen Referenzleitfaden mit einer Beschreibung jedes Ereignisses zusammen mit den für jedes Ereignis gemeinsam genutzten Daten.
Jedes Ereignis hat zahlreiche Felder, die dem Ereignistyp entsprechen. Einige Felder wie die transmission_id sind in jedem Ereignis zu finden, aber andere Felder können spezifischer für ein bestimmtes Ereignis sein; zum Beispiel haben nur Öffnungs- und Klickereignisse Geo-Tag-Informationen.
Ein sehr wichtiger Nachrichtenereigniseintrag für dieses Projekt ist die transmission_id. Alle Nachrichtenereigniseinträge für die ursprüngliche E-Mail, archivierte E-Mail und jede CC- und BCC-Adresse werden die gleiche transmission_id gemeinsam haben.
Es gibt auch einen gemeinsamen Eintrag namens message_id die die gleiche ID für jeden Eintrag der ursprünglichen E-Mail und der archivierten E-Mail haben wird. Jede CC- oder BCC-Adresse wird für den message_id Eintrag ihre eigene ID haben.
Bis jetzt klingt das großartig und ehrlich gesagt ziemlich einfach, aber jetzt kommt der schwierige Teil. Denken Sie daran, um die Archiv-E-Mail zu erhalten, lassen wir SparkPost ein Duplikat der ursprünglichen E-Mail an eine andere E-Mail-Adresse senden, die mit einem Posteingang korrespondiert, auf den Sie Zugriff haben. Aber um diese Lösung zu automatisieren und den E-Mail-Text zu speichern, werde ich eine andere Funktion von SparkPost nutzen, die Inbound Email Relaying genannt wird. Was das macht, ist, dass alle an eine bestimmte Domain gesendeten E-Mails genommen und verarbeitet werden. Durch die Verarbeitung werden die E-Mails auseinandergerissen und eine JSON-Struktur erstellt, die dann über einen Webhook an eine Anwendung geliefert wird. Siehe Anhang A für eine Beispiel-JSON.
Wenn Sie genau hinsehen, werden Sie feststellen, dass in der JSON-Struktur des Inbound-Relays eines der sehr wichtigen Feld fehlt; die transmission_id. Während alle ausgehenden E-Mails die transmission_id mit dem gleichen Eintrag haben, der alle Daten von der ursprünglichen E-Mail, dem Archiv, CC- und BCC-Adressen verbindet; weiß SparkPost nicht, dass die von der Inbound-Verarbeitung erfasste E-Mail mit irgendeiner der ausgehenden E-Mails verbunden ist. Der Inbound-Prozess weiß einfach nur, dass eine E-Mail an eine bestimmte Domain gesendet wurde und die E-Mail analysiert werden soll. Das ist alles. Es wird jede an diese Domain gesendete E-Mail auf die gleiche Weise behandeln, sei es eine Antwort von einem Kunden oder die von SparkPost gesendete Archiv-E-Mail.
Der Trick besteht also darin; wie verbindet man die Ausgangsdaten mit dem Inbound-Prozess, der gerade die archivierte Version der Mail erfasst hat? Was ich beschlossen habe, ist eine einzigartige ID im Körper der E-Mail zu verstecken. Wie das gemacht wird, liegt bei Ihnen, aber ich habe einfach ein Eingabefeld mit dem versteckten Tag eingeschaltet erstellt.
Ich habe dieses Feld auch in den Metadatablock des X-MSYS-API-Headers hinzugefügt, der während der Eintragung an SparkPost übermittelt wird. Diese versteckte UID wird letztendlich der Kleber für das gesamte Verfahren sein und ist eine Hauptkomponente des Projekts, die in den folgenden Blogbeiträgen eingehend behandelt wird.
Jetzt, da wir die UID haben, die dieses Projekt zusammenhält und wir verstehen, warum es notwendig ist, kann ich beginnen, die Vision des gesamten Projekts und der entsprechenden Blog-Posts zu entwickeln.
Erfassen und Speichern der Archiv-E-Mail zusammen mit einem Datenbankeintrag zur Suche/Indexierung
Erfassung aller Nachrichtendaten
Erstellen einer Anwendung, um die E-Mail und alle zugehörigen Daten anzuzeigen
Hier ist ein einfaches Diagramm des Projekts:
Der erste Code-Drop wird den Archivierungsprozess und die Speicherung der E-Mail auf S3 abdecken, während der zweite Code-Drop die Speicherung aller Protokolldaten von Nachrichtenevents in MySQL abdecken wird. Sie können die ersten beiden Code-Drops und Blog-Einträge irgendwann Anfang 2019 erwarten. Wenn Sie Fragen oder Anregungen haben, können Sie diese gerne weiterleiten.
Viel Spaß beim Versenden.
– Jeff
Anhang A:
