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 archivage et visualisation, mais je n'ai 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 événementielles (c'est-à-dire quand l'email a été envoyé, ouvert, cliqué, rebondi, désabonné, etc.) sur 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églementaires, j'ai décidé qu'il était 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 dans le but de créer une application de stockage et de visualisation fonctionnelle 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 rend la construction d'une plateforme d'archivage assez facile.

Dans cette série de blogs, je décrirai le processus que j'ai suivi pour stocker le corps de l'email sur S3 (le service de stockage simple d'Amazon) et toutes les données de journal pertinentes dans MySQL pour une référence croisée facile. Pour les systèmes d'archivage en production nécessitant des stratégies de sauvegarde de base de données robustes, envisagez de mettre en œuvre un processus complet de sauvegarde et restauration de PostgreSQL pour garantir que vos données archivées sont correctement protégées. Finalement, c'est le point de départ pour construire une application qui permettra de rechercher facilement les emails archivés, puis d'afficher ces emails avec les données d'événement (journal). Le code de ce projet peut être trouvé dans le référentiel GitHub suivant : PHPArchivePlatform sur GitHub

Cette première entrée de la série de blogs va décrire le défi et proposer 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 a été de comprendre 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 :

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

2. Amener le serveur de messagerie à stocker une copie

3. Faire en sorte que le serveur de messagerie crée une copie pour vous permettre de la stocker
   
   

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

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

Cela se fait en utilisant la fonction d'Archive de SparkPost. La fonction d'Archive de SparkPost donne à l'expéditeur la possibilité de dire à SparkPost d'envoyer un double 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 d'Archive de la manière suivante :

Les destinataires dans la liste d'archivage recevront une réplique exacte du message qui a été 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 par rapport à l'email RCPT TO sont que certaines des en-têtes seront différentes car 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 de SparkPost sur la création de copies (ou archives) dupliquées d'un email.

En passant, SparkPost permet en fait d'envoyer des emails à des adresses cc, bcc, et d'archivage. Pour cette solution, nous nous concentrons sur les adresses d'archivage.

* 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 nuances subtiles au sein de ces données. SparkPost suit tout ce qui se passe sur ses serveurs et offre ces informations à vous 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 un nombre d'applications de collecte que vous souhaitez. Le mécanisme de push est effectué via des webhooks et se fait en temps réel.

Actuellement, il existe 14 événements différents qui peuvent se produire pour un email.  Voici une liste des événements actuels :

• Rebondissement

• Retard de clic

• Livraison

• Échec de génération

• Rejet de génération

• Première ouverture

• Lien d'injection désabonnement

• Désabonnement de liste

• Ouverture

• Hors bande

• Rejet de politique Plainte de spam

  
  

* Suivez ce lien pour un guide de référence à jour décrivant chaque événement ainsi que les données qui sont 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 se trouvent dans chaque événement, mais d'autres champs peuvent être plus spécifiques à un événement ; par exemple, seuls les événements d'ouverture et de clic ont des informations de géolocalisation.

Une entrée d'événement de message très importante 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 y a aussi une entrée commune appelée le 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 du message_id .

Jusqu'ici cela semble génial et franchement assez facile, mais maintenant vient la partie difficile. Souvenez-vous, afin d'obtenir l'email archivé, nous demandons à SparkPost d'envoyer un duplicata de l'email original à une autre adresse email correspondant à une boîte de réception à laquelle vous avez accès. Mais afin d'automatiser cette solution et de stocker le corps de l'email, je vais utiliser une autre fonctionnalité de SparkPost appelée Relais d'Email Entrant. Ce qu'il 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 envoyé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 est manquante d'un champ très important ; le transmission_id. Alors que tous les emails sortants ont le transmission_id provenant de 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 entrant est connecté à l'un des emails sortants. Le processus entrant sait simplement qu'un email a été envoyé à un domaine spécifique et 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é depuis SparkPost.

Alors l'astuce est ; comment connectez-vous les données sortantes au processus entrant qui vient de saisir 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 de saisie 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 passé à SparkPost lors de l'injection. Cet UID caché finira par être le lien de tout le processus, et est un composant principal du projet qui sera discuté en profondeur dans les prochains articles de blog.

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

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

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

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

Voici un schéma simple 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 journal des événements de message dans MySQL. Vous pouvez vous attendre aux deux premières versions de code et 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: