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 di email per l'archiviazione e la visualizzazione, ma non ho affrontato l'argomento dell'archiviazione dell'email o dei dati correlati. Recentemente ho scritto un blog sull'archiviazione di tutti i dati degli eventi (ad esempio, quando è stata inviata l'email, aperture, clic, rimbalzi, cancellazioni, ecc.) su un'email per scopi di verifica, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso delle email in ambienti regolamentati, ho deciso che è il momento di avviare un nuovo progetto che metta insieme tutto ciò con esempi di codice su come archiviare 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 delle email e tutte le informazioni di log prodotte da SparkPost. SparkPost non ha un sistema che archivia il corpo dell'email, ma rende piuttosto semplice costruire una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per archiviare il corpo dell'email su S3 (il servizio di archiviazione semplice di Amazon) e tutti i dati di log pertinenti in MySQL per una facile consultazione. Per i sistemi di archiviazione in produzione che richiedono strategie di backup robusto, considera l'implementazione di un completo processo di backup e ripristino PostgreSQL per garantire che i tuoi dati di archiviazione 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 degli eventi (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 definirà un'architettura per la soluzione. Il resto dei blog dettaglierà parti della soluzione insieme a esempi di codice.
Il primo passo nel mio processo era 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 memorizzare una copia al server di posta
Far creare al server di posta una copia per il tuo archivio
Se il server di posta aggiunge elementi come il tracciamento dei link o delle aperture, non puoi usare il #1 perché non rifletterà i cambiamenti del tracciamento aperture/clic.
Questo significa che o il server deve memorizzare l'email o in qualche modo offrire una copia di quella email per il tuo archivio. Poiché SparkPost non ha un meccanismo di memorizzazione per i corpi delle email ma ha un modo per creare una copia dell'email, faremo in modo che SparkPost ci invii un duplicato dell'email da archiviare su S3.
Questo avviene utilizzando la funzione di Archiviazione di SparkPost. La funzione di Archiviazione di SparkPost fornisce al mittente la possibilità di dire a SparkPost di inviare un duplicato dell'email a uno o più indirizzi email ed usare gli stessi link di tracciamento e di apertura dell'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 che è stato inviato all'indirizzo RCPT TO. In particolare, tutti i link codificati destinati al destinatario RCPT TO saranno identici nei messaggi di archivio
Le uniche differenze dall'email RCPT TO sono che alcuni dei header saranno diversi, poiché l'indirizzo target per l'email di archiviazione è diverso, ma il corpo dell'email sarà una replica esatta!
Se vuoi una spiegazione più dettagliata, ecco un link alla documentazione di SparkPost sulla creazione di copie duplicate (o di archiviazione) di un'email.
Come nota a margine, SparkPost ti permette 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 inviano email a SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo guardare i dati di log prodotti e alcune delle sottili sfumature all'interno di quei dati. SparkPost traccia tutto ciò che accade sui suoi server e offre quell'informazione sotto forma di eventi-messaggio. Quegli eventi vengono archiviati su SparkPost per 10 giorni e possono essere prelevati dal server tramite un'API RESTful chiamata eventi-messaggio, oppure puoi far sì che SparkPost invii quegli eventi a qualsiasi numero di applicazioni di raccolta che tu desideri. Il meccanismo di invio avviene tramite webhook ed è in tempo reale.
Attualmente, ci sono 14 diversi eventi che possono verificarsi su un'email. Ecco un elenco degli eventi correnti:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial 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 ogni evento insieme ai dati condivisi per ogni 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 per evento; per esempio, solo gli eventi di apertura e clic hanno informazioni geografiche.
Un importante punto d'ingresso per gli eventi messaggio in questo progetto è il transmission_id. Tutti gli entrati di evento messaggio per l'email originale, l'email archiviata, e qualsiasi indirizzo cc e bcc condivideranno lo stesso transmission_id.
Esiste anche un comune punto d'ingresso chiamato message_id che avrà lo stesso id per ciascuna entrata dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per l'entrata di message_id.
Fin qui sembra tutto fantastico e, francamente, abbastanza semplice, ma ora viene la parte difficile. Ricorda, per ottenere l'email archiviata, abbiamo SparkPost che invia 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 archiviare il corpo dell'email, utilizzerò un'altra funzionalità di SparkPost chiamata Relaying Email Inbound. Ciò che fa è prendere tutte le email inviate a un dominio specifico e processarle. Elaborando, smonta l'email e crea una struttura JSON che viene poi consegnata a un'applicazione tramite un webhook. Vedi l'Appendice A per un esempio di JSON.
Se guardi attentamente, noterai che la struttura JSON del relè 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 unisce tutti i dati dall'email originale, di archiviazione, cc e bcc agli indirizzi, SparkPost non può sapere che l'email catturata dal processo in entrata è collegata a qualcuna delle email in uscita. Il processo in entrata sa semplicemente che un'email è stata inviata a un dominio specifico e di analizzare l'email. Tutto qui. Tratterà qualsiasi email inviata a quel dominio nello stesso modo, sia essa una risposta da un cliente o l'email di archivio inviata da SparkPost.
Quindi il trucco è; come si uniscono i dati in uscita con il processo in entrata che ha appena acquisito la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un ID univoco nel corpo dell'email. Come venga fatto questo, dipende da te, ma ho semplicemente creato un campo di input con il tag nascosto attivato.
Ho anche aggiunto quel campo nel blocco metadata dell'header X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto alla fine sarà la colla di tutto il processo e sarà discusso in dettaglio nei post del blog seguenti.
Ora che abbiamo l'UID che unirà questo progetto e capiamo perché è necessario, posso iniziare a costruire la visione del progetto complessivo e dei post del blog corrispondenti.
Acquisizione e memorizzazione dell'email archiviata insieme a un ingresso nel database per ricerca/indicizzazione
Acquisizione di tutti i dati dell'evento messaggio
Creare un'applicazione per visualizzare l'email e tutti i dati corrispondenti
Ecco un semplice diagramma del progetto:
La prima versione di codice coprirà il processo di archiviazione e l'archiviazione dell'email su S3, mentre la seconda versione di codice coprirà l'archiviazione di tutti i dati di log dagli eventi-messaggio in MySQL. Puoi aspettarti le prime due versioni di codice e voci di blog all'inizio del 2019. Se hai domande o suggerimenti, per favore sentiti libero di comunicarli.
Buon invio.
– Jeff
Appendice A:
