Construire un système d'archivage des e-mails : les défis et bien sûr la solution – Partie 1

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 véritable stockage de l'email ou des données connexes. Récemment, j'ai écrit un blog sur le stockage de toutes les données d'événements (c'est-à-dire quand l'email a été envoyé, ouvert, cliqué, rejeté, désinscrit, etc.) d'un email dans le but d'audit, mais j'ai choisi de ne pas créer de code support.

Avec l'augmentation de l'utilisation des emails dans les environnements réglementés, j'ai décidé qu'il est temps de commencer un nouveau projet qui regroupe tout cela avec des exemples de code sur la façon de 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 afin 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 des emails mais facilite la construction d'une plateforme d'archivage.

Dans cette série de blogs, je décrirai le processus que j'ai suivi pour stocker le corps des emails sur S3 (Amazon’s Simple Store Service) et toutes les données de journal 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 de PostgreSQL pour garantir que vos données d'archivage soient correctement protégées. En fin de compte, c'est le point de départ pour construire une application qui permettra une recherche facile des emails archivés, puis affichera ces emails avec les données d'événement (journal). Le code de ce projet peut être trouvé dans le dépôt GitHub suivant : PHPArchivePlatform sur GitHub

Cette première entrée de la série de blogs va décrire le défi et exposer une architecture pour la solution. Le reste des blogs détaillera des parties de la solution avec des exemples de code.

La première étape de mon processus était de comprendre comment j'allais obtenir une copie de l'email envoyé au destinataire initial. Pour obtenir une copie du corps de l'email, vous devez soit :

Options de Capture du Corps de l'Email

1. Capturer le corps de l'email avant d'envoyer l'email

2. Amener le serveur de messagerie à stocker une copie

3. Faire créer une copie par le serveur de messagerie pour vous permettre de le stocker

Si le serveur de messagerie ajoute des éléments comme le suivi des liens ou l'ouverture des messages, vous ne pouvez pas utiliser l'option #1 car elle ne reflétera pas les changements de suivi d'ouverture/clique.

Cela signifie que le serveur doit soit stocker l'email soit d'une manière ou d'une autre vous offrir une copie de cet email pour le stockage. Comme SparkPost n'a pas de mécanisme de stockage pour les corps d'email mais a un moyen de créer une copie de l'email, nous demanderons à SparkPost de nous envoyer un doublon de l'email pour le stocker sur S3.

Ceci est fait en utilisant la fonctionnalité d'archive de SparkPost. La fonctionnalité d'archive de SparkPost permet à l'expéditeur de demander à SparkPost d'envoyer un doublon de l'email à une ou plusieurs adresses électroniques et d'utiliser les mêmes liens de suivi et d'ouverture que l'original. La documentation de SparkPost définit leur fonctionnalité d'archive comme suit :

Les destinataires de 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.

La seule différence par rapport à l'email RCPT TO est 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 SparkPost sur la création de copies duplicata (ou archives) d'un email.

En passant, SparkPost vous permet 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 journal qui sont produites et certaines des subtilités dans ces données. SparkPost suit tout ce qui se passe sur ses serveurs et offre cette information sous forme d'événements de messages. Ces événements sont stockés sur SparkPost pendant 10 jours et peuvent être récupérés depuis le serveur via une API RESTful appelée message-events, ou vous pouvez demander à SparkPost de pousser ces événements vers un certain nombre d'applications de collecte de votre choix. Le mécanisme de poussée est réalisé via webhooks et est fait en temps réel.

Actuellement, il y a 14 événements différents qui peuvent se produire sur un email. Voici la liste des événements actuels :

• Bounce

• Retard de Clic

• Livraison

• Échec de Génération

• Rejet de Génération

• Première Ouverture

• Lien d'Injection Désinscription

• Liste de Désinscription

• Ouverture

• Hors Bande

• Rejet par PolitiqueRéclamation de Spam

  
  

* Suivez ce lien pour un guide de référence à jour décrivant chaque événement ainsi que les données partagées pour chaque événement.

Chaque événement contient de nombreux champs qui correspondent 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 ont des informations de géolocalisation.

Identifiants Utilisés dans le Système d'Archivage

Un élément très important de l'événement de message dans ce projet est le transmission_id. Toutes les entrées d'événement de message pour l'email original, l'email archivé, et toutes les adresses cc et bcc partageront le même transmission_id.

Il y a également une entrée commune appelée message_id qui aura le même ID pour chaque entrée 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 bien et plutôt simple, mais vient maintenant la partie complexe. Souvenez-vous, pour obtenir l'email d'archive, nous avons SparkPost envoyer un doublon de l'email original à une autre adresse email qui correspond à une boîte de réception à laquelle vous avez accès. Mais pour automatiser cette solution et stocker le corps de l'email, je vais utiliser une autre fonction de SparkPost appelée Relais de Courrier Entrant. Ce que cela fait, c'est prendre tous les emails envoyés à un domaine spécifique et 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 bien, 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 lie toutes les données de l'email original, archive, cc, et bcc ; SparkPost n'a aucun moyen de savoir que l'email capturé par le processus d'entrée est connecté à l'un des emails sortants. Le processus entrant sait seulement qu'un email a été envoyé à un domaine spécifique et doit être analysé. 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 défi est donc ; comment lier 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 est à vous, mais j'ai simplement créé un champ d'entrée avec l'attribut caché activé.

<input name="ArchiveCode" type="hidden" value="<<UID>>">

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é finira par être la colle du processus entier, et est un élément principal du projet qui sera discuté en profondeur dans les prochains articles de blog.

Maintenant que nous avons l'UID qui reliera ce projet ensemble et comprenons pourquoi il est nécessaire, je peux commencer à construire la vision d'ensemble du projet et les articles de blog correspondants.

1. Capteur et stockage de l'email d'archive avec une entrée de base de données pour la recherche/indexation

2. Capture de toutes les données d'événement de message

3. Créer une application pour visualiser l'email et toutes les données correspondantes

Voici un schéma simple du projet :

La première livraison de code couvrira le processus d'archivage et le stockage de l'email sur S3, tandis que la deuxième livraison de code concernera le stockage de toutes les données de journal des message-events dans MySQL. Vous pouvez vous attendre aux deux premières livraisons de code et entrées de blog au début de 2019. Si vous avez des questions ou des suggestions, n'hésitez pas à les transmettre.

Bonne Envoi.
– Jeff

Annexe A :