Vor etwa einem Jahr habe ich einen Blog darüber geschrieben, wie man Kopien von E-Mails für Archivierungs- und Anzeigezwecke abrufen kann, aber ich habe das eigentliche Speichern der E-Mail oder verwandter Daten nicht angesprochen, und kürzlich habe ich einen Blog über das Speichern aller Ereignisdaten (d.h. wann die E-Mail gesendet wurde, Öffnungen, Klicks, Rückläufer, Abmeldungen usw.) zu einer E-Mail zu Prüfungszwecken geschrieben, 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 mit Codebeispielen zusammenführt, wie man den E-Mail-Inhalt und alle damit verbundenen Daten speichert. Im nächsten Jahr werde ich weiterhin an diesem Projekt arbeiten mit dem Ziel, eine funktionierende Speicher- und Sichtungsanwendung für archivierte E-Mails und alle von SparkPost erzeugten Protokollinformationen zu erstellen. SparkPost hat kein System, das den E-Mail-Inhalt archiviert, aber es macht den Aufbau einer Archivierungsplattform ziemlich einfach.
In dieser Blogreihe werde ich den Prozess beschreiben, den ich durchlaufen habe, um den E-Mail-Inhalt auf S3 (Amazons Simple Store Service) und alle relevanten Protokolldaten in MySQL für eine einfache Querverweisung zu speichern. 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 Ereignis-(Protokoll-)Daten anzeigt. Der Code für dieses Projekt kann im folgenden GitHub-Repository gefunden werden: https://github.com/jeff-goldstein/PHPArchivePlatform
Dieser erste Eintrag der Blogreihe wird die Herausforderung beschreiben und eine Architektur für die Lösung skizzieren. Die restlichen Blogs werden 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-Inhalts zu erhalten, müssen Sie entweder:
Den E-Mail-Inhalt vor dem Versand der E-Mail erfassen
Den E-Mail-Server veranlassen, eine Kopie zu speichern
Den E-Mail-Server veranlassen, eine Kopie für Sie zu erstellen
Wenn der E-Mail-Server Elemente wie Link-Tracking oder Öffnungs-Tracking hinzufügt, können Sie #1 nicht verwenden, da dies die Änderungen im offenen/klick Tracking nicht widerspiegelt.
Das bedeutet, dass entweder der Server die E-Mail speichern muss oder Ihnen irgendwie eine Kopie dieser E-Mail für die 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, werden wir SparkPost veranlassen, uns eine Duplikat der E-Mail zu senden, die wir in S3 speichern können.
Dies erfolgt über die Archivfunktion von SparkPost. Die Archivfunktion von SparkPost gibt dem Absender die Möglichkeit, SparkPost anzuweisen, eine Duplikat der E-Mail an eine oder mehrere E-Mail-Adressen zu senden und dieselben Tracking- und Öffenungslinks wie das Original zu verwenden. Die SparkPost-Dokumentation definiert ihre Archivfunktion wie folgt:
Empfänger in der Archivliste erhalten ein exactes Abbild 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 archivierte E-Mail anders ist, aber der Inhalt der E-Mail wird ein exaktes Abbild sein!
Wenn Sie eine tiefere Erklärung möchten, hier ist ein Link zur SparkPost-Dokumentation zum Erstellen von Duplikat- (oder Archiv-)Kopien einer E-Mail.
Als Nebenbemerkung ermöglicht es 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 Archivadressen.
* Hinweis * Archivierte E-Mails können NUR erstellt werden, wenn E-Mails über SMTP in SparkPost eingefügt 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 feinen Nuancen innerhalb dieser Daten. SparkPost verfolgt alles, was auf seinen Servern passiert, und bietet diese Informationen in Form von Nachrichtenereignissen an. Diese Ereignisse werden für 10 Tage auf SparkPost gespeichert und können über eine RESTful API mit dem Namen Nachrichtenereignisse vom Server abgerufen werden, oder Sie können SparkPost veranlassen, diese Ereignisse an jede Anzahl von Sammelanwendungen, die Sie wünschen, zu übertragen. Der Übertragungsmechanismus erfolgt über Webhooks und geschieht in Echtzeit.
Derzeit gibt es 14 verschiedene Ereignisse, die einer E-Mail passieren können. Hier ist eine Liste der aktuellen Ereignisse:
Rückläufer
Klickverzögerung
Lieferung
Generierungsfehler
Generierungsablehnung
Erster Öffner
InjectionLink Abmeldung
Liste Abmeldung
Öffnen
Außerband
RichtlinienablehnungSpam-Beschwerde
* Folgen Sie diesem Link, um auf einen aktuellen Referenzleitfaden für eine Beschreibung jedes Ereignisses sowie die Daten zuzugreifen, 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 zu finden, andere Felder können spezifischer für das Ereignis sein; beispielsweise haben nur Öffnungs- und Klickereignisse Geotag-Informationen.
Ein sehr wichtiger Nachrichteneintrag für dieses Projekt ist die transmission_id. Alle Nachrichteneinträge für die ursprüngliche E-Mail, die 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 für jeden Eintrag der ursprünglichen E-Mail und der archivierten E-Mail die gleiche ID haben wird. Jede cc- oder bcc-Adresse hat ihre eigene ID für den message_id Eintrag.
Bisher 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 eine Duplikat der ursprünglichen E-Mail an eine andere E-Mail-Adresse senden, die zu einem Posteingang gehört, auf den Sie Zugriff haben. Aber um diese Lösung zu automatisieren und den E-Mail-Inhalt zu speichern, werde ich eine weitere Funktion von SparkPost verwenden, die als Inbound Email Relaying bezeichnet wird. Was das bewirkt, ist, dass alle E-Mails, die an eine bestimmte Domain gesendet werden, verarbeitet werden. Durch die Verarbeitung 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 ganz genau hinsehen, werden Sie feststellen, dass die JSON-Struktur vom Inbound-Relay ein sehr wichtiges Feld vermisst; die transmission_id. Während alle ausgehenden E-Mails die transmission_id mit demselben Eintrag haben, der alle Daten der ursprünglichen E-Mail, der Archiv-E-Mail, der cc- und bcc-Adressen bindet; 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 um die E-Mail zu analysieren. Das ist es. Es wird jede E-Mail, die an diese Domain gesendet wird, gleich behandeln, sei es eine Antwort von einem Kunden oder die archivierte E-Mail, die von SparkPost gesendet wurde.
Also der Trick ist; 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 Inhalt der E-Mail zu verstecken. Wie das gemacht wird, bleibt Ihnen überlassen, aber ich habe einfach ein Eingabefeld mit dem versteckten Tag aktiviert.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Ich habe dieses Feld auch in den Metadatenblock des X-MSYS-API-Headers eingefügt, der während der Einspeisung an SparkPost übergeben wird. Diese versteckte UID wird das Bindeglied für den gesamten Prozess sein und ist ein Hauptbestandteil des Projekts, der in den folgenden Blogbeiträgen ausführlich behandelt wird.
Jetzt, da wir die UID haben, die dieses Projekt zusammenfügt und verstehen, warum sie notwendig ist, kann ich beginnen, die Vision des Gesamtprojekts und der entsprechenden Blogbeiträge zu entwickeln.
Erfassung und Speicherung der archivierten E-Mail zusammen mit einem Datenbankeintrag zur Suche/Indizierung
Erfassung aller Ereignisdaten
Eine Anwendung erstellen, um die E-Mail und alle entsprechenden Daten anzuzeigen
Hier ist ein einfaches Diagramm des Projekts:
Der erste Codeabschnitt wird den Archivprozess und das Speichern der E-Mail auf S3 abdecken, während der zweite Codeabschnitt das Speichern aller Protokolldaten von Nachrichtenereignissen in MySQL behandeln wird. Sie können die ersten beiden Codeabschnitte und Blogeinträge Anfang 2019 erwarten. Wenn Sie Fragen oder Vorschläge haben, zögern Sie bitte nicht, diese mitzuteilen.
Viel Spaß beim Senden.
– Jeff
Anhang A:
