Circa un anno fa, ho scritto un blog su come recuperare copie di 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 sugli eventi (ad esempio, quando l'email è stata inviata, aperture, clic, rimbalzi, disiscrizioni, ecc.) su un'email ai fini dell'audit, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso delle email negli ambienti normativi, ho deciso che è tempo di avviare un nuovo progetto che raccolga tutto questo insieme a campioni di codice su come archiviare il corpo dell'email e tutti i dati associati. Nel corso del prossimo anno, continuerò a lavorare su 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 ha un sistema che archivia il corpo dell'email, ma rende abbastanza facile costruire una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per archiviare il corpo dell'email su S3 (Amazon Simple Store Service) e tutti i dati di log pertinenti in MySQL per un facile cross-referencing. In ultima analisi, questo è il punto di partenza per costruire un'applicazione che permetta 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 di GitHub: https://github.com/jeff-goldstein/PHPArchivePlatform
Questo primo articolo della serie di blog descriverà la sfida e delineerà un'architettura per la soluzione. Il resto dei blog dettagliarà parti della soluzione insieme ai campioni di codice.
Il primo passo del mio processo è stato capire come avrei potuto ottenere una copia dell'email inviata al destinatario originale. Per ottenere una copia del corpo dell'email, è necessario:
Catturare il corpo dell'email prima di inviare l'email
Far memorizzare una copia dal server email
Far creare al server email una copia da memorizzare
Se il server email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non puoi usare il punto #1 perché non rifletterà le modifiche al tracciamento delle aperture/clic.
Ciò significa che o il server deve archiviare 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 duplicazione dell'email da memorizzare in S3.
Questo viene fatto utilizzando la funzionalità di archiviazione di SparkPost. La funzione di archiviazione di SparkPost consente al mittente di dire a SparkPost di inviare una copia duplicata dell'email a uno o più indirizzi email e utilizzare lo stesso tracciamento e i link di apertura dell'originale. La documentazione di SparkPost definisce la loro funzione di archiviazione nel seguente modo:
I destinatari nella lista 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 target 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.
* Nota * 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 esaminare i dati di log che vengono prodotti e alcune delle sottili sfumature all'interno di quei dati. SparkPost tiene traccia di tutto ciò che accade sui suoi server e ti offre queste informazioni sotto forma di eventi-messaggio. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere estratti dal server tramite un'API RESTful chiamata eventi-messaggio, oppure puoi far spingere quegli eventi a un numero qualsiasi di applicazioni di raccolta che desideri. Il meccanismo di push avviene tramite webhook e viene effettuato in tempo reale.
Attualmente, ci sono 14 eventi diversi che possono verificarsi su un'email. Ecco un elenco degli eventi attuali:
Rimbalzo
ClickDelay
Consegna
Errore di generazione
Rigetto di generazione
Prima apertura
Disiscrizione da InjectionLink
Disiscrizione da lista
Apertura
Fuori banda
Rigetto della politica/Denuncia di spam
* Segui questo link per una guida di riferimento aggiornata per una descrizione di ogni evento insieme ai dati condivisi per ciascun evento.
Ogni evento ha numerosi campi che corrispondono al tipo di evento. Alcuni campi come transmission_id si trovano in ogni evento, ma altri campi possono essere più specifici per evento; ad esempio, solo gli eventi di apertura e clic hanno informazioni geotag.
Un'entrata 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.
C'è anche un'entrata comune chiamata message_id che avrà lo stesso id per ogni entrata dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per l'entrata message_id .
Finora tutto ciò 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 inbox a cui hai accesso. Ma per automatizzare questa soluzione e memorizzare il corpo dell'email, utilizzerò un'altra funzionalità di SparkPost chiamata Inbound Email Relaying. Ciò che fa è prendere tutte le email inviate a un dominio specifico e processarle. Processandole, strappa l'email e crea una struttura JSON che viene quindi consegnata a un'applicazione tramite un webhook. Vedi l'Appendice A per un esempio di JSON.
Se guardi molto attentamente, noterai che la struttura JSON dal relay in ingresso manca di un campo molto importante: il transmission_id. Mentre tutte le email in uscita hanno il transmission_id con la stessa entrata che lega tutti i dati dell'email originale, archiviata, cc e bcc; SparkPost non ha modo di sapere che l'email catturata dal processo in ingresso è collegata a una delle email in uscita. Il processo in ingresso 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 o l'email di archiviazione inviata da SparkPost.
Quindi la sfida è: come incollare i dati in uscita al processo in ingresso che ha appena catturato la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id unico nel corpo dell'email. Come questo viene fatto dipende da te, ma io ho semplicemente creato un campo di input con il tag hidden 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 diventerà la colla per l'intero processo ed è un componente principale del progetto che sarà discusso in profondità nei prossimi articoli del blog.
Ora che abbiamo l'UID che incollerà questo progetto insieme e comprendiamo perché è necessario, posso iniziare a costruire la visione dell'intero progetto e dei relativi articoli del blog.
Catturare e archiviare l'email di archiviazione insieme a un'entrata di database per la ricerca/lindicizzazione
Catturare tutti i dati degli eventi dei messaggi
Creare un'applicazione per visualizzare l'email e tutti i dati corrispondenti
Ecco un semplice diagramma del progetto:
Il primo blocco di codice tratterà il processo di archiviazione e lo stoccaggio dell'email su S3, mentre il secondo blocco di codice tratterà lo stoccaggio di tutti i dati di log dagli eventi-messaggio in MySQL. Puoi aspettarti i primi due blocchi di codice e i post del blog per l'inizio del 2019. Se hai domande o suggerimenti, sentiti libero di inviarli.
Felice invio.
– Jeff
Appendice A:
