Avec l'augmentation de l'utilisation des e-mails dans les environnements réglementaires, j'ai décidé qu'il est temps de commencer un nouveau projet qui rassemble tout cela avec des exemples de code sur la façon de stocker le corps de l'e-mail et toutes ses données associées.
Il y a environ un an, j'ai écrit un blog sur la façon de récupérer des copies d'emails pour l'archivage et la visualisation, mais je n'ai pas abordé le stockage réel de l'email ou des données connexes, et récemment, j'ai écrit un blog sur le stockage de toutes les données d'événement (c'est-à-dire quand l'email a été envoyé, ouvert, cliqué, rebondi, désabonné, etc.) d'un email à des fins d'audit, mais j'ai choisi de ne pas créer de code de support.
Avec l'augmentation de l'utilisation des emails dans les environnements réglementaires, j'ai décidé qu'il était temps de commencer un nouveau projet qui regroupe tout cela avec des exemples de code sur comment stocker le corps de l'email et toutes ses données associées. Au cours de l'année prochaine, je continuerai à développer ce projet dans le but de créer une application fonctionnelle de stockage et de visualisation pour les emails archivés et toutes les informations de journal produites par SparkPost. SparkPost n'a pas de système qui archive le corps de l'email mais permet de construire une plateforme d'archivage assez facilement.
Dans cette série de blogs, je décrirai le processus que j'ai suivi pour stocker le corps de l'email sur S3 (Amazon’s Simple Store Service) et toutes les données de log pertinentes dans MySQL pour un référencement croisé facile. Pour les systèmes d'archivage en production qui nécessitent des stratégies de sauvegarde de base de données robustes, envisagez de mettre en œuvre un processus complet de sauvegarde et restauration PostgreSQL pour vous assurer que vos données archivées sont correctement protégées. En fin de compte, il s'agit du point de départ pour construire une application qui permettra une recherche facile des emails archivés, puis l'affichage de ces emails avec les données d'événement (log). Le code de ce projet peut être trouvé dans le dépôt GitHub suivant : https://github.com/jeff-goldstein/PHPArchivePlatform
Cet article initial de la série de blogs va décrire le défi et établir une architecture pour la solution. Le reste des blogs détaillera des portions de la solution avec des exemples de code.
La première étape de mon processus était de déterminer comment j'allais obtenir une copie de l'email envoyé au destinataire d'origine. Pour obtenir une copie du corps de l'email, vous devez soit :
Capturer le corps de l'email avant d'envoyer l'email
Obtenir du serveur email qu'il stocke une copie
Demander au serveur email de créer une copie pour vous à stocker
Si le serveur de messagerie ajoute des éléments comme le suivi des liens ou l'ouverture des emails, vous ne pouvez pas utiliser #1 car cela ne reflètera pas les modifications de suivi d'ouverture/clic.
Cela signifie que soit le serveur doit stocker l'email, soit offrir d'une manière ou d'une autre une copie de cet email pour vous. Étant donné que SparkPost n'a pas de mécanisme de stockage pour les corps d'emails mais dispose d'une manière de créer une copie de l'email, nous demanderons à SparkPost de nous envoyer un duplicata de l'email à stocker sur S3.
Ceci est réalisé en utilisant la fonction Archive de SparkPost. La fonction Archive de SparkPost permet à l'expéditeur de demander à SparkPost d'envoyer un duplicata de l'email à une ou plusieurs adresses email, et d'utiliser les mêmes liens de suivi et d'ouverture que l'original. La documentation de SparkPost définit leur fonction Archive de la manière suivante :
Les destinataires dans la liste d'archive recevront une réplique exacte du message envoyé à l'adresse RCPT TO. En particulier, tous les liens encodés destinés au destinataire RCPT TO seront identiques dans les messages d'archive.
Les seules différences avec l'email RCPT TO sont que certains en-têtes seront différents puisque l'adresse cible pour l'email d'archivage est différente, mais le corps de l'email sera une réplique exacte !
Si vous souhaitez une explication plus approfondie, voici un lien vers la documentation SparkPost sur la création de copies dupliquées (ou d'archives) d'un email.
En guise de note annexe, SparkPost vous permet réellement d'envoyer des emails à des adresses cc, bcc et d'archive. Pour cette solution, nous nous concentrons sur les adresses d'archive.
* Remarque * Les emails archivés ne peuvent être créés QUE lors de l'injection d'emails dans SparkPost via SMTP !
Maintenant que nous savons comment obtenir une copie de l'email original, nous devons examiner les données de log produites et certaines des subtilités dans ces données. SparkPost suit tout ce qui se passe sur ses serveurs et offre ces informations sous forme d'événements de message. Ces événements sont stockés sur SparkPost pendant 10 jours et peuvent être extraits du serveur via une API RESTful appelée événements de message, ou vous pouvez demander à SparkPost de pousser ces événements vers n'importe quel nombre d'applications de collecte que vous souhaitez. Le mécanisme de poussée est réalisé par le biais de webhooks en temps réel.
Actuellement, il y a 14 événements différents qui peuvent arriver à un email. Voici une liste des événements actuels :
Rebond
Retard de Clic
Livraison
Échec de génération
Rejet de génération
Première ouverture
Lien Injection Désabonnement
Liste Désabonnement
Ouverture
Hors bande
Rejet de politique, Plainte pour spam
* Suivez ce lien pour un guide de référence mis à jour avec une description de chaque événement et les données partagées pour chaque événement.
Chaque événement possède de nombreux champs correspondant au type d'événement. Certains champs comme le transmission_id se trouvent dans chaque événement, mais d'autres champs peuvent être plus spécifiques à l'événement ; par exemple, seuls les événements d'ouverture et de clic comportent les informations de géolocalisation.
Un élément d'événement de message très important pour ce projet est le transmission_id. Toutes les entrées d'événements de message pour l'email original, l'email archivé, et toutes les adresses cc et bcc partageront le même transmission_id.
Il existe également une entrée commune appelée message_id qui aura le même identifiant pour chaque entrée de l'email original et de l'email archivé. Toutes les adresses cc ou bcc auront leur propre identifiant pour l'entrée message_id.
Jusqu'ici cela semble génial et franchement assez facile, mais c'est maintenant que la partie difficile commence. Rappelez-vous, afin d'obtenir l'email d'archive, nous avons demandé à SparkPost d'envoyer un duplicata de l'email original à une autre adresse email correspondant à un inbox auquel vous avez accès. Mais pour automatiser cette solution et stocker le corps de l'email, je vais utiliser une autre fonctionnalité de SparkPost appelée Relais de courrier entrant. Ce que cela fait, c'est de prendre tous les emails envoyés à un domaine spécifique et de les traiter. En les traitant, il démonte l'email et crée une structure JSON qui est ensuite livrée à une application via un webhook. Voir l'Annexe A pour un exemple de JSON.
Si vous regardez attentivement, vous remarquerez que la structure JSON du relais entrant manque d'un champ très important ; le transmission_id. Bien que tous les emails sortants aient le même transmission_id qui lie toutes les données de l'email original, de l'archive, des adresses cc et bcc ; SparkPost n'a aucun moyen de savoir que l'email capturé par le processus entrant est connecté à n'importe lequel des emails sortants. Le processus entrant sait simplement qu'un email a été envoyé à un domaine spécifique et de démêler l'email. C'est tout. Il traitera n'importe quel email envoyé à ce domaine de la même manière, qu'il s'agisse d'une réponse d'un client ou de l'email d'archive envoyé par SparkPost.
Donc, le tour de passe-passe est ; comment coller les données sortantes au processus entrant qui vient de capturer la version archivée de l'email ? Ce que j'ai décidé de faire, c'est de cacher un identifiant unique dans le corps de l'email. Comment cela est fait dépend de vous, mais j'ai simplement créé un champ d'entrée avec le tag caché activé.
J'ai également ajouté ce champ dans le bloc de métadonnées de l'en-tête X-MSYS-API qui est passé à SparkPost lors de l'injection. Cet identifiant UID caché finira par être la colle de tout le processus, et c'est un composant principal du projet et sera discuté en profondeur dans les articles de blog suivants.
Maintenant que nous avons l'UID qui va rassembler ce projet et comprenons pourquoi il est nécessaire, je peux commencer à construire la vision globale du projet et des articles de blog correspondants.
Capturer et stocker l'email archivé avec une entrée de base de données pour la recherche/indexation
Capturer toutes les données d'événement de message
Créer une application pour visualiser l'email et toutes les données correspondantes
Voici un diagramme simple du projet :
La première version du code couvrira le processus d'archive et le stockage de l'email sur S3, tandis que la deuxième version du code couvrira le stockage de toutes les données de journal des événements de message dans MySQL. Vous pouvez vous attendre à voir les deux premières versions de code et les premières entrées de blog au début de 2019. Si vous avez des questions ou des suggestions, n'hésitez pas à les faire parvenir.
Envoi Heureux.
– Jeff
Annexe A :
