Aufbau eines E-Mail-Archivierungssystems: Die Herausforderungen und natürlich die Lösung – Teil 1
Jeff Goldstein
04.02.2019
1 min read
Wichtige Erkenntnisse
E-Mail-Archivierung wird zunehmend für Regulierungs-, Compliance- und Prüfungsumgebungen unverzichtbar.
SparkPost speichert keine E-Mail-Inhalte, aber seine Archive-Funktion ermöglicht es Absendern, Duplikate von Nachrichten zu erhalten, die Tracking-Links und Inhalte widerspiegeln.
E-Mail-Inhalte können in Amazon S3 gespeichert werden, während Metadaten zu Nachrichtenereignissen in MySQL zur Abfrage und Kreuzreferenzierung gespeichert werden können.
SparkPost-Nachrichtenereignisse bieten umfassende Aktivitätsprotokolle (Bounces, Zustellungen, Klicks, Öffnungen, Abmeldungen, Beschwerden und mehr).
Archivkopien werden nur erzeugt, wenn E-Mails über SMTP versendet werden.
Nachrichtenereignisse für Original-, Archiv-, CC- und BCC-E-Mails teilen eine gemeinsame transmission_id.
Der Inbound Email Relay kann archivierte Nachrichten aufnehmen, enthält jedoch nicht die transmission_id, was eine Herausforderung für die Datenverknüpfung darstellt.
Durch Einbetten einer versteckten eindeutigen Kennung (UID) im Nachrichtentext wird diese Lücke geschlossen und eingehende Inhalte werden mit ausgehenden Protokollen verknüpft.
Die Kombination aus archivierten E-Mails + Nachrichtenereignissen ermöglicht den Aufbau eines durchsuchbaren, überprüfbaren Archivsystems.
Das Langzeitprojekt umfasst Code-Veröffentlichungen zur Speicherung von Archiv-E-Mails in S3 und zur Protokollierung von Ereignisdaten in MySQL.
Die endgültige Anwendung ermöglicht einfaches Suchen, Anzeigen und Abgleichen von E-Mail-Inhalten mit der gesamten zugehörigen Ereignisgeschichte.
Ideal für regulierungslastige Branchen, die vollständige Transparenz über jede versendete Nachricht benötigen.
Q&A Highlights
Warum ein eigenes Email-Archivierungssystem erstellen?
Regulierte Branchen erfordern oft eine langfristige Speicherung sowohl des E-Mail-Körpers als auch aller zugehörigen Ereignisprotokolle. SparkPost speichert keine Nachrichteninhalte, daher sorgt der Aufbau eines benutzerdefinierten Systems für Compliance, Prüfung und Sichtbarkeit.
Wie erhalten Sie eine exakte Kopie der originalen gesendeten E-Mail?
Das Archive feature von SparkPost sendet eine Kopie jeder ausgehenden E-Mail an festgelegte Archivadressen und bewahrt dabei alle kodierten Links und Verhaltensweisen zur Nachverfolgung.
Warum können Sie den Körper der E-Mail nicht erfassen, bevor Sie ihn senden?
Das Erfassen vor dem Senden beinhaltet nicht die Änderungen von SparkPost (Open Tracking, Click Tracking, Link Encoding). Die Verwendung von Archivkopien stellt sicher, dass Ihre gespeicherte Version genau dem entspricht, was die Empfänger erhalten.
Archiviert SparkPost E-Mails automatisch?
Nein. SparkPost speichert keine Nachrichteninhalte. Archivkopien müssen angefordert werden, indem Archivadressen während der SMTP-Injektion spezifiziert werden.
Was wird wo in diesem Archiving System gespeichert?
Email body → Amazon S3
Message event logs → MySQL
Diese Trennung unterstützt schnelle Suche, strukturierte Abfragen und kostengünstige Objektspeicherung.
Wie lange behält SparkPost Ereignisdaten?
SparkPost speichert Nachrichtenereignisse für 10 Tage. Danach müssen die Daten über Webhook erfasst oder abgefragt und an einem anderen Ort gespeichert werden.
Welche Nachrichtenereignisse sind verfügbar?
SparkPost stellt derzeit 14 Ereignisse bereit, einschließlich Zustellungen, Bounces, Klicks, Öffnungen, Ablehnungen, Richtlinienprobleme, Spam-Beschwerden, Abmeldungen und mehr.
Welche Identifikatoren verbinden alle Events miteinander?
Alle ausgehenden Nachrichten (Original, Archiv, CC, BCC) teilen dieselbe transmission_id. Die Original- und Archiv-Email teilen auch dieselbe message_id.
Warum ist die Inbound-Verarbeitung eine Herausforderung?
Der Inbound Email Relay von SparkPost wandelt eingehende E-Mails in JSON um, aber dieses JSON enthält nicht transmission_id. Ohne zusätzliche Daten kann die eingehende Kopie nicht mit ihrer ausgehenden Protokollhistorie verknüpft werden.
Wie verbinden Sie eingehende Archiv-E-Mails mit ausgehenden Nachrichtenereignissen?
Fügen Sie eine versteckte unique identifier (UID) in den E-Mail-Text ein und übergeben Sie dieselbe UID in den Metadaten. Diese UID wird zur gemeinsamen Referenz für eingehende und ausgehende Datensätze.
Wie hilft Inbound Email Relay, das Archivieren zu automatisieren?
Es empfängt Archiv-E-Mails, die an Ihre Archivdomäne gesendet werden, analysiert sie in strukturiertes JSON und sendet sie über einen Webhook an Ihre Anwendung—ermöglicht die automatisierte Extraktion und Speicherung.
Was ist die langfristige Vision des Projekts?
Eine vollständige Anwendung, die:
Archivierte E-Mails in S3 speichert
Alle Ereignisprotokolle in MySQL speichert
Benutzern ermöglicht, nach E-Mails zu suchen
Die Original-E-Mail und jedes zugehörige Ereignis in einer einheitlichen Oberfläche anzeigt
Vor ungefähr einem Jahr schrieb ich einen Blog darüber, wie man Kopien von E-Mails für Archivierung und Ansicht abruft, aber ich bin nicht auf die eigentliche Speicherung der E-Mail oder der zugehörigen Daten eingegangen. Kürzlich habe ich einen Blog darüber geschrieben, wie man alle Ereignisdaten speichert (d. h. wann die E-Mail gesendet wurde, Öffnungen, Klicks, Bounces, Abmeldungen usw.) für Prüfungszwecke, aber ich habe mich entschieden, keinen unterstützenden Code zu erstellen.
Mit der zunehmenden 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 Laufe des nächsten Jahres werde ich dieses Projekt weiter ausbauen mit dem Ziel, eine funktionierende Speicher- und Betrachtungsanwendung für archivierte E-Mails und alle von SparkPost erzeugten Protokollinformationen zu erstellen. SparkPost hat kein System, das den E-Mail-Body 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-Body auf S3 (Amazon's Simple Store Service) zu speichern und alle relevanten Logdaten in MySQL für eine einfache Querverweisung zu sichern. Für Produktionsarchivierungssysteme, die robuste Datenbank-Backup-Strategien erfordern, sollten Sie die Implementierung eines umfassenden PostgreSQL-Backup- und Wiederherstellungsprozesses in Erwägung ziehen, um sicherzustellen, dass Ihre Archivierungsdaten 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 und diese E-Mails zusammen mit den Ereignis-(Log-)Daten anzeigt. Der Code für dieses Projekt ist im folgenden GitHub-Repository zu finden: PHPArchivePlatform auf GitHub
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 war herauszufinden, wie ich eine Kopie der an den ursprünglichen Empfänger gesendeten E-Mail erhalten würde. Um eine Kopie der E-Mail zu erhalten, müssen Sie entweder:
Optionen zur Erfassung des E-Mail-Texts
Methode | Wer erstellt die Kopie | Spiegelt Nachverfolgungsänderungen | Automatisierungsfreundlich | In dieser Lösung verwendet |
|---|---|---|---|---|
Vor dem Senden erfassen | Anwendung | ❌ Nein | ✅ Ja | ❌ |
E-Mail-Server speichert Kopie | Mail-Server | ✅ Ja | ❌ Eingeschränkt | ❌ |
SparkPost Archivierungsfunktion | SparkPost | ✅ Ja | ✅ Ja | ✅ |
Erfassen Sie den E-Mail-Text vor dem Senden der E-Mail
Lassen Sie den E-Mail-Server eine Kopie speichern
Lassen Sie den E-Mail-Server eine Kopie für die Speicherung erstellen
Wenn der E-Mail-Server Elemente wie Link-Tracking oder Open-Tracking hinzufügt, können Sie #1 nicht verwenden, da es die Änderungen beim Open/Klick-Tracking nicht widerspiegelt.
Das bedeutet, dass entweder der Server die E-Mail speichern muss oder Ihnen irgendwie eine Kopie dieser E-Mail zur Speicherung anbieten 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 verwenden, um uns eine Duplikat der E-Mail zu senden, die wir in S3 speichern können.
Dies geschieht durch Verwendung der SparkPost-Archivierungsfunktion. Die SparkPost-Archivierungsfunktion 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 Open-Links wie das Original zu verwenden. Die SparkPost-Dokumentation definiert ihre Archivierungsfunktion folgendermaßen:
Empfänger in der Archivliste erhalten eine exakte Replik des bereits gesendeten Nachrichtentextes an die RCPT TO Adresse. Besonders, alle codierten Links für den RCPT TO Empfänger werden in den Archiven identisch sein.
Die einzigen Unterschiede zur RCPT TO-E-Mail bestehen darin, dass einige der Header abweichen, da die Zieladresse für die Archivierungsmail anders ist, aber der Text der E-Mail wird eine exakte Replik sein!
Wenn Sie eine detailliertere Erklärung wünschen, finden Sie hier einen Link zur SparkPost-Dokumentation über das Erstellen von Duplikaten (oder Archiv-) Kopien einer E-Mail.
Als Zusatzinformation erlaubt SparkPost 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 Archiv-Adressen.
* Hinweis * Archivierte E-Mails können NUR erstellt werden, wenn E-Mails per SMTP an SparkPost gesendet werden!
Jetzt, da wir wissen, wie wir eine Kopie der ursprünglichen E-Mail erhalten können, müssen wir uns die Logdaten ansehen, die erstellt werden und einige der subtilen Nuancen innerhalb dieser Daten. SparkPost verfolgt alles, was auf seinen Servern passiert und bietet diese Informationen in Form von Nachricht-Ereignissen an. Diese Ereignisse werden 10 Tage auf SparkPost aufbewahrt und können vom Server per RESTful API namens message-events abgerufen werden, oder Sie können SparkPost veranlassen, diese Ereignisse an eine beliebige Anzahl von Sammelanwendungen zu senden, die Sie wünschen. Der Push-Mechanismus erfolgt über Webhooks und erfolgt in Echtzeit.
Aktuell gibt es 14 verschiedene Ereignisse, die einer E-Mail passieren können. Hier ist eine Liste der aktuellen Ereignisse:
Bounce
ClickDelay
Zustellung
Generierungsfehler
Generierungsablehnung
Erstöffnung
InjectionLink Abmeldung
Listenabmeldung
Öffnen
Außerband
Policy AblehnungSpam Beschwerde
* Folgen Sie diesem Link für einen aktuellen Referenzleitfaden mit einer Beschreibung jedes Ereignisses zusammen mit den Daten, die für jedes Ereignis geteilt werden.
Jedes Ereignis hat zahlreiche Felder, die dem Ereignistyp entsprechen. Einige Felder wie das transmission_id werden in jedem Ereignis gefunden, aber andere Felder können spezifischer für das Ereignis sein; zum Beispiel haben nur Open- und Klick-Ereignisse Geotag-Informationen.
Identifikatoren, die im Archivierungssystem verwendet werden
Identifikator | Woher es stammt | Geteilt über | Zweck | Einschränkung |
|---|---|---|---|---|
transmission_id | SparkPost ausgehend | Original, Archiv, cc, bcc | Korreliert alle Nachricht-Ereignisse | Nicht verfügbar im Eingangsrelay |
message_id | SparkPost ausgehend | Original + Archiv | Identifiziert individuelle Nachrichten | Anders für cc/bcc |
Versteckter UID | Eingespeist vom Absender | Ausgehend + eingehend | Verknüpft archivierten E-Mail-Body mit Ereignissen | Muss benutzerdefiniert implementiert werden |
Ein sehr wichtiger Nachricht-Ereignis-Eintrag für dieses Projekt ist das transmission_id. Alle Nachricht-Ereignis-Einträge für die originale E-Mail, die archivierte E-Mail und alle cc und bcc Adressen teilen die gleiche transmission_id.
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 hat. Alle cc oder bcc Adressen werden ihre eigene ID für den message_id Eintrag haben.
Das sieht bisher großartig aus und ist ehrlich gesagt ziemlich einfach, aber jetzt kommt der herausfordernde Teil. Denken Sie daran, um die Archivierungs-E-Mail zu bekommen, haben wir SparkPost verwenden, um eine Duplikat der Original-E-Mail an eine andere E-Mail-Adresse zu senden, die einem von Ihnen zugänglichen Posteingang entspricht. Aber um diese Lösung zu automatisieren und den E-Mail-Body zu speichern, werde ich ein weiteres Feature von SparkPost verwenden, das Eingehende E-Mail-Weiterleitung heißt. Was das macht, ist, alle an eine bestimmte Domain gesendeten E-Mails zu verarbeiten. Indem sie verarbeitet werden, reißt es die E-Mail auseinander und erstellt eine JSON-Struktur, die dann über einen Webhook zu einer Anwendung geliefert wird. Siehe Anhang A für eine Beispiel-JSON.
Wenn Sie genau hinschauen, werden Sie feststellen, dass die JSON-Struktur von der eingehenden Weiterleitung ein sehr wichtiges Feld fehlt; das transmission_id. Während alle ausgehenden E-Mails das transmission_id mit demselben Eintrag haben, der alle Daten aus der Original-E-Mail, Archiv, 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ß nur, dass eine E-Mail an eine bestimmte Domain gesendet wurde und diese zu parsen ist. Das ist alles. Er behandelt jede an diese Domain gesendete E-Mail gleich, sei es eine Antwort eines 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 aufgenommen hat? Was ich beschlossen habe, ist, eine eindeutige ID im Text der E-Mail zu verstecken. Wie dies 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 Metadatenblock des X-MSYS-API-Headers eingefügt, der während der Einspeisung an SparkPost übergeben wird. Diese versteckte UID wird am Ende der Kleber 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 zusammenhält und verstehen, warum sie notwendig ist, kann ich beginnen, die Vision des gesamten Projekts und der entsprechenden Blogbeiträge zu erstellen.
Erfassen und Speichern der Archiv-E-Mail zusammen mit einem Datenbankeintrag für die Suche/Indizierung
Alle Nachricht-Ereignisdaten erfassen
Erstellen einer 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 Logdaten von Nachricht-Ereignissen in MySQL behandeln wird. Sie können die ersten beiden Code-Drops und Blog-Einträge irgendwann Anfang 2019 erwarten. Wenn Sie Fragen oder Anregungen haben, zögern Sie nicht, sie weiterzugeben.
Fröhliches Senden.
– Jeff
Anhang A:
Vor ungefähr einem Jahr schrieb ich einen Blog darüber, wie man Kopien von E-Mails für Archivierung und Ansicht abruft, aber ich bin nicht auf die eigentliche Speicherung der E-Mail oder der zugehörigen Daten eingegangen. Kürzlich habe ich einen Blog darüber geschrieben, wie man alle Ereignisdaten speichert (d. h. wann die E-Mail gesendet wurde, Öffnungen, Klicks, Bounces, Abmeldungen usw.) für Prüfungszwecke, aber ich habe mich entschieden, keinen unterstützenden Code zu erstellen.
Mit der zunehmenden 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 Laufe des nächsten Jahres werde ich dieses Projekt weiter ausbauen mit dem Ziel, eine funktionierende Speicher- und Betrachtungsanwendung für archivierte E-Mails und alle von SparkPost erzeugten Protokollinformationen zu erstellen. SparkPost hat kein System, das den E-Mail-Body 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-Body auf S3 (Amazon's Simple Store Service) zu speichern und alle relevanten Logdaten in MySQL für eine einfache Querverweisung zu sichern. Für Produktionsarchivierungssysteme, die robuste Datenbank-Backup-Strategien erfordern, sollten Sie die Implementierung eines umfassenden PostgreSQL-Backup- und Wiederherstellungsprozesses in Erwägung ziehen, um sicherzustellen, dass Ihre Archivierungsdaten 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 und diese E-Mails zusammen mit den Ereignis-(Log-)Daten anzeigt. Der Code für dieses Projekt ist im folgenden GitHub-Repository zu finden: PHPArchivePlatform auf GitHub
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 war herauszufinden, wie ich eine Kopie der an den ursprünglichen Empfänger gesendeten E-Mail erhalten würde. Um eine Kopie der E-Mail zu erhalten, müssen Sie entweder:
Optionen zur Erfassung des E-Mail-Texts
Methode | Wer erstellt die Kopie | Spiegelt Nachverfolgungsänderungen | Automatisierungsfreundlich | In dieser Lösung verwendet |
|---|---|---|---|---|
Vor dem Senden erfassen | Anwendung | ❌ Nein | ✅ Ja | ❌ |
E-Mail-Server speichert Kopie | Mail-Server | ✅ Ja | ❌ Eingeschränkt | ❌ |
SparkPost Archivierungsfunktion | SparkPost | ✅ Ja | ✅ Ja | ✅ |
Erfassen Sie den E-Mail-Text vor dem Senden der E-Mail
Lassen Sie den E-Mail-Server eine Kopie speichern
Lassen Sie den E-Mail-Server eine Kopie für die Speicherung erstellen
Wenn der E-Mail-Server Elemente wie Link-Tracking oder Open-Tracking hinzufügt, können Sie #1 nicht verwenden, da es die Änderungen beim Open/Klick-Tracking nicht widerspiegelt.
Das bedeutet, dass entweder der Server die E-Mail speichern muss oder Ihnen irgendwie eine Kopie dieser E-Mail zur Speicherung anbieten 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 verwenden, um uns eine Duplikat der E-Mail zu senden, die wir in S3 speichern können.
Dies geschieht durch Verwendung der SparkPost-Archivierungsfunktion. Die SparkPost-Archivierungsfunktion 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 Open-Links wie das Original zu verwenden. Die SparkPost-Dokumentation definiert ihre Archivierungsfunktion folgendermaßen:
Empfänger in der Archivliste erhalten eine exakte Replik des bereits gesendeten Nachrichtentextes an die RCPT TO Adresse. Besonders, alle codierten Links für den RCPT TO Empfänger werden in den Archiven identisch sein.
Die einzigen Unterschiede zur RCPT TO-E-Mail bestehen darin, dass einige der Header abweichen, da die Zieladresse für die Archivierungsmail anders ist, aber der Text der E-Mail wird eine exakte Replik sein!
Wenn Sie eine detailliertere Erklärung wünschen, finden Sie hier einen Link zur SparkPost-Dokumentation über das Erstellen von Duplikaten (oder Archiv-) Kopien einer E-Mail.
Als Zusatzinformation erlaubt SparkPost 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 Archiv-Adressen.
* Hinweis * Archivierte E-Mails können NUR erstellt werden, wenn E-Mails per SMTP an SparkPost gesendet werden!
Jetzt, da wir wissen, wie wir eine Kopie der ursprünglichen E-Mail erhalten können, müssen wir uns die Logdaten ansehen, die erstellt werden und einige der subtilen Nuancen innerhalb dieser Daten. SparkPost verfolgt alles, was auf seinen Servern passiert und bietet diese Informationen in Form von Nachricht-Ereignissen an. Diese Ereignisse werden 10 Tage auf SparkPost aufbewahrt und können vom Server per RESTful API namens message-events abgerufen werden, oder Sie können SparkPost veranlassen, diese Ereignisse an eine beliebige Anzahl von Sammelanwendungen zu senden, die Sie wünschen. Der Push-Mechanismus erfolgt über Webhooks und erfolgt in Echtzeit.
Aktuell gibt es 14 verschiedene Ereignisse, die einer E-Mail passieren können. Hier ist eine Liste der aktuellen Ereignisse:
Bounce
ClickDelay
Zustellung
Generierungsfehler
Generierungsablehnung
Erstöffnung
InjectionLink Abmeldung
Listenabmeldung
Öffnen
Außerband
Policy AblehnungSpam Beschwerde
* Folgen Sie diesem Link für einen aktuellen Referenzleitfaden mit einer Beschreibung jedes Ereignisses zusammen mit den Daten, die für jedes Ereignis geteilt werden.
Jedes Ereignis hat zahlreiche Felder, die dem Ereignistyp entsprechen. Einige Felder wie das transmission_id werden in jedem Ereignis gefunden, aber andere Felder können spezifischer für das Ereignis sein; zum Beispiel haben nur Open- und Klick-Ereignisse Geotag-Informationen.
Identifikatoren, die im Archivierungssystem verwendet werden
Identifikator | Woher es stammt | Geteilt über | Zweck | Einschränkung |
|---|---|---|---|---|
transmission_id | SparkPost ausgehend | Original, Archiv, cc, bcc | Korreliert alle Nachricht-Ereignisse | Nicht verfügbar im Eingangsrelay |
message_id | SparkPost ausgehend | Original + Archiv | Identifiziert individuelle Nachrichten | Anders für cc/bcc |
Versteckter UID | Eingespeist vom Absender | Ausgehend + eingehend | Verknüpft archivierten E-Mail-Body mit Ereignissen | Muss benutzerdefiniert implementiert werden |
Ein sehr wichtiger Nachricht-Ereignis-Eintrag für dieses Projekt ist das transmission_id. Alle Nachricht-Ereignis-Einträge für die originale E-Mail, die archivierte E-Mail und alle cc und bcc Adressen teilen die gleiche transmission_id.
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 hat. Alle cc oder bcc Adressen werden ihre eigene ID für den message_id Eintrag haben.
Das sieht bisher großartig aus und ist ehrlich gesagt ziemlich einfach, aber jetzt kommt der herausfordernde Teil. Denken Sie daran, um die Archivierungs-E-Mail zu bekommen, haben wir SparkPost verwenden, um eine Duplikat der Original-E-Mail an eine andere E-Mail-Adresse zu senden, die einem von Ihnen zugänglichen Posteingang entspricht. Aber um diese Lösung zu automatisieren und den E-Mail-Body zu speichern, werde ich ein weiteres Feature von SparkPost verwenden, das Eingehende E-Mail-Weiterleitung heißt. Was das macht, ist, alle an eine bestimmte Domain gesendeten E-Mails zu verarbeiten. Indem sie verarbeitet werden, reißt es die E-Mail auseinander und erstellt eine JSON-Struktur, die dann über einen Webhook zu einer Anwendung geliefert wird. Siehe Anhang A für eine Beispiel-JSON.
Wenn Sie genau hinschauen, werden Sie feststellen, dass die JSON-Struktur von der eingehenden Weiterleitung ein sehr wichtiges Feld fehlt; das transmission_id. Während alle ausgehenden E-Mails das transmission_id mit demselben Eintrag haben, der alle Daten aus der Original-E-Mail, Archiv, 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ß nur, dass eine E-Mail an eine bestimmte Domain gesendet wurde und diese zu parsen ist. Das ist alles. Er behandelt jede an diese Domain gesendete E-Mail gleich, sei es eine Antwort eines 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 aufgenommen hat? Was ich beschlossen habe, ist, eine eindeutige ID im Text der E-Mail zu verstecken. Wie dies 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 Metadatenblock des X-MSYS-API-Headers eingefügt, der während der Einspeisung an SparkPost übergeben wird. Diese versteckte UID wird am Ende der Kleber 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 zusammenhält und verstehen, warum sie notwendig ist, kann ich beginnen, die Vision des gesamten Projekts und der entsprechenden Blogbeiträge zu erstellen.
Erfassen und Speichern der Archiv-E-Mail zusammen mit einem Datenbankeintrag für die Suche/Indizierung
Alle Nachricht-Ereignisdaten erfassen
Erstellen einer 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 Logdaten von Nachricht-Ereignissen in MySQL behandeln wird. Sie können die ersten beiden Code-Drops und Blog-Einträge irgendwann Anfang 2019 erwarten. Wenn Sie Fragen oder Anregungen haben, zögern Sie nicht, sie weiterzugeben.
Fröhliches Senden.
– Jeff
Anhang A:
Vor ungefähr einem Jahr schrieb ich einen Blog darüber, wie man Kopien von E-Mails für Archivierung und Ansicht abruft, aber ich bin nicht auf die eigentliche Speicherung der E-Mail oder der zugehörigen Daten eingegangen. Kürzlich habe ich einen Blog darüber geschrieben, wie man alle Ereignisdaten speichert (d. h. wann die E-Mail gesendet wurde, Öffnungen, Klicks, Bounces, Abmeldungen usw.) für Prüfungszwecke, aber ich habe mich entschieden, keinen unterstützenden Code zu erstellen.
Mit der zunehmenden 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 Laufe des nächsten Jahres werde ich dieses Projekt weiter ausbauen mit dem Ziel, eine funktionierende Speicher- und Betrachtungsanwendung für archivierte E-Mails und alle von SparkPost erzeugten Protokollinformationen zu erstellen. SparkPost hat kein System, das den E-Mail-Body 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-Body auf S3 (Amazon's Simple Store Service) zu speichern und alle relevanten Logdaten in MySQL für eine einfache Querverweisung zu sichern. Für Produktionsarchivierungssysteme, die robuste Datenbank-Backup-Strategien erfordern, sollten Sie die Implementierung eines umfassenden PostgreSQL-Backup- und Wiederherstellungsprozesses in Erwägung ziehen, um sicherzustellen, dass Ihre Archivierungsdaten 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 und diese E-Mails zusammen mit den Ereignis-(Log-)Daten anzeigt. Der Code für dieses Projekt ist im folgenden GitHub-Repository zu finden: PHPArchivePlatform auf GitHub
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 war herauszufinden, wie ich eine Kopie der an den ursprünglichen Empfänger gesendeten E-Mail erhalten würde. Um eine Kopie der E-Mail zu erhalten, müssen Sie entweder:
Optionen zur Erfassung des E-Mail-Texts
Methode | Wer erstellt die Kopie | Spiegelt Nachverfolgungsänderungen | Automatisierungsfreundlich | In dieser Lösung verwendet |
|---|---|---|---|---|
Vor dem Senden erfassen | Anwendung | ❌ Nein | ✅ Ja | ❌ |
E-Mail-Server speichert Kopie | Mail-Server | ✅ Ja | ❌ Eingeschränkt | ❌ |
SparkPost Archivierungsfunktion | SparkPost | ✅ Ja | ✅ Ja | ✅ |
Erfassen Sie den E-Mail-Text vor dem Senden der E-Mail
Lassen Sie den E-Mail-Server eine Kopie speichern
Lassen Sie den E-Mail-Server eine Kopie für die Speicherung erstellen
Wenn der E-Mail-Server Elemente wie Link-Tracking oder Open-Tracking hinzufügt, können Sie #1 nicht verwenden, da es die Änderungen beim Open/Klick-Tracking nicht widerspiegelt.
Das bedeutet, dass entweder der Server die E-Mail speichern muss oder Ihnen irgendwie eine Kopie dieser E-Mail zur Speicherung anbieten 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 verwenden, um uns eine Duplikat der E-Mail zu senden, die wir in S3 speichern können.
Dies geschieht durch Verwendung der SparkPost-Archivierungsfunktion. Die SparkPost-Archivierungsfunktion 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 Open-Links wie das Original zu verwenden. Die SparkPost-Dokumentation definiert ihre Archivierungsfunktion folgendermaßen:
Empfänger in der Archivliste erhalten eine exakte Replik des bereits gesendeten Nachrichtentextes an die RCPT TO Adresse. Besonders, alle codierten Links für den RCPT TO Empfänger werden in den Archiven identisch sein.
Die einzigen Unterschiede zur RCPT TO-E-Mail bestehen darin, dass einige der Header abweichen, da die Zieladresse für die Archivierungsmail anders ist, aber der Text der E-Mail wird eine exakte Replik sein!
Wenn Sie eine detailliertere Erklärung wünschen, finden Sie hier einen Link zur SparkPost-Dokumentation über das Erstellen von Duplikaten (oder Archiv-) Kopien einer E-Mail.
Als Zusatzinformation erlaubt SparkPost 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 Archiv-Adressen.
* Hinweis * Archivierte E-Mails können NUR erstellt werden, wenn E-Mails per SMTP an SparkPost gesendet werden!
Jetzt, da wir wissen, wie wir eine Kopie der ursprünglichen E-Mail erhalten können, müssen wir uns die Logdaten ansehen, die erstellt werden und einige der subtilen Nuancen innerhalb dieser Daten. SparkPost verfolgt alles, was auf seinen Servern passiert und bietet diese Informationen in Form von Nachricht-Ereignissen an. Diese Ereignisse werden 10 Tage auf SparkPost aufbewahrt und können vom Server per RESTful API namens message-events abgerufen werden, oder Sie können SparkPost veranlassen, diese Ereignisse an eine beliebige Anzahl von Sammelanwendungen zu senden, die Sie wünschen. Der Push-Mechanismus erfolgt über Webhooks und erfolgt in Echtzeit.
Aktuell gibt es 14 verschiedene Ereignisse, die einer E-Mail passieren können. Hier ist eine Liste der aktuellen Ereignisse:
Bounce
ClickDelay
Zustellung
Generierungsfehler
Generierungsablehnung
Erstöffnung
InjectionLink Abmeldung
Listenabmeldung
Öffnen
Außerband
Policy AblehnungSpam Beschwerde
* Folgen Sie diesem Link für einen aktuellen Referenzleitfaden mit einer Beschreibung jedes Ereignisses zusammen mit den Daten, die für jedes Ereignis geteilt werden.
Jedes Ereignis hat zahlreiche Felder, die dem Ereignistyp entsprechen. Einige Felder wie das transmission_id werden in jedem Ereignis gefunden, aber andere Felder können spezifischer für das Ereignis sein; zum Beispiel haben nur Open- und Klick-Ereignisse Geotag-Informationen.
Identifikatoren, die im Archivierungssystem verwendet werden
Identifikator | Woher es stammt | Geteilt über | Zweck | Einschränkung |
|---|---|---|---|---|
transmission_id | SparkPost ausgehend | Original, Archiv, cc, bcc | Korreliert alle Nachricht-Ereignisse | Nicht verfügbar im Eingangsrelay |
message_id | SparkPost ausgehend | Original + Archiv | Identifiziert individuelle Nachrichten | Anders für cc/bcc |
Versteckter UID | Eingespeist vom Absender | Ausgehend + eingehend | Verknüpft archivierten E-Mail-Body mit Ereignissen | Muss benutzerdefiniert implementiert werden |
Ein sehr wichtiger Nachricht-Ereignis-Eintrag für dieses Projekt ist das transmission_id. Alle Nachricht-Ereignis-Einträge für die originale E-Mail, die archivierte E-Mail und alle cc und bcc Adressen teilen die gleiche transmission_id.
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 hat. Alle cc oder bcc Adressen werden ihre eigene ID für den message_id Eintrag haben.
Das sieht bisher großartig aus und ist ehrlich gesagt ziemlich einfach, aber jetzt kommt der herausfordernde Teil. Denken Sie daran, um die Archivierungs-E-Mail zu bekommen, haben wir SparkPost verwenden, um eine Duplikat der Original-E-Mail an eine andere E-Mail-Adresse zu senden, die einem von Ihnen zugänglichen Posteingang entspricht. Aber um diese Lösung zu automatisieren und den E-Mail-Body zu speichern, werde ich ein weiteres Feature von SparkPost verwenden, das Eingehende E-Mail-Weiterleitung heißt. Was das macht, ist, alle an eine bestimmte Domain gesendeten E-Mails zu verarbeiten. Indem sie verarbeitet werden, reißt es die E-Mail auseinander und erstellt eine JSON-Struktur, die dann über einen Webhook zu einer Anwendung geliefert wird. Siehe Anhang A für eine Beispiel-JSON.
Wenn Sie genau hinschauen, werden Sie feststellen, dass die JSON-Struktur von der eingehenden Weiterleitung ein sehr wichtiges Feld fehlt; das transmission_id. Während alle ausgehenden E-Mails das transmission_id mit demselben Eintrag haben, der alle Daten aus der Original-E-Mail, Archiv, 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ß nur, dass eine E-Mail an eine bestimmte Domain gesendet wurde und diese zu parsen ist. Das ist alles. Er behandelt jede an diese Domain gesendete E-Mail gleich, sei es eine Antwort eines 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 aufgenommen hat? Was ich beschlossen habe, ist, eine eindeutige ID im Text der E-Mail zu verstecken. Wie dies 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 Metadatenblock des X-MSYS-API-Headers eingefügt, der während der Einspeisung an SparkPost übergeben wird. Diese versteckte UID wird am Ende der Kleber 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 zusammenhält und verstehen, warum sie notwendig ist, kann ich beginnen, die Vision des gesamten Projekts und der entsprechenden Blogbeiträge zu erstellen.
Erfassen und Speichern der Archiv-E-Mail zusammen mit einem Datenbankeintrag für die Suche/Indizierung
Alle Nachricht-Ereignisdaten erfassen
Erstellen einer 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 Logdaten von Nachricht-Ereignissen in MySQL behandeln wird. Sie können die ersten beiden Code-Drops und Blog-Einträge irgendwann Anfang 2019 erwarten. Wenn Sie Fragen oder Anregungen haben, zögern Sie nicht, sie weiterzugeben.
Fröhliches Senden.
– Jeff
Anhang A:
