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 archiviarle e visualizzarle, ma non ho affrontato l'effettivo salvataggio delle email o dei dati correlati. Recentemente ho scritto un blog su come salvare tutti i dati degli eventi (ad esempio, quando l'email è stata inviata, aperture, clic, rimbalzi, cancellazioni, etc) 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 raccolga tutto questo insieme a esempi di codice su come salvare il corpo email e tutti i dati associati. Nel corso del prossimo anno, continuerò a sviluppare questo progetto con l'obiettivo di creare un'applicazione di archiviazione e visualizzazione funzionale per email archiviate e tutte le informazioni di registro prodotte da SparkPost. SparkPost non dispone di un sistema che archivia il corpo delle email ma rende abbastanza semplice la creazione di una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per memorizzare il corpo email su S3 (Amazon's Simple Store Service) e tutti i dati di registro rilevanti in MySQL per una facile consultazione incrociata. Per i sistemi di archiviazione di produzione che richiedono strategie di backup del database robuste, considerare di implementare un processo completo di backup e ripristino PostgreSQL per garantire che i dati di archiviazione siano adeguatamente protetti. In definitiva, questo è il punto di partenza per costruire un'applicazione che consenta una facile ricerca delle email archiviate, quindi visualizzare quelle email insieme ai dati dell'evento (registro). 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 elaborerà un'architettura per la soluzione. Il resto dei blog dettaglierebbe porzioni 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 o:
Catturare il corpo dell'email prima di inviare l'email
Far sì che il server di posta memorizzi una copia
Far creare al server di posta una copia da conservare
Se il server di posta aggiunge elementi come il tracciamento dei link o delle aperture, non puoi utilizzare #1 perché non rifletterà i cambiamenti di tracciamento di apertura/clic.
Ciò significa che o il server deve memorizzare l'email o in qualche modo offrire una copia di quella email per la conservazione. Dal momento che 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 un duplicato dell'email da archiviare su S3.
Questo viene fatto utilizzando la funzione di Archiviazione di SparkPost. La funzione di Archiviazione di SparkPost consente al mittente di dire a SparkPost di inviare un duplicato dell'email a uno o più indirizzi email e utilizzare gli stessi link di tracciamento e apertura dell'originale. La documentazione di SparkPost definisce la loro funzione di Archiviazione nel modo seguente:
I destinatari nella lista di archiviazione riceveranno una replica esatta del messaggio inviato all'indirizzo RCPT TO. In particolare, eventuali link codificati destinati al destinatario RCPT TO saranno identici nei messaggi di archiviazione
L'unica differenza rispetto all'email RCPT TO è che alcuni degli header saranno diversi 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 email in cc, bcc e archiviazione. Per questa soluzione, ci concentriamo sugli indirizzi di archiviazione.
* Nota * Le email archiviate possono essere CREATE SOLO inserendo email in SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo esaminare i dati di registro prodotti e alcune delle sottili sfumature all'interno di quei dati. SparkPost traccia tutto ciò che accade sui suoi server e offre queste informazioni a te sotto forma di eventi dei messaggi. Questi eventi sono memorizzati su SparkPost per 10 giorni e possono essere prelevati 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 push viene eseguito tramite webhook ed è fatto in tempo reale.
Attualmente, ci sono 14 diversi eventi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
Rimbalzo
ClickDelay
Consegna
Errore di Generazione
Rifiuto di Generazione
Apertura Iniziale
Link di Iniezione Disiscrizione
Disiscrizione da Lista
Apertura
Fuori Band
Rifiuto di Politica Reclamo Spam
* Segui questo link per una guida di riferimento aggiornata con 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 per l'evento; ad esempio, solo gli eventi di apertura e clic hanno informazioni geografiche.
Una voce di evento di messaggio molto importante per questo progetto è il transmission_id. Tutte le voci di evento di messaggio 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 dell'email archiviata. Qualsiasi indirizzo email cc o bcc avrà il proprio id per la voce message_id.
Finora sembra fantastico e francamente abbastanza semplice, ma ora arriva la parte difficile. Ricorda, per ottenere l'email di archivio, facciamo inviare un duplicato dell'email originale da SparkPost a un altro indirizzo email corrispondente a una inbox a cui hai accesso. Ma per automatizzare questa soluzione e salvare il corpo dell'email, userò un'altra funzione di SparkPost chiamata Inbound Email Relaying. Ciò che fa è prendere tutte le email inviate a un determinato dominio e processarle. Elaborandole, smonta 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 con molta attenzione, noterai che la struttura JSON del relay in entrata manca 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 in entrata è collegata a una qualsiasi delle email in uscita. Il processo in entrata sa semplicemente che è stata inviata un'email a un dominio specifico e di analizzare l'email. E basta. Tratterà qualsiasi email inviata a quel dominio allo stesso modo, sia esso una risposta da un cliente o l'email archivio inviata da SparkPost.
Quindi il trucco è; come si collega i dati in uscita al processo in entrata che ha appena catturato la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un ID unico nel corpo dell'email. Come ciò viene fatto dipende da te, ma ho semplicemente creato un campo di input con l'attributo nascosto attivato.
Ho anche aggiunto quel campo nel blocco di metadati dell'header X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto sarà la colla per l'intero processo ed è un componente principale del progetto e sarà discusso in profondità nei post del blog seguenti.
Ora che abbiamo l'UID che collegherà questo progetto e comprendiamo perché è necessario, posso iniziare a costruire la visione del progetto complessivo e i relativi post del blog.
Catturare e memorizzare l'email di archivio insieme a un'entrata nel database per la ricerca/indicizzazione
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:
La prima porzione di codice coprirà il processo di archiviazione e memorizzazione dell'email su S3, mentre la seconda porzione di codice riguarderà la memorizzazione di tutti i dati di log dagli message-events in MySQL. Puoi aspettarti le prime due porzioni di codice e i post del blog nei primi mesi del 2019. Se hai domande o suggerimenti, non esitare a inviarli.
Buon invio.
– Jeff
Appendice A:
