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.
Business in a box.
Scopri le nostre soluzioni.
Parla con il nostro team di vendita
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'effettiva memorizzazione dell'email o dei dati correlati, e di recente ho scritto un blog su come memorizzare tutti i dati dell'evento (ad esempio, quando l'email è stata inviata, aperture, clic, rimbalzi, cancellazioni, ecc.) su un'email a scopo di audit, ma ho scelto di non creare alcun codice di supporto.
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. Nei prossimi mesi, continuerò a lavorare su questo progetto con l'obiettivo di creare un'applicazione funzionale per la memorizzazione e visualizzazione di email archiviate e di tutte le informazioni di log prodotte da SparkPost. SparkPost non dispone di 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 memorizzare il corpo dell'email su S3 (Amazon’s Simple Store Service) e tutti i dati di log rilevanti in MySQL per un facile riferimento incrociato. In definitiva, questo è il punto di partenza per la creazione di un'applicazione che consentirà di cercare facilmente le email archiviate, quindi di 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 delineerà un'architettura per la soluzione. Il resto dei blog dettagliarà parti della soluzione insieme a esempi di codice.
Il primo passo nel mio processo è stato capire come avrei ottenuto una copia dell'email inviata al destinatario originale. Per ottenere una copia del corpo dell'email, è necessario:
Catturare il corpo dell'email prima di inviarla
Chiedere al server di email di memorizzare una copia
Chiedere al server di email di creare una copia da memorizzare
Se il server di email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non si può usare il #1 perché non rifletterà le modifiche di tracciamento aperture/clic.
Questo significa che o il server deve memorizzare l'email o in qualche modo offrirti una copia di quella email da memorizzare. Poiché SparkPost non ha un meccanismo di memorizzazione 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 da memorizzare in S3.
Questo avviene utilizzando la funzione Archivio di SparkPost. La funzione Archivio 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 dell'originale. La documentazione di SparkPost definisce la loro funzione Archivio nel seguente modo:
I destinatari nella lista di archivio riceveranno una replica esatta del messaggio inviato all'indirizzo RCPT TO. In particolare, tutti i link codificati destinati al destinatario RCPT TO saranno identici nei messaggi di archivio
L'unica differenza rispetto all'email RCPT TO è 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 vuoi una spiegazione più approfondita, ecco un link alla documentazione di SparkPost su come creare copie duplicate (o di archivio) di un'email.
Come nota a margine, SparkPost consente effettivamente di inviare email a indirizzi di cc, bcc e archivio. Per questa soluzione, ci concentriamo sugli indirizzi di archivio.
* Avviso * Le email archiviate possono essere create SOLO quando si immettono email in SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo esaminare i dati di log prodotti e alcune delle sfumature sottili all'interno di questi dati. SparkPost traccia tutto ciò che accade sui suoi server e offre queste informazioni sotto forma di message-events. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere estratti dal server tramite un'API RESTful chiamata message-events, o puoi far sì che SparkPost invii quegli eventi a qualsiasi numero di applicazioni di raccolta che desideri. Il meccanismo di push avviene tramite webhooks ed è in tempo reale.
Attualmente, ci sono 14 diversi eventi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
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 ciascun evento insieme ai dati condivisi per ciascuno di essi.
Ciascun 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 un evento; ad esempio, solo gli eventi di apertura e clic hanno informazioni geografiche.
Una voce molto importante del messaggio di evento per questo progetto è il transmission_id. Tutte le voci del messaggio di evento per l'email originale, l'email archiviata e qualsiasi indirizzo cc e bcc condivideranno lo stesso transmission_id.
Esiste anche una voce comune chiamata message_id che avrà lo stesso id per ciascuna voce dell'email originale e quella archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per la voce message_id.
Finora sembra tutto fantastico e francamente abbastanza facile, ma ora arriva la parte difficile. Ricordate, per ottenere l'email di archivio, facciamo inviare a SparkPost un duplicato dell'email originale a un altro indirizzo email che corrisponde a qualche inbox a cui avete accesso. Ma per automatizzare questa soluzione e memorizzare il corpo dell'email, userò un'altra funzione di SparkPost chiamata Inbound Email Relaying. Cosa fa, prende tutte le email inviate a un dominio specifico e le elabora. Elaborandole, scompone l'email e crea una struttura JSON che viene poi consegnata a un'applicazione tramite un webhook. Vedere Appendice A per un esempio JSON.
Se guardi attentamente, noterai che la struttura JSON dal relay inbound è priva di un campo molto importante; il transmission_id. Mentre tutte le email in uscita hanno il transmission_id con la stessa voce che lega tutti i dati dell'email originale, archivio, cc e bcc; SparkPost non ha modo di sapere che l'email catturata dal processo inbound è collegata a una qualsiasi delle email in uscita. Il processo inbound sa semplicemente che un'email è stata inviata a un dominio specifico e di analizzare l'email. Questo è tutto. Tratterà qualsiasi email inviata a quel dominio allo stesso modo, sia che si tratti di una risposta di un cliente o dell'email di archivio inviata da SparkPost.
Quindi il trucco è; come si collega i dati in uscita al processo in entrata che ha appena ottenuto la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id univoco nel corpo dell'email. Come ciò è fatto sta a te, ma ho semplicemente creato un campo di input con il tag nascosto attivato.
Ho anche aggiunto quel campo nel blocco dei metadati dell'intestazione X-MSYS-API che viene passato a SparkPost durante l'inserimento. Questo UID nascosto finirà per essere la colla dell'intero processo, ed è un componente principale del progetto e sarà discusso in dettaglio nei post del blog successivi.
Ora che abbiamo l'UID che collegherà questo progetto e comprendiamo perché è necessario, posso iniziare a costruire la visione dell'intero progetto e dei post del blog corrispondenti.
Catturare e memorizzare l'email di archivio insieme a un'entrata di database per la ricerca/indicizzazione
Acquisire 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 rilascio del codice coprirà il processo di archivio e la memorizzazione dell'email su S3, mentre il secondo rilascio del codice coprirà la memorizzazione di tutti i dati di log da message-events in MySQL. Puoi aspettarti i primi due rilasci del codice e le voci del blog all'inizio del 2019. Se hai domande o suggerimenti, sentiti libero di farli pervenire.
Felice invio.
– Jeff
Appendice A:
