Costruire un sistema di archiviazione delle email: le sfide e ovviamente la soluzione - Parte 1
Jeff Goldstein
4 feb 2019
1 min read
Punti Chiave
L'archiviazione delle email è sempre più essenziale per ambienti normativi, di conformità e di auditing.
SparkPost non memorizza i corpi delle email, ma la sua funzione di archiviazione consente ai mittenti di ricevere messaggi duplicati che rispecchiano i link di tracciamento e il contenuto.
I corpi delle email possono essere archiviati in Amazon S3, mentre i metadati degli eventi dei messaggi possono essere archiviati in MySQL per interrogazioni e riferimenti incrociati.
Gli eventi dei messaggi di SparkPost forniscono registri di attività dettagliati (rimbalzi, consegne, clic, aperture, disiscrizioni, reclami e altro).
Copie di archiviazione vengono generate solo quando si invia tramite SMTP.
Gli eventi dei messaggi per email originali, archiviate, CC e BCC condividono un transmission_id comune.
Il Relay Email Inbound può acquisire messaggi archiviati ma non include il transmission_id, creando una sfida di collegamento dei dati.
Incorporare un identificatore unico nascosto (UID) nel corpo del messaggio colma questa lacuna e collega il contenuto in entrata ai registri in uscita.
Combinare email archiviate + eventi dei messaggi consente di creare un sistema di archiviazione ricercabile e auditabile.
Il progetto a lungo termine include rilasci di codice per archiviare email in S3 e registrare i dati degli eventi in MySQL.
La versione finale dell'applicazione permetterà una ricerca, una visualizzazione e una riconciliazione facili del contenuto delle email con tutta la storia degli eventi correlati.
Ideale per settori con elevati requisiti di conformità che necessitano di una visibilità completa su ogni messaggio inviato.
Punti salienti del Q&A
Perché costruire un sistema di archiviazione delle email autonomo?
Le industrie regolamentate richiedono spesso lo stoccaggio a lungo termine sia del corpo dell'email che di tutti i log degli eventi associati. SparkPost non memorizza i corpi dei messaggi, quindi costruire un sistema personalizzato garantisce conformità, audit e visibilità.
Come si ottiene una copia esatta dell'email originale inviata?
La funzione Archivia di SparkPost invia una copia di ogni email in uscita agli indirizzi di archiviazione designati, preservando tutti i link codificati e i comportamenti di tracciamento.
Perché non puoi catturare il corpo dell'email prima di inviarlo?
La cattura pre-invio non include le modifiche di SparkPost (tracciamento delle aperture, tracciamento dei clic, codifica dei collegamenti). L'utilizzo delle copie di Archivio garantisce che la tua versione salvata corrisponda esattamente a ciò che i destinatari ricevono.
SparkPost archivia automaticamente le email?
No. SparkPost non memorizza i corpi dei messaggi. Le copie di archivio devono essere richieste specificando gli indirizzi di archivio durante l'iniezione SMTP.
Cosa è conservato dove in questo sistema di archiviazione?
Corpo dell'email → Amazon S3
Log degli eventi dei messaggi → MySQL
Questa separazione supporta la ricerca veloce, query strutturate e un'archiviazione degli oggetti economica.
Per quanto tempo SparkPost conserva i dati sugli eventi?
SparkPost memorizza gli eventi dei messaggi per 10 giorni. Dopo di che, i dati devono essere incorporati tramite webhook o interrogati e memorizzati altrove.
Quali eventi di messaggio sono disponibili?
SparkPost attualmente espone 14 eventi, tra cui consegne, rimbalzi, clic, aperture, rifiuti, problemi di politica, segnalazioni di spam, cancellazioni e altro ancora.
Quali identificatori collegano tutti gli eventi?
Tutti i messaggi in uscita (originale, archivio, CC, BCC) condividono lo stesso transmission_id. L'email originale e l'email di archivio condividono anche lo stesso message_id.
Perché il processamento in entrata è una sfida?
Il Relay Email Inbound di SparkPost converte le email in entrata in JSON, ma questo JSON non include transmission_id. Senza dati aggiuntivi, la copia in entrata non può essere collegata alla sua cronologia del log in uscita.
Come si collegano le email di archivio in entrata agli eventi dei messaggi in uscita?
Incorpora un identificatore unico (UID) nascosto nel corpo dell'email e passa lo stesso UID nei metadati. Questo UID diventa il riferimento condiviso tra i record in entrata e in uscita.
In che modo il Relay Email Inbound aiuta ad automatizzare l'archiviazione?
Riceve le email di archivio inviate al tuo dominio di archiviazione, le analizza in JSON strutturato e le invia alla tua applicazione tramite webhook, consentendo l'estrazione e la memorizzazione automatizzata.
Qual è la visione a lungo termine del progetto?
Un'applicazione completa che:
Archivia le email in S3
Memorizza tutti i log degli eventi in MySQL
Permette agli utenti di cercare le email
Visualizza l'email originale e ogni evento associato in un'interfaccia unica
Circa un anno fa, ho scritto un blog su come recuperare copie delle email per archiviazione e visualizzazione, ma non ho affrontato il reale stoccaggio dell'email o dei dati correlati, e recentemente ho scritto un blog sullo stoccaggio di tutti i dati degli eventi (cioè quando l'email è stata inviata, aperture, clic, rimbalzi, disiscrizioni, ecc.) su un'email per scopi di auditing, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso delle email in ambienti normativi, ho deciso che era ora di avviare un nuovo progetto che unisse tutto questo con dei campioni di codice su come memorizzare il corpo dell'email e tutti i suoi dati associati. Nel prossimo anno, continuerò a sviluppare questo progetto con l'obiettivo di creare un'applicazione funzionante per l'archiviazione e la visualizzazione delle email archiviate e di tutte le informazioni di log prodotte da SparkPost. SparkPost non dispone di un sistema che archivia il corpo delle email, ma rende relativamente semplice la costruzione di una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per memorizzare il corpo dell’email su S3 (Simple Store Service di Amazon) e tutti i dati di log pertinenti in MySQL per un facile riferimento incrociato. Per i sistemi di archiviazione di produzione che richiedono strategie di backup di database robuste, considera di implementare un processo di backup e ripristino PostgreSQL completo per garantire che i tuoi dati di archiviazione siano protetti correttamente. In definitiva, questo è il punto di partenza per costruire un'applicazione che consentirà una facile ricerca delle email archiviate, per poi visualizzare quelle email insieme ai dati degli eventi (log). Il codice per questo progetto può essere trovato nel seguente repository GitHub: PHPArchivePlatform su GitHub
Questa prima voce della serie di blog descriverà la sfida e delineerà un'architettura per la soluzione. Il resto dei blog dettagliarà porzioni della soluzione insieme a campioni di codice.
Il primo passo nel mio processo è stato scoprire come ottenere una copia dell’email inviata al destinatario originale. Per ottenere una copia del corpo dell'email, è necessario:
Opzioni di cattura del corpo dell'email
Metodo | Chi crea la copia | Riflette le modifiche di tracciamento | Amico dell'automazione | Utilizzato in questa soluzione |
|---|---|---|---|---|
Cattura prima dell'invio | Applicazione | ❌ No | ✅ Sì | ❌ |
Il server email memorizza la copia | Server di posta | ✅ Sì | ❌ Limitato | ❌ |
Funzione di archiviazione di SparkPost | SparkPost | ✅ Sì | ✅ Sì | ✅ |
Catturare il corpo dell'email prima di inviare l'email
Far memorizzare una copia dal server email
Far creare la copia dal server email per memorizzarla
Se il server email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non puoi utilizzare il punto #1 perché non rifletterà le modifiche del tracciamento delle aperture/clic.
Questo significa che o il server deve memorizzare l'email o in qualche modo offrirti una copia di quell'email per la memorizzazione. Poiché SparkPost non ha un meccanismo di archiviazione per i corpi delle email ma ha un modo per creare una copia dell'email, faremo in modo che SparkPost ci invii una copia dell'email da memorizzare su S3.
Questo viene fatto utilizzando la funzione di archiviazione di SparkPost. La funzione di archiviazione di SparkPost dà al mittente la possibilità di dire a SparkPost di inviare una copia duplicata dell'email a uno o più indirizzi email e di utilizzare gli stessi link di tracciamento e apertura dell'originale. La documentazione di SparkPost definisce la loro funzione di archiviazione nel seguente modo:
I destinatari nell'elenco di archiviazione riceveranno un replica esatta del messaggio che è stato inviato all'indirizzo RCPT TO. In particolare, eventuali link codificati destinati al destinatario RCPT TO saranno identici nei messaggi di archiviazione
Le uniche differenze rispetto all'email RCPT TO sono che alcune delle intestazioni saranno diverse poiché l'indirizzo di destinazione per l'email di archiviazione è diverso, ma il corpo dell'email sarà una replica esatta!
Se desideri una spiegazione più approfondita, ecco un link alla documentazione di SparkPost sulla creazione di copie duplicate (o di archiviazione) di un'email.
Come nota a margine, SparkPost consente effettivamente di inviare email a indirizzi cc, bcc e di archiviazione. Per questa soluzione, ci concentriamo sugli indirizzi di archiviazione.
* Avviso * Le email archiviate possono ESSERE create SOLO quando si iniettano email in SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo guardare i dati di log che vengono prodotti e alcune delle sottigliezze all'interno di quel dato. SparkPost tiene traccia di tutto ciò che accade sui propri server e ti offre tali informazioni sotto forma di eventi di messaggio. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere recuperati dal server tramite un'API RESTful chiamata eventi di messaggio, o puoi fare in modo che SparkPost invii quegli eventi a qualsiasi numero di applicazioni di raccolta che desideri. Il meccanismo di invio avviene tramite webhook ed è eseguito in tempo reale.
Attualmente, ci sono 14 eventi diversi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
Rimbalzo
ClickDelay
Consegna
Errore di generazione
Reiezione di generazione
Prima apertura
Unsubscribe link di InjectionLink
Disiscrizione dalla lista
Apertura
Fuori banda
Politica di Reiezione Reclamo di Spam
* Segui questo link per una guida di riferimento aggiornata per una descrizione di ciascun evento insieme ai dati condivisi per ciascun evento.
Ogni evento ha numerosi campi che corrispondono al tipo di evento. Alcuni campi come il transmission_id si trovano in ogni evento, ma altri campi potrebbero essere più specifici per l'evento; ad esempio, solo gli eventi di apertura e clic hanno informazioni geotag.
Identificatori utilizzati nel sistema di archiviazione
Identificatore | Dove ha origine | Condiviso tra | Scopo | Limitazione |
|---|---|---|---|---|
transmission_id | Uscita SparkPost | Originale, archiviazione, cc, bcc | Correla tutti gli eventi di messaggio | Non disponibile nel relay in entrata |
message_id | Uscita SparkPost | Originale + archiviazione | Identifica messaggi individuali | Diverso per cc/bcc |
UID Nascosto | Iniettato dal mittente | Uscente + in entrata | Collega il corpo email archiviato agli eventi | Deve essere implementato su misura |
Un'entry di evento di messaggio molto importante per questo progetto è il transmission_id. Tutte le voci degli eventi di messaggio per l'email originale, l'email archiviata e eventuali indirizzi cc e bcc condivideranno lo stesso transmission_id.
Esiste anche una voce comune chiamata message_id che avrà lo stesso id per ogni entry dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per l'entry message_id .
Finora sembra fantastico e francamente piuttosto facile, ma ora arriva la parte impegnativa. Ricorda, per ottenere l'email di archiviazione, facciamo in modo che SparkPost invii una copia duplicata dell'email originale a un altro indirizzo email che corrisponde a qualche casella di posta a cui hai accesso. Ma per automatizzare questa soluzione e memorizzare il corpo dell'email, utilizzerò un’altra funzione di SparkPost chiamata Relaying Email in Entrata. Ciò che fa, è prendere tutte le email inviate a un dominio specifico e processarle. Processandole, l'email viene smontata e viene creata una struttura JSON che viene quindi consegnata a un'applicazione tramite un webhook. Vedi l'Appendice A per un campione JSON.
Se guardi attentamente, noterai che la struttura JSON del relay in entrata è priva di un campo molto importante; il transmission_id. Mentre tutte le email in uscita hanno il transmission_id con la stessa entry che lega tutti i dati dell'email originale, archiviazione, cc e indirizzi bcc; SparkPost non ha modo di sapere che l'email catturata dal processo in entrata è collegata a qualsiasi email in uscita. Il processo in entrata sa semplicemente che è stata inviata un'email a un dominio specifico e di analizzare l'email. Questo è tutto. Tratterà qualsiasi email inviata a quel dominio allo stesso modo, sia essa una risposta da un cliente che l'email di archiviazione inviata da SparkPost.
Quindi, il trucco è: come si incolla il dato in uscita al processo in entrata che ha appena acquisito la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id unico nel corpo dell'email. Come questo venga fatto è a tua discrezione, ma io ho semplicemente creato un campo di input con il tag nascosto attivato.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Ho anche aggiunto quel campo nel blocco dei metadati dell'intestazione X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto finirà per essere la colla dell'intero processo, ed è un componente principale del progetto che sarà discusso in modo approfondito nei prossimi post del blog.
Ora che abbiamo l'UID che unirà questo progetto e comprendiamo perché sia necessario, posso iniziare a costruire la visione dell'intero progetto e dei corrispondenti post del blog.
Catturare e memorizzare l'email di archiviazione insieme a un'entry di database per ricerca indicizzazione
Catturare tutti i dati dell'evento del messaggio
Creare un'applicazione per visualizzare l’email e tutti i dati corrispondenti
Qui c'è un diagramma semplice del progetto:
Il primo drop di codice coprirà il processo di archiviazione e la memorizzazione dell'email su S3, mentre il secondo drop di codice coprirà la memorizzazione di tutti i dati di log provenienti dagli eventi di messaggio in MySQL. Puoi aspettarti i primi due drop di codice e post del blog nei primi mesi del 2019. Se hai domande o suggerimenti, non esitare a farceli sapere.
Buon invio.
– Jeff
Appendice A:
Circa un anno fa, ho scritto un blog su come recuperare copie delle email per archiviazione e visualizzazione, ma non ho affrontato il reale stoccaggio dell'email o dei dati correlati, e recentemente ho scritto un blog sullo stoccaggio di tutti i dati degli eventi (cioè quando l'email è stata inviata, aperture, clic, rimbalzi, disiscrizioni, ecc.) su un'email per scopi di auditing, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso delle email in ambienti normativi, ho deciso che era ora di avviare un nuovo progetto che unisse tutto questo con dei campioni di codice su come memorizzare il corpo dell'email e tutti i suoi dati associati. Nel prossimo anno, continuerò a sviluppare questo progetto con l'obiettivo di creare un'applicazione funzionante per l'archiviazione e la visualizzazione delle email archiviate e di tutte le informazioni di log prodotte da SparkPost. SparkPost non dispone di un sistema che archivia il corpo delle email, ma rende relativamente semplice la costruzione di una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per memorizzare il corpo dell’email su S3 (Simple Store Service di Amazon) e tutti i dati di log pertinenti in MySQL per un facile riferimento incrociato. Per i sistemi di archiviazione di produzione che richiedono strategie di backup di database robuste, considera di implementare un processo di backup e ripristino PostgreSQL completo per garantire che i tuoi dati di archiviazione siano protetti correttamente. In definitiva, questo è il punto di partenza per costruire un'applicazione che consentirà una facile ricerca delle email archiviate, per poi visualizzare quelle email insieme ai dati degli eventi (log). Il codice per questo progetto può essere trovato nel seguente repository GitHub: PHPArchivePlatform su GitHub
Questa prima voce della serie di blog descriverà la sfida e delineerà un'architettura per la soluzione. Il resto dei blog dettagliarà porzioni della soluzione insieme a campioni di codice.
Il primo passo nel mio processo è stato scoprire come ottenere una copia dell’email inviata al destinatario originale. Per ottenere una copia del corpo dell'email, è necessario:
Opzioni di cattura del corpo dell'email
Metodo | Chi crea la copia | Riflette le modifiche di tracciamento | Amico dell'automazione | Utilizzato in questa soluzione |
|---|---|---|---|---|
Cattura prima dell'invio | Applicazione | ❌ No | ✅ Sì | ❌ |
Il server email memorizza la copia | Server di posta | ✅ Sì | ❌ Limitato | ❌ |
Funzione di archiviazione di SparkPost | SparkPost | ✅ Sì | ✅ Sì | ✅ |
Catturare il corpo dell'email prima di inviare l'email
Far memorizzare una copia dal server email
Far creare la copia dal server email per memorizzarla
Se il server email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non puoi utilizzare il punto #1 perché non rifletterà le modifiche del tracciamento delle aperture/clic.
Questo significa che o il server deve memorizzare l'email o in qualche modo offrirti una copia di quell'email per la memorizzazione. Poiché SparkPost non ha un meccanismo di archiviazione per i corpi delle email ma ha un modo per creare una copia dell'email, faremo in modo che SparkPost ci invii una copia dell'email da memorizzare su S3.
Questo viene fatto utilizzando la funzione di archiviazione di SparkPost. La funzione di archiviazione di SparkPost dà al mittente la possibilità di dire a SparkPost di inviare una copia duplicata dell'email a uno o più indirizzi email e di utilizzare gli stessi link di tracciamento e apertura dell'originale. La documentazione di SparkPost definisce la loro funzione di archiviazione nel seguente modo:
I destinatari nell'elenco di archiviazione riceveranno un replica esatta del messaggio che è stato inviato all'indirizzo RCPT TO. In particolare, eventuali link codificati destinati al destinatario RCPT TO saranno identici nei messaggi di archiviazione
Le uniche differenze rispetto all'email RCPT TO sono che alcune delle intestazioni saranno diverse poiché l'indirizzo di destinazione per l'email di archiviazione è diverso, ma il corpo dell'email sarà una replica esatta!
Se desideri una spiegazione più approfondita, ecco un link alla documentazione di SparkPost sulla creazione di copie duplicate (o di archiviazione) di un'email.
Come nota a margine, SparkPost consente effettivamente di inviare email a indirizzi cc, bcc e di archiviazione. Per questa soluzione, ci concentriamo sugli indirizzi di archiviazione.
* Avviso * Le email archiviate possono ESSERE create SOLO quando si iniettano email in SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo guardare i dati di log che vengono prodotti e alcune delle sottigliezze all'interno di quel dato. SparkPost tiene traccia di tutto ciò che accade sui propri server e ti offre tali informazioni sotto forma di eventi di messaggio. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere recuperati dal server tramite un'API RESTful chiamata eventi di messaggio, o puoi fare in modo che SparkPost invii quegli eventi a qualsiasi numero di applicazioni di raccolta che desideri. Il meccanismo di invio avviene tramite webhook ed è eseguito in tempo reale.
Attualmente, ci sono 14 eventi diversi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
Rimbalzo
ClickDelay
Consegna
Errore di generazione
Reiezione di generazione
Prima apertura
Unsubscribe link di InjectionLink
Disiscrizione dalla lista
Apertura
Fuori banda
Politica di Reiezione Reclamo di Spam
* Segui questo link per una guida di riferimento aggiornata per una descrizione di ciascun evento insieme ai dati condivisi per ciascun evento.
Ogni evento ha numerosi campi che corrispondono al tipo di evento. Alcuni campi come il transmission_id si trovano in ogni evento, ma altri campi potrebbero essere più specifici per l'evento; ad esempio, solo gli eventi di apertura e clic hanno informazioni geotag.
Identificatori utilizzati nel sistema di archiviazione
Identificatore | Dove ha origine | Condiviso tra | Scopo | Limitazione |
|---|---|---|---|---|
transmission_id | Uscita SparkPost | Originale, archiviazione, cc, bcc | Correla tutti gli eventi di messaggio | Non disponibile nel relay in entrata |
message_id | Uscita SparkPost | Originale + archiviazione | Identifica messaggi individuali | Diverso per cc/bcc |
UID Nascosto | Iniettato dal mittente | Uscente + in entrata | Collega il corpo email archiviato agli eventi | Deve essere implementato su misura |
Un'entry di evento di messaggio molto importante per questo progetto è il transmission_id. Tutte le voci degli eventi di messaggio per l'email originale, l'email archiviata e eventuali indirizzi cc e bcc condivideranno lo stesso transmission_id.
Esiste anche una voce comune chiamata message_id che avrà lo stesso id per ogni entry dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per l'entry message_id .
Finora sembra fantastico e francamente piuttosto facile, ma ora arriva la parte impegnativa. Ricorda, per ottenere l'email di archiviazione, facciamo in modo che SparkPost invii una copia duplicata dell'email originale a un altro indirizzo email che corrisponde a qualche casella di posta a cui hai accesso. Ma per automatizzare questa soluzione e memorizzare il corpo dell'email, utilizzerò un’altra funzione di SparkPost chiamata Relaying Email in Entrata. Ciò che fa, è prendere tutte le email inviate a un dominio specifico e processarle. Processandole, l'email viene smontata e viene creata una struttura JSON che viene quindi consegnata a un'applicazione tramite un webhook. Vedi l'Appendice A per un campione JSON.
Se guardi attentamente, noterai che la struttura JSON del relay in entrata è priva di un campo molto importante; il transmission_id. Mentre tutte le email in uscita hanno il transmission_id con la stessa entry che lega tutti i dati dell'email originale, archiviazione, cc e indirizzi bcc; SparkPost non ha modo di sapere che l'email catturata dal processo in entrata è collegata a qualsiasi email in uscita. Il processo in entrata sa semplicemente che è stata inviata un'email a un dominio specifico e di analizzare l'email. Questo è tutto. Tratterà qualsiasi email inviata a quel dominio allo stesso modo, sia essa una risposta da un cliente che l'email di archiviazione inviata da SparkPost.
Quindi, il trucco è: come si incolla il dato in uscita al processo in entrata che ha appena acquisito la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id unico nel corpo dell'email. Come questo venga fatto è a tua discrezione, ma io ho semplicemente creato un campo di input con il tag nascosto attivato.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Ho anche aggiunto quel campo nel blocco dei metadati dell'intestazione X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto finirà per essere la colla dell'intero processo, ed è un componente principale del progetto che sarà discusso in modo approfondito nei prossimi post del blog.
Ora che abbiamo l'UID che unirà questo progetto e comprendiamo perché sia necessario, posso iniziare a costruire la visione dell'intero progetto e dei corrispondenti post del blog.
Catturare e memorizzare l'email di archiviazione insieme a un'entry di database per ricerca indicizzazione
Catturare tutti i dati dell'evento del messaggio
Creare un'applicazione per visualizzare l’email e tutti i dati corrispondenti
Qui c'è un diagramma semplice del progetto:
Il primo drop di codice coprirà il processo di archiviazione e la memorizzazione dell'email su S3, mentre il secondo drop di codice coprirà la memorizzazione di tutti i dati di log provenienti dagli eventi di messaggio in MySQL. Puoi aspettarti i primi due drop di codice e post del blog nei primi mesi del 2019. Se hai domande o suggerimenti, non esitare a farceli sapere.
Buon invio.
– Jeff
Appendice A:
Circa un anno fa, ho scritto un blog su come recuperare copie delle email per archiviazione e visualizzazione, ma non ho affrontato il reale stoccaggio dell'email o dei dati correlati, e recentemente ho scritto un blog sullo stoccaggio di tutti i dati degli eventi (cioè quando l'email è stata inviata, aperture, clic, rimbalzi, disiscrizioni, ecc.) su un'email per scopi di auditing, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso delle email in ambienti normativi, ho deciso che era ora di avviare un nuovo progetto che unisse tutto questo con dei campioni di codice su come memorizzare il corpo dell'email e tutti i suoi dati associati. Nel prossimo anno, continuerò a sviluppare questo progetto con l'obiettivo di creare un'applicazione funzionante per l'archiviazione e la visualizzazione delle email archiviate e di tutte le informazioni di log prodotte da SparkPost. SparkPost non dispone di un sistema che archivia il corpo delle email, ma rende relativamente semplice la costruzione di una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per memorizzare il corpo dell’email su S3 (Simple Store Service di Amazon) e tutti i dati di log pertinenti in MySQL per un facile riferimento incrociato. Per i sistemi di archiviazione di produzione che richiedono strategie di backup di database robuste, considera di implementare un processo di backup e ripristino PostgreSQL completo per garantire che i tuoi dati di archiviazione siano protetti correttamente. In definitiva, questo è il punto di partenza per costruire un'applicazione che consentirà una facile ricerca delle email archiviate, per poi visualizzare quelle email insieme ai dati degli eventi (log). Il codice per questo progetto può essere trovato nel seguente repository GitHub: PHPArchivePlatform su GitHub
Questa prima voce della serie di blog descriverà la sfida e delineerà un'architettura per la soluzione. Il resto dei blog dettagliarà porzioni della soluzione insieme a campioni di codice.
Il primo passo nel mio processo è stato scoprire come ottenere una copia dell’email inviata al destinatario originale. Per ottenere una copia del corpo dell'email, è necessario:
Opzioni di cattura del corpo dell'email
Metodo | Chi crea la copia | Riflette le modifiche di tracciamento | Amico dell'automazione | Utilizzato in questa soluzione |
|---|---|---|---|---|
Cattura prima dell'invio | Applicazione | ❌ No | ✅ Sì | ❌ |
Il server email memorizza la copia | Server di posta | ✅ Sì | ❌ Limitato | ❌ |
Funzione di archiviazione di SparkPost | SparkPost | ✅ Sì | ✅ Sì | ✅ |
Catturare il corpo dell'email prima di inviare l'email
Far memorizzare una copia dal server email
Far creare la copia dal server email per memorizzarla
Se il server email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non puoi utilizzare il punto #1 perché non rifletterà le modifiche del tracciamento delle aperture/clic.
Questo significa che o il server deve memorizzare l'email o in qualche modo offrirti una copia di quell'email per la memorizzazione. Poiché SparkPost non ha un meccanismo di archiviazione per i corpi delle email ma ha un modo per creare una copia dell'email, faremo in modo che SparkPost ci invii una copia dell'email da memorizzare su S3.
Questo viene fatto utilizzando la funzione di archiviazione di SparkPost. La funzione di archiviazione di SparkPost dà al mittente la possibilità di dire a SparkPost di inviare una copia duplicata dell'email a uno o più indirizzi email e di utilizzare gli stessi link di tracciamento e apertura dell'originale. La documentazione di SparkPost definisce la loro funzione di archiviazione nel seguente modo:
I destinatari nell'elenco di archiviazione riceveranno un replica esatta del messaggio che è stato inviato all'indirizzo RCPT TO. In particolare, eventuali link codificati destinati al destinatario RCPT TO saranno identici nei messaggi di archiviazione
Le uniche differenze rispetto all'email RCPT TO sono che alcune delle intestazioni saranno diverse poiché l'indirizzo di destinazione per l'email di archiviazione è diverso, ma il corpo dell'email sarà una replica esatta!
Se desideri una spiegazione più approfondita, ecco un link alla documentazione di SparkPost sulla creazione di copie duplicate (o di archiviazione) di un'email.
Come nota a margine, SparkPost consente effettivamente di inviare email a indirizzi cc, bcc e di archiviazione. Per questa soluzione, ci concentriamo sugli indirizzi di archiviazione.
* Avviso * Le email archiviate possono ESSERE create SOLO quando si iniettano email in SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo guardare i dati di log che vengono prodotti e alcune delle sottigliezze all'interno di quel dato. SparkPost tiene traccia di tutto ciò che accade sui propri server e ti offre tali informazioni sotto forma di eventi di messaggio. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere recuperati dal server tramite un'API RESTful chiamata eventi di messaggio, o puoi fare in modo che SparkPost invii quegli eventi a qualsiasi numero di applicazioni di raccolta che desideri. Il meccanismo di invio avviene tramite webhook ed è eseguito in tempo reale.
Attualmente, ci sono 14 eventi diversi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
Rimbalzo
ClickDelay
Consegna
Errore di generazione
Reiezione di generazione
Prima apertura
Unsubscribe link di InjectionLink
Disiscrizione dalla lista
Apertura
Fuori banda
Politica di Reiezione Reclamo di Spam
* Segui questo link per una guida di riferimento aggiornata per una descrizione di ciascun evento insieme ai dati condivisi per ciascun evento.
Ogni evento ha numerosi campi che corrispondono al tipo di evento. Alcuni campi come il transmission_id si trovano in ogni evento, ma altri campi potrebbero essere più specifici per l'evento; ad esempio, solo gli eventi di apertura e clic hanno informazioni geotag.
Identificatori utilizzati nel sistema di archiviazione
Identificatore | Dove ha origine | Condiviso tra | Scopo | Limitazione |
|---|---|---|---|---|
transmission_id | Uscita SparkPost | Originale, archiviazione, cc, bcc | Correla tutti gli eventi di messaggio | Non disponibile nel relay in entrata |
message_id | Uscita SparkPost | Originale + archiviazione | Identifica messaggi individuali | Diverso per cc/bcc |
UID Nascosto | Iniettato dal mittente | Uscente + in entrata | Collega il corpo email archiviato agli eventi | Deve essere implementato su misura |
Un'entry di evento di messaggio molto importante per questo progetto è il transmission_id. Tutte le voci degli eventi di messaggio per l'email originale, l'email archiviata e eventuali indirizzi cc e bcc condivideranno lo stesso transmission_id.
Esiste anche una voce comune chiamata message_id che avrà lo stesso id per ogni entry dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per l'entry message_id .
Finora sembra fantastico e francamente piuttosto facile, ma ora arriva la parte impegnativa. Ricorda, per ottenere l'email di archiviazione, facciamo in modo che SparkPost invii una copia duplicata dell'email originale a un altro indirizzo email che corrisponde a qualche casella di posta a cui hai accesso. Ma per automatizzare questa soluzione e memorizzare il corpo dell'email, utilizzerò un’altra funzione di SparkPost chiamata Relaying Email in Entrata. Ciò che fa, è prendere tutte le email inviate a un dominio specifico e processarle. Processandole, l'email viene smontata e viene creata una struttura JSON che viene quindi consegnata a un'applicazione tramite un webhook. Vedi l'Appendice A per un campione JSON.
Se guardi attentamente, noterai che la struttura JSON del relay in entrata è priva di un campo molto importante; il transmission_id. Mentre tutte le email in uscita hanno il transmission_id con la stessa entry che lega tutti i dati dell'email originale, archiviazione, cc e indirizzi bcc; SparkPost non ha modo di sapere che l'email catturata dal processo in entrata è collegata a qualsiasi email in uscita. Il processo in entrata sa semplicemente che è stata inviata un'email a un dominio specifico e di analizzare l'email. Questo è tutto. Tratterà qualsiasi email inviata a quel dominio allo stesso modo, sia essa una risposta da un cliente che l'email di archiviazione inviata da SparkPost.
Quindi, il trucco è: come si incolla il dato in uscita al processo in entrata che ha appena acquisito la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id unico nel corpo dell'email. Come questo venga fatto è a tua discrezione, ma io ho semplicemente creato un campo di input con il tag nascosto attivato.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Ho anche aggiunto quel campo nel blocco dei metadati dell'intestazione X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto finirà per essere la colla dell'intero processo, ed è un componente principale del progetto che sarà discusso in modo approfondito nei prossimi post del blog.
Ora che abbiamo l'UID che unirà questo progetto e comprendiamo perché sia necessario, posso iniziare a costruire la visione dell'intero progetto e dei corrispondenti post del blog.
Catturare e memorizzare l'email di archiviazione insieme a un'entry di database per ricerca indicizzazione
Catturare tutti i dati dell'evento del messaggio
Creare un'applicazione per visualizzare l’email e tutti i dati corrispondenti
Qui c'è un diagramma semplice del progetto:
Il primo drop di codice coprirà il processo di archiviazione e la memorizzazione dell'email su S3, mentre il secondo drop di codice coprirà la memorizzazione di tutti i dati di log provenienti dagli eventi di messaggio in MySQL. Puoi aspettarti i primi due drop di codice e post del blog nei primi mesi del 2019. Se hai domande o suggerimenti, non esitare a farceli sapere.
Buon invio.
– Jeff
Appendice A:
