Con l'aumento dell'uso delle email in ambienti normativi, ho deciso che è il momento di avviare un nuovo progetto che riunisca tutto questo con esempi di codice su come memorizzare il corpo dell'email e tutti i dati associati.
Circa un anno fa, ho scritto un blog su come recuperare copie delle email per l'archiviazione e la visualizzazione, ma non ho affrontato il tema effettivo dello stoccaggio delle email o dei dati correlati. Recentemente, ho scritto un blog su come archiviare tutti i dati degli eventi (cioè quando l'email è stata inviata, aperture, clic, rimbalzi, cancellazioni, ecc.) su un’email per finalità di audit, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso delle email in ambienti regolatori, ho deciso che è giunto il momento di avviare un nuovo progetto che riunisca tutto questo con esempi di codice su come conservare il corpo dell'email e tutti i dati associati. Nel corso del 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 tutte le informazioni di log prodotte da SparkPost. SparkPost non ha un sistema che archivia il corpo delle 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’s Simple Store Service) e tutti i dati di registro pertinenti in MySQL per un facile cross-referencing. Per sistemi di archiviazione di produzione che richiedono strategie robuste di backup del database, considera l'implementazione di un processo completo di backup e ripristino di PostgreSQL per garantire che i tuoi dati d'archivio siano adeguatamente protetti. In definitiva, questo è il punto di partenza per costruire un'applicazione che consentirà una facile ricerca delle email archiviate, quindi visualizzare quelle email insieme ai dati di evento (log). Il codice per questo progetto può essere trovato nel seguente repository GitHub: https://github.com/jeff-goldstein/PHPArchivePlatform
Questa prima voce della serie di blog descriverà la sfida e delineerà un'architettura per la soluzione. Il resto dei blog dettaglierà parti della soluzione insieme a esempi di codice.
Il primo passo nel mio processo è stato capire come 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 sì che il server email memorizzi una copia
Fare in modo che il server email crei una copia da archiviare
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 di tracciamento aperture/clic.
Ciò significa che o il server deve memorizzare l'email o, in qualche modo, deve offrire una copia di quell'email per essere conservata. Poiché SparkPost non ha un meccanismo di archiviazione per i corpi delle email ma ha un modo per creare una copia dell'email, faremo sì che SparkPost ci invii un duplicato dell'email per archiviarlo su S3.
Questo è 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 un duplicato dell'email a uno o più indirizzi email e di utilizzare gli stessi link di tracciamento e apertura della email originale. La documentazione di SparkPost definisce la loro funzione di Archiviazione nel seguente modo:
I destinatari nella lista di archiviazione riceveranno una replica esatta del messaggio inviato all'indirizzo RCPT TO. In particolare, qualsiasi link codificato destinato al destinatario RCPT TO sarà identico nei messaggi di archiviazione
L'unica differenza rispetto alla email RCPT TO è che alcuni degli header saranno differenti poiché l'indirizzo di destinazione per l'email di archiviazione è diverso, ma il corpo della email sarà una replica esatta!
Se desideri una spiegazione più approfondita, ecco un link alla documentazione di SparkPost su come creare copie duplicate (o d'archivio) di un'email.
Come nota a margine, SparkPost ti 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 registro che vengono prodotti e alcune delle piccole sottigliezze all'interno di quei dati. SparkPost traccia tutto ciò che accade sui suoi server e offre tali 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 sì che SparkPost invii questi eventi a qualsiasi numero di applicazioni di raccolta che desideri. Il meccanismo di invio è effettuato tramite webhook ed è fatto in tempo reale.
Attualmente ci sono 14 eventi diversi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
Bounce
ClickDelay
Delivery
Generazione Failure
Generazione Rejection
Initially Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* 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 possono essere più specifici all'evento; ad esempio, solo gli eventi di apertura e clic hanno informazioni di geotag.
Un campo molto importante di evento messaggio per questo progetto è il transmission_id. Tutte le voci di eventi messaggio per l'email originale, l'email archiviata e qualsiasi indirizzo cc e bcc condivideranno lo stesso transmission_id.
Vi è anche una voce comune chiamata message_id che avrà lo stesso id per ogni voce dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per la voce message_id .
Fin qui sembra tutto ottimo e francamente abbastanza facile, ma ora arriva la parte difficile. Ricorda, per ottenere l'email di archivio, abbiamo fatto sì che SparkPost inviasse un duplicato dell'email originale a un altro indirizzo email che corrisponde a qualche inbox a cui hai accesso. Ma per automatizzare questa soluzione e conservare il corpo dell'email, userò un'altra funzione 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 poi consegnata a un'applicazione tramite un webhook. Vedi Appendice A per un esempio di JSON.
Se guardi attentamente, noterai che la struttura JSON del relay inbound manca di un campo molto importante; il transmission_id. Mentre tutte le email outbound hanno il transmission_id con la stessa voce che lega tutti i dati dall'email originale, archivia, cc e bcc indirizzi; SparkPost non ha modo di sapere che l'email catturata dal processo inbound è collegata a una delle email outbound. Il processo inbound sa semplicemente che un'email è stata inviata a un dominio specifico e di analizzare l'email. That's it. Tratterà qualsiasi email inviata a quel dominio nello stesso modo, sia essa una risposta di un cliente o l'email di archivio inviata da SparkPost.
Quindi il punto è; come unisci i dati outbound al processo inbound che ha appena preso la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id unico nel corpo dell'email. Come questo sia fatto dipende da te, ma ho semplicemente creato un campo di input con il tag hidden attivato.
Ho anche aggiunto quel campo nel blocco di metadata dell'header X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto finirà per essere la colla per l'intero processo ed è un componente principale del progetto e sarà discusso in dettaglio nei post del blog successivi.
Ora che abbiamo l'UID che unirà questo progetto e capiamo perché è necessario, posso iniziare a costruire la visione dell'intero progetto e dei corrispondenti post del blog.
Catturare e conservare l'email d'archivio insieme a una voce di database per la ricerca/indicizzazione
Registrare tutti i dati di evento messaggio
Creare un'applicazione per visualizzare l'email e tutti i dati corrispondenti
Ecco un semplice diagramma del progetto:
La prima pubblicazione di codice riguarderà il processo di archiviazione e la conservazione dell'email su S3, mentre la seconda pubblicazione di codice riguarderà la conservazione di tutti i dati di log da eventi messaggio in MySQL. Puoi aspettarti le prime due pubblicazioni di codice e voci di blog all'inizio del 2019. Se hai domande o suggerimenti, non esitare a farceli avere.
Buon Invio.
– Jeff
Appendice A:
