Costruire un sistema di archiviazione delle email: le sfide e naturalmente la soluzione – Parte 1

Circa un anno fa ho scritto un blog su come recuperare copie delle email per archiviazione e visualizzazione, ma non ho affrontato la questione dell'effettiva memorizzazione dell'email o dei dati correlati, e recentemente ho scritto un blog su come memorizzare tutti i dati dell'evento (ovvero quando l'email è stata inviata, aperture, clic, rimbalzi, cancellazioni dell'iscrizione, ecc.) su un'email per scopi di auditing, ma ho scelto di non creare alcun codice di supporto.

Con l'aumento dell'uso dell'email in ambienti normativi, ho deciso che è il momento di avviare un nuovo progetto che raccolga tutto ciò insieme a campioni di codice su come memorizzare il corpo dell'email e tutti i suoi dati associati. Nel prossimo anno, continuerò a costruire su questo progetto con l'obiettivo di creare una applicazione funzionante per la memorizzazione e visualizzazione delle email archiviate e 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 memorizzare il corpo dell'email su S3 (Amazon’s Simple Store Service) e tutti i dati di log rilevanti in MySQL per un facile incrocio delle referenze. Per i sistemi di archiviazione in produzione che richiedono strategie robuste di backup dei database, considera di implementare un processo completo di backup e ripristino PostgreSQL per garantire che i tuoi dati di archiviazione siano correttamente protetti. In definitiva, questo è il punto di partenza per costruire un'applicazione che consenta la facile ricerca delle email archiviate, quindi visualizzare quelle email insieme ai dati dell'evento (log). 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 delinerà un'architettura per la soluzione. Il resto dei blog dettagliarà parti della soluzione insieme a campioni 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:

1. Catturare il corpo dell'email prima di inviare l'email

2. Far sì che il server email memorizzi una copia

3. Far sì che il server email crei una copia per te da memorizzare
   
   

Se il server email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non puoi utilizzare il #1 perché non rifletterà le modifiche di tracciamento delle aperture/clic.

Ciò significa che il server deve memorizzare l'email o in qualche modo offrire una copia di quella email a te per la memorizzazione. 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 è fatto usando la funzione Archive di SparkPost. La funzione Archive di SparkPost dà al mittente la possibilità 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 Archive nel seguente modo:

I destinatari nella lista di archivio riceveranno una replica esatta del messaggio che è stato inviato all'indirizzo RCPT TO. In particolare, qualsiasi link codificato destinato al destinatario RCPT TO sarà identico nei messaggi di archivio

Le uniche differenze rispetto all'email RCPT TO sono 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 archivio) di un'email.

Come nota a margine, SparkPost in realtà ti permette di inviare email a indirizzi cc, bcc e di archivio. Per questa soluzione, ci concentriamo sugli indirizzi di archivio.

* Avviso * 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 osservare i dati di log che vengono prodotti e alcune delle sfumature sottili all'interno di quei dati. SparkPost traccia tutto ciò che accade sui suoi server e offre quell'informazione a te sotto forma di eventi del messaggio. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere estratti dal server tramite un'API RESTful chiamata message-events, oppure puoi far sì che SparkPost spedisca quegli eventi a un numero qualsiasi di applicazioni di raccolta che desideri. Il meccanismo di push è fatto tramite webhook ed è eseguito 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 ogni 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 open e clic hanno informazioni geografiche.

Un elemento molto importante del messaggio-evento per questo progetto è il transmission_id. Tutti gli elementi del messaggio-evento per l'email originale, l'email archiviata, e qualsiasi indirizzo cc e bcc condivideranno lo stesso transmission_id.

C'è anche un elemento comune chiamato 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'elemento message_id.

Finora questo sembra ottimo e, francamente, abbastanza facile, ma ora arriva la parte difficile. Ricorda, per ottenere l'email di archivio, facciamo in modo che SparkPost invii un duplicato dell'email originale a un altro indirizzo email che corrisponde a una casella di posta a cui hai accesso. Ma al fine di automatizzare questa soluzione e memorizzare il corpo dell'email, utilizzerò un'altra funzione di SparkPost chiamata Relay Email Inbound. Quello che fa, è prendere tutte le email inviate a un dominio specifico e processarle. Processandole, smonta l'email e crea una struttura JSON che viene poi inviata a un'applicazione tramite un webhook. Vedi l'Appendice A per un esempio di JSON.

Se guardi attentamente, noterai che la struttura JSON dal relé di input manca un campo molto importante; la transmission_id. Mentre tutte le email in uscita hanno la transmission_id con la stessa voce che lega tutti i dati dall'email originale, archivio, cc e bcc indirizzi; SparkPost non ha modo di sapere che l'email catturata dal processo in entrata è collegata a qualsiasi delle email in uscita. Il processo in entrata sa semplicemente che un'email è stata inviata a un dominio specifico e analizzare l'email. Questo è tutto. Tratterà qualsiasi email inviata a quel dominio nello stesso modo, sia che si tratti di una risposta da un cliente o dell'email di archivio inviata da SparkPost.

Quindi l'astuzia è: 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 univoco nel corpo dell'email. Come questo viene fatto dipende da te, ma 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 metadata dell'intestazione X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto finirà per essere il collante per l'intero processo ed è un componente principale del progetto, sarà discusso in profondità nei post di blog seguenti.

Ora che abbiamo l'UID che collegherà questo progetto e capiamo perché è necessario, posso iniziare a costruire la visione del progetto globale e i post di blog corrispondenti.

1. Catturare e memorizzare l'email di archivio insieme a una voce di database per la ricerca/la indicizzazione

2. Catturare tutti i dati degli eventi del messaggio

3. Creare un'applicazione per visualizzare l'email e tutti i dati corrispondenti

Ecco un semplice diagramma del progetto:

Il primo gruppo di codice coprirà il processo di archiviazione e memorizzazione dell'email su S3, mentre il secondo gruppo di codice coprirà la memorizzazione di tutti i dati di log degli eventi del messaggio in MySQL. Puoi aspettarti i primi due gruppi di codice e voci di blog nel primo trimestre del 2019. Se hai domande o suggerimenti, non esitare a comunicarli.

Buon invio.
– Jeff

Appendice A: