Aufbau eines E-Mail-Archivierungssystems: Die Herausforderungen und natürlich die Lösung – Teil 1

Vor etwa einem Jahr habe ich einen Blog darüber geschrieben, wie man Kopien von E-Mails zur Archivierung und Ansicht abruft, aber ich habe nicht das tatsächliche Speichern der E-Mail oder verwandter Daten behandelt. 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 usw.) auf einer E-Mail speichert, um ein Audit durchzuführen, habe mich jedoch entschieden, keinen unterstützenden Code zu erstellen.

Mit der zunehmenden Nutzung von E-Mails 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-Text und alle zugehörigen Daten speichert. Im nächsten Jahr werde ich dieses Projekt weiter ausbauen mit dem Ziel, eine funktionierende Speicher- und Anwendungsanwendung für archivierte E-Mails und alle von SparkPost erzeugten Protokollinformationen zu erstellen. SparkPost hat kein System, das den E-Mail-Text archiviert, aber es erleichtert den Aufbau einer Archivierungsplattform erheblich.

In dieser Blog-Serie werde ich den Prozess beschreiben, den ich durchlaufen habe, um den E-Mail-Text auf S3 (Amazons Simple Store Service) zu speichern und alle relevanten Protokolldaten in MySQL für einfaches Cross-Referencing. Für Produktionsarchivierungssysteme, die robuste Datenbanksicherungsstrategien erfordern, sollten Sie die Implementierung eines umfassenden PostgreSQL-Sicherungs- und Wiederherstellungsprozesses in Betracht ziehen, 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, dann diese E-Mails zusammen mit den Ereignis-(Protokoll-)Daten anzeigt. Der Code für dieses Projekt ist im folgenden GitHub-Repository zu finden: PHPArchivePlatform auf GitHub

Dieser erste Eintrag der Blog-Serie wird die Herausforderung beschreiben und eine Architektur für die Lösung entwerfen. Die restlichen Blogs werden Teile der Lösung zusammen mit Codebeispielen detailliert erläutern.

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-Texts zu erhalten, müssen Sie entweder:

1. Den E-Mail-Text vor dem Versand der E-Mail erfassen

2. Den E-Mail-Server dazu bringen, eine Kopie zu speichern

3. Den E-Mail-Server dazu bringen, eine Kopie für Sie 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 widerspiegelt.

Das bedeutet, dass entweder der Server die E-Mail speichern oder Ihnen irgendwie eine Kopie dieser E-Mail zur Speicherung anbieten muss. Da SparkPost keinen Speichermodus für E-Mail-Texte hat, aber eine Möglichkeit, eine Kopie der E-Mail zu erstellen, lassen wir SparkPost uns ein Duplikat der E-Mail senden, das wir in S3 speichern können.

Dies erfolgt durch die Verwendung der Archivfunktion von SparkPost. Die Archivfunktion von SparkPost gibt dem Absender die Möglichkeit, SparkPost zu senden, um ein Duplikat der E-Mail an eine oder mehrere E-Mail-Adressen zu senden und die gleichen Tracking- und Öffnungslinks wie das Original zu verwenden. Die Dokumentation von SparkPost definiert ihre Archivfunktion wie folgt:

Empfänger auf der Archivliste erhalten eine exakte Kopie der Nachricht, die an die RCPT TO-Adresse gesendet wurde. Insbesondere sind alle kodierten Links, die für den RCPT TO-Empfänger bestimmt sind, in den Archivnachrichten identisch.

Einziger Unterschied zur RCPT TO-E-Mail ist, dass einige der Kopfzeilen unterschiedlich sind, da die Zieladresse für die Archiv-E-Mail eine andere ist, aber der E-Mail-Text wird eine exakte Kopie sein!

Wenn Sie eine ausführlichere Erklärung wünschen, finden Sie hier einen Link zur SparkPost-Dokumentation zur Erstellung 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 Sie E-Mails über SMTP in SparkPost injizieren!

Da wir jetzt 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 innerhalb dieser Daten. SparkPost verfolgt alles, was auf seinen Servern passiert, und bietet Ihnen diese Informationen in Form von Nachrichtenereignissen an. Diese Ereignisse werden 10 Tage lang auf SparkPost gespeichert und können über eine RESTful API namens Nachrichtenereignisse vom Server abgerufen werden, oder Sie können SparkPost veranlassen, diese Ereignisse an jede 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 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 einen aktuellen Referenzleitfaden für eine Beschreibung jedes Ereignisses sowie der Daten, die für jedes Ereignis geteilt werden.

Jedes Ereignis hat zahlreiche Felder, die zum Ereignistyp passen. Einige Felder wie das transmission_id befinden sich in jedem Ereignis, andere Felder können jedoch spezifischer für das Ereignis sein; zum Beispiel haben nur Open- und Click-Ereignisse Geotag-Informationen.

Ein sehr wichtiger Nachrichteneintrag in diesem Projekt ist das transmission_id. Alle Nachrichteneinträge für die ursprüngliche E-Mail, die archivierte E-Mail und alle cc und bcc Adressen teilen das gleiche transmission_id.

Es gibt auch einen gemeinsamen Eintrag namens message_id, der die gleiche ID für jeden Eintrag der ursprünglichen E-Mail und der archivierten E-Mail haben wird. Alle cc- oder bcc-Adressen werden ihre eigene ID für den message_id-Eintrag haben.

Bis jetzt klingt das großartig und ehrlich gesagt ziemlich einfach, aber jetzt wird es herausfordernd. 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 einem Postfach entspricht, auf das Sie Zugriff haben. Aber um diese Lösung zu automatisieren und den E-Mail-Text zu speichern, werde ich eine weitere Funktion von SparkPost namens Inbound Email Relaying verwenden. Was das tut, ist, alle an eine bestimmte Domain gesendeten E-Mails zu verarbeiten. Durch die Verarbeitung werden E-Mails aufgeschlüsselt 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 hinschauen, werden Sie bemerken, dass die JSON-Struktur der eingehenden Weiterleitung ein sehr wichtiges Feld nicht enthält; das transmission_id. Während alle ausgehenden E-Mails das transmission_id mit dem gleichen Eintrag haben, der alle Daten von der ursprünglichen E-Mail, Archiv, cc- und bcc-Adressen verbindet, hat SparkPost keine Möglichkeit zu wissen, dass die von der eingehenden Verarbeitung erfasste E-Mail mit einer der ausgehenden E-Mails verbunden ist. Der eingehende Prozess weiß einfach, dass eine E-Mail an eine bestimmte Domain gesendet wurde und diese E-Mail zu parsen ist. Das war's. Es wird jede E-Mail, die an diese Domain gesendet wird, auf die gleiche Weise behandeln, sei es eine Antwort von einem Kunden oder die von SparkPost gesendete Archiv-E-Mail.

Der Trick ist also; wie verbinden Sie die ausgehenden Daten mit dem eingehenden Prozess, der gerade die archivierte Version der E-Mail erhalten hat? Was ich beschlossen habe, ist, eine eindeutige ID im Körper der E-Mail zu verstecken. Wie das gemacht wird, bleibt Ihnen überlassen, aber ich habe einfach ein Eingabefeld mit dem versteckten Tag erstellt.

<input name="ArchiveCode" type="hidden" value="<<UID>>">

Ich habe dieses Feld auch in den Metadatabschnitt des X-MSYS-API-Headers hinzugefügt, der während der Injektion 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 Blogeinträ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 gesamten Projekts und der entsprechenden Blogeinträge zu entwickeln.

1. Erfassen und Speichern der Archiv-E-Mail zusammen mit einem Datenbankeintrag für die Suche/Indexierung

2. Erfassung aller Nachrichteneffektdaten

3. Erstellen einer Anwendung zur Ansicht der E-Mail und aller zugehörigen Daten

Hier ist ein einfaches Diagramm des Projekts:

Der erste Code-Drop wird den Archivprozess und das Speichern der E-Mail auf S3 behandeln, während der zweite Code-Drop das Speichern aller Protokolldaten von Nachrichtenereignissen in MySQL abdeckt. Sie können den ersten beiden Code-Drops und Blogeinträgen irgendwann Anfang 2019 erwarten. Wenn Sie Fragen oder Vorschläge haben, lassen Sie es mich bitte wissen.

Viel Spaß beim Verschicken.
– Jeff

Anhang A: