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 archivage et visualisation, mais je n'avais pas abordé le stockage réel de l'email ou des données associées, et récemment j'ai écrit un blog sur le stockage de toutes les données d'événement (par ex. quand l'email a été envoyé, ouvert, cliqué, rebondi, désinscription, etc.) sur 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 en environnements réglementés, j'ai décidé qu'il était temps de commencer un nouveau projet qui rassemble 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 de développer ce projet avec l'objectif de créer une application de stockage et de visualisation fonctionnelle pour les emails archivés et toutes les informations de journalisation produites par SparkPost. SparkPost n'a pas de système qui archive le corps des emails mais il facilite la création d'une plateforme d'archivage.
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 journalisation pertinentes dans MySQL pour un référencement croisé facile. Pour les systèmes d'archivage de 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 de restauration PostgreSQL pour garantir que vos données d'archivage sont correctement protégées. En fin de compte, c'est le point de départ pour créer une application qui permettra une recherche facile des emails archivés, puis l'affichage de ces emails avec les données d'événement (journal). Le code pour ce projet peut être trouvé dans le dépôt GitHub suivant : PHPArchivePlatform sur GitHub
Cet article d'introduction à la série de blogs va décrire le défi et établir une architecture pour la solution. Les autres blogs détailleront des parties 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 original. Pour obtenir une copie du corps de l'email, vous devez :
Capturer le corps de l'email avant d'envoyer l'email
Faire en sorte que le serveur d'email stocke une copie
Faire créer une copie par le serveur d'email pour que vous puissiez la stocker
Si le serveur d'email ajoute des éléments comme le suivi des liens ou le suivi d'ouverture, vous ne pouvez pas utiliser #1 car cela ne reflétera pas les modifications du suivi d'ouverture/clics.
Cela signifie donc que le serveur doit soit stocker l'email, soit vous offrir une copie de cet email pour le stockage. Comme SparkPost n'a pas de mécanisme de stockage pour les corps d'emails mais dispose d'un moyen de créer une copie de l'email, nous demanderons à SparkPost de nous envoyer un duplicata de l'email pour que nous le stockions dans S3.
Cela se fait en utilisant la fonctionnalité Archive de SparkPost. La fonctionnalité Archive de SparkPost donne à l'expéditeur la possibilité de dire à 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 de la liste d'archive recevront une réplique exacte du message qui a été envoyé à l'adresse RCPT TO. En particulier, tous les liens codés destinés au destinataire RCPT TO seront identiques dans les messages d'archive.
Les seules différences par rapport à l'email RCPT TO sont que certains des en-têtes seront différents puisque l'adresse cible de l'email d'archivage est différente, mais le corps de l'email sera une réplique exacte !
Si vous voulez une explication plus approfondie, voici un lien vers la documentation de SparkPost sur la création de copies d'archive d'un email.
À titre d'information, SparkPost permet en fait d'envoyer des emails à des adresses cc, bcc et d'archive. Pour cette solution, nous nous concentrons sur les adresses d'archive.
* Notez * Les emails archivés peuvent UNIQUEMENT être créés lors de l'injection d'email dans SparkPost via SMTP !
Maintenant que nous savons comment obtenir une copie de l'email original, nous devons examiner les données de journalisation qui sont produites et certaines des nuances subtiles au sein de ces données. SparkPost suit tout ce qui se passe sur ses serveurs et offre ces informations sous forme d'événements de messages. Ces événements sont stockés sur SparkPost pendant 10 jours et peuvent être extraits du serveur via une API RESTful appelée message-events, ou vous pouvez demander à SparkPost de pousser ces événements vers l'une des nombreuses applications de collecte que vous souhaitez. Le mécanisme de push se fait par webhooks et se fait en temps réel.
Actuellement, il y a 14 événements différents qui peuvent se produire pour un email. Voici une liste des événements actuels :
Rebond
ClickDelay
Livraison
Échec de génération
Rejet de génération
Ouverture initiale
InjectionLien désinscription
Liste de désinscription
Ouverture
Hors bande
Rejet de politique Plaindre de spam
* Suivez ce lien pour un guide de référence à jour et une description de chaque événement avec les données partagées pour chaque événement.
Chaque événement a de nombreux champs qui correspondent au type d'événement. Certains champs comme le transmission_id sont présents 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 clics ont des informations de géolocalisation.
Un élément d'événement de message très important pour ce projet est le transmission_id. Tous les éléments d'événement de message pour l'email original, l'email archivé, et les adresses cc et bcc partagent le même transmission_id.
Il y a également un élément commun appelé le message_id qui aura le même id pour chaque élément de l'email original et de l'email archivé. Toute adresse cc ou bcc aura son propre id pour l'entrée message_id.
Jusqu'à présent, cela semble génial et franchement assez facile, mais maintenant vient la partie compliquée. Rappelez-vous, pour obtenir l'email d'archive, nous demandons à 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 courriel entrant. Ce que cela fait, c'est que tous les emails envoyés à un domaine spécifique sont traités. En les traitant, il démonte l'email et crée une structure JSON qui est ensuite transmise à une application via un webhook. Voir l'Annexe A pour un exemple de JSON.
Si vous regardez bien attentivement, vous remarquerez que la structure JSON du relais entrant manque un champ très important : le transmission_id. Bien que tous les emails sortants aient le transmission_id avec la même entrée qui relie toutes les données de l'email original, de l'archive, de cc, et de bcc ; SparkPost n'a aucun moyen de savoir que l'email capturé par le processus d'entrée est lié à tous les emails sortants. Le processus d'entrée sait simplement qu'un email a été envoyé à un domaine spécifique et qu'il doit analyser l'email. C'est tout. Il traitera tout 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.
Le truc est donc; comment connecter les données sortantes au processus d'entrée qui vient de saisir la version archivée de l'email ? Ce que j'ai décidé de faire 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 la balise cachée activée.
J'ai également ajouté ce champ dans le bloc de métadonnées de l'en-tête X-MSYS-API qui est transmis à SparkPost lors de l'injection. Cet UID caché sera le lien de l'ensemble du processus, et est un composant principal du projet et sera discuté en profondeur dans les articles de blog suivants.
Maintenant que nous avons l'UID qui liera ce projet ensemble et comprenons pourquoi il est nécessaire, je peux commencer à construire la vision du projet global et les articles de blog correspondants.
Capturer et stocker l'email d'archive 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 simple diagramme du projet :
La première version du code couvrira le processus d'archivage 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 journalisation des message-events dans MySQL. Vous pouvez vous attendre aux deux premières versions de code et aux articles de blog au début de 2019. Si vous avez des questions ou des suggestions, n'hésitez pas à les transmettre.
Bon envoi.
– Jeff
Annexe A :
