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 habe ich einen Blog geschrieben, wie man Kopien von E-Mails für Archivierung und Anzeige abruft, aber ich habe die eigentliche Speicherung der E-Mail oder verwandter Daten nicht behandelt, und kürzlich habe ich einen Blog darüber geschrieben, wie man alle Event-Daten speichert (d.h. wann die E-Mail gesendet wurde, Öffnungen, Klicks, Bounces, Abmeldungen usw.) auf eine E-Mail zum Zweck der Prüfung, habe mich jedoch dafür entschieden, keinen unterstützenden Code zu erstellen.
Mit dem Anstieg der E-Mail-Nutzung in regulierten Umgebungen habe ich beschlossen, dass es an der Zeit ist, ein neues Projekt zu starten, das all dies mit Codebeispielen dafür verbindet, wie man den E-Mail-Body und alle zugehörigen Daten speichert. Im nächsten Jahr werde ich weiterhin an diesem Projekt arbeiten, um eine funktionierende Speicher- und Anzeigeanwendung für archivierte E-Mails und alle von SparkPost erzeugten Log-Informationen zu erstellen. SparkPost hat kein System zum Archivieren des E-Mail-Bodys, aber es macht den Aufbau einer Archivierungsplattform relativ einfach.
In dieser Blog-Reihe werde ich den Prozess beschreiben, den ich durchlaufen habe, um den E-Mail-Body auf S3 (Amazons Simple Store Service) und alle relevanten Log-Daten in MySQL für eine einfache Querverweise zu speichern. Letztendlich ist dies der Ausgangspunkt für den Aufbau einer Anwendung, die das einfache Durchsuchen archivierter E-Mails ermöglicht und dann diese E-Mails zusammen mit den Event- (Log-)Daten 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-Reihe wird die Herausforderung beschreiben und eine Architektur für die Lösung darlegen. Die restlichen Blogs werden einzelne Teile der Lösung zusammen mit Codebeispielen detailiert darlegen.
Der erste Schritt in meinem Prozess bestand darin, herauszufinden, wie ich eine Kopie der E-Mail erhalte, die an den ursprünglichen Empfänger gesendet wurde. Um eine Kopie des E-Mail-Bodys zu erhalten, müssen Sie entweder:
Den E-Mail-Body vor dem Senden der E-Mail erfassen
Den E-Mail-Server dazu bringen, eine Kopie zu speichern
Den E-Mail-Server dazu bringen, eine Kopie für Sie zu erstellen, die Sie speichern
Wenn der E-Mail-Server Dinge wie Link-Tracking oder Öffnungs-Tracking hinzufügt, können Sie #1 nicht verwenden, da es die Änderungen durch das Öffnen/Klicken-Tracking nicht widerspiegelt.
Das bedeutet, dass entweder der Server die E-Mail speichern muss oder Ihnen irgendwie eine Kopie dieser E-Mail zur Speicherung angeboten werden muss. Da SparkPost keinen Speichermechanismus für E-Mail-Bodys hat, aber eine Möglichkeit bietet, eine Kopie der E-Mail zu erstellen, werden wir SparkPost dazu bringen, uns ein Duplikat der E-Mail zu senden, das wir in S3 speichern.
Dies wird durch die Verwendung der Archivierungsfunktion von SparkPost erreicht. Die Archivierungsfunktion von SparkPost gibt dem Absender die Möglichkeit, SparkPost mitzuteilen, eine Kopie der E-Mail an eine oder mehrere E-Mail-Adressen zu senden und dieselben Tracking- und Öffnungs-Links wie das Original zu verwenden. Die Dokumentation von SparkPost definiert die Archivierungsfunktion folgendermaßen:
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
Der einzige Unterschied zur RCPT TO-E-Mail besteht darin, dass einige der Header unterschiedlich sein werden, da die Zieladresse für die archivierte E-Mail anders ist, aber der Body der E-Mail wird eine exakte Kopie sein!
Wenn Sie eine tiefere Erklärung wünschen, hier ist ein Link zur SparkPost-Dokumentation zur Erstellung von Duplikaten (oder Archiv-)Kopien einer E-Mail.
Als Nebenbemerkung: SparkPost ermöglicht es Ihnen tatsächlich, E-Mails an cc, bcc und Archiv-E-Mail-Adressen zu senden. Für diese Lösung konzentrieren wir uns auf die Archivadressen.
* 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 Original-E-Mail erhalten, müssen wir die Log-Daten betrachten, 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 Nachrichten-Ereignissen an. Diese Ereignisse werden 10 Tage lang auf SparkPost gespeichert und können über eine RESTful-API namens Nachrichten-Ereignisse vom Server abgerufen werden, oder Sie können SparkPost diese Ereignisse an eine beliebige Anzahl von Sammelanwendungen senden lassen, die Sie wünschen. Der Push-Mechanismus erfolgt in Echtzeit über Webhooks.
Derzeit gibt es 14 verschiedene Ereignisse, die mit 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 für eine Beschreibung jedes Ereignisses zusammen mit den Daten, die für jedes Ereignis geteilt werden.
Jedes Ereignis hat zahlreiche Felder, die mit dem Ereignistyp übereinstimmen. Einige Felder wie die transmission_id sind in jedem Ereignis enthalten, aber andere Felder können spezifischer für das Ereignis sein; zum Beispiel haben nur Öffnungs- und Klickereignisse Geotag-Informationen.
Ein sehr wichtiger Nachrichten-Ereignis-Eintrag für dieses Projekt ist die transmission_id. Alle Nachrichten-Ereignis-Einträge für die Original-E-Mail, die archivierte E-Mail und alle cc und bcc Adressen werden dieselbe transmission_id teilen.
Es gibt auch einen gemeinsamen Eintrag namens message_id, der dieselbe ID für jeden Eintrag der Original-E-Mail und der archivierten E-Mail haben wird. Alle cc oder bcc Adressen werden ihre eigene ID für die message_id-Eintrag haben.
Bis jetzt klingt das großartig und ehrlich gesagt ziemlich einfach, aber jetzt kommt der herausfordernde Teil. Denken Sie daran, um die archivierte E-Mail zu erhalten, lassen wir SparkPost ein 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-Body zu speichern, werde ich eine weitere Funktion von SparkPost nutzen, die Inbound Email Relaying genannt wird. Was das tut, ist, alle an eine bestimmte Domain gesendeten E-Mails zu nehmen und sie zu verarbeiten. Durch die Verarbeitung wird die E-Mail zerlegt 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 genau hinschauen, werden Sie feststellen, dass die JSON-Struktur des Inbound-Relay ein sehr wichtiges Feld fehlt; die transmission_id. Während alle ausgehenden E-Mails die transmission_id mit demselben Eintrag haben, das alle Daten der Original-E-Mail, Archive, cc und bcc Adressen verbindet; SparkPost hat keine Möglichkeit zu wissen, dass die von dem Inbound-Prozess erfasste E-Mail im Zusammenhang mit einer der ausgehenden E-Mails steht. Der Inbound-Prozess weiß einfach, dass eine E-Mail an eine bestimmte Domain gesendet wurde und die E-Mail zu parsen ist. Das ist alles. Es behandelt jede an diese Domain gesendete E-Mail auf die gleiche Weise, ob es sich um eine Antwort von einem Kunden oder die vom SparkPost gesendete Archiv-E-Mail handelt.
Der Trick ist also: wie verbinden Sie die ausgehenden Daten mit dem Inbound-Prozess, der gerade die archivierte Version der E-Mail erfasst hat? Was ich beschlossen habe zu tun, ist eine eindeutige ID im Body der E-Mail zu verstecken. Wie dies gemacht wird, bleibt Ihnen überlassen, aber ich habe einfach ein Eingabefeld mit der versteckten Tag aktiviert erstellt.
Ich habe dieses Feld auch in den Metadatenblock des X-MSYS-API-Headers eingefügt, der bei der Einspeisung an SparkPost übergeben wird. Diese versteckte UID wird am Ende der Klebstoff für den gesamten Prozess sein und ist ein Hauptbestandteil des Projekts und wird im Detail in den folgenden Blog-Posts behandelt.
Da wir nun die UID haben, die dieses Projekt zusammenhalten wird und verstehen, warum sie notwendig ist, kann ich beginnen, die Vision des gesamten Projekts und der entsprechenden Blog-Posts zu erstellen.
Erfassen und Speichern der archivierten E-Mail zusammen mit einem Datenbankeintrag zum Suchen/Indizieren
Alle Nachrichten-Ereignisdaten erfassen
Erstellen Sie eine Anwendung zum Anzeigen der E-Mail und aller zugehörigen Daten
Hier ist ein einfaches Diagramm des Projekts:
Der erste Code-Drop wird den Archivierungsprozess und das Speichern der E-Mail auf S3 abdecken, während der zweite Code-Drop das Speichern aller Log-Daten von Nachrichten-Ereignissen in MySQL behandelt. Sie können die ersten beiden Code-Drops und Blog-Einträge irgendwann Anfang 2019 erwarten. Wenn Sie Fragen oder Vorschläge haben, zögern Sie nicht, diese weiterzugeben.
Viel Spaß beim Senden.
– Jeff
Anhang A:
