Il y a environ un an, j'ai écrit un blog sur la façon de récupérer des copies d'e-mails pour archivage et consultation, mais je n'ai pas abordé le stockage réel de l'e-mail ou des données associées. Récemment, j'ai écrit un blog sur le stockage de toutes les données liées aux événements (c'est-à-dire quand l'e-mail a été envoyé, ouvert, cliqué, les rebonds, les désinscriptions, etc.) concernant un e-mail dans le but d'auditer, mais j'ai choisi de ne pas créer de code d'accompagnement.

Avec l’augmentation de l'utilisation des e-mails dans des 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'e-mail 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 consultation fonctionnelle pour les e-mails archivés et toutes les informations de journal produites par SparkPost. SparkPost n'a pas de système qui archive le corps des e-mails, mais il est assez facile de créer une plateforme d'archivage.

Dans cette série de blogs, je décrirai le processus par lequel je suis passé pour stocker le corps de l'e-mail sur S3 (le Simple Storage Service d'Amazon) et toutes les données de journal pertinentes dans MySQL pour un référencement croisé facile.  En fin de compte, c'est le point de départ pour construire une application qui permettra une recherche facile des e-mails archivés, puis l'affichage de ces e-mails ainsi que des données des événements (journal). Le code pour ce projet peut être trouvé dans le dépôt GitHub suivant : https://github.com/jeff-goldstein/PHPArchivePlatform

Cette première entrée 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 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'e-mail envoyé au destinataire d'origine. Pour obtenir une copie du corps de l'e-mail, vous devez soit :

1. Capturer le corps de l'e-mail avant d'envoyer l'e-mail

2. Faire en sorte que le serveur de messagerie stocke une copie

3. Demander au serveur de messagerie de créer une copie à stocker

Si le serveur d'e-mails ajoute des éléments tels que le suivi des liens ou le suivi des ouvertures, vous ne pouvez pas utiliser #1 car cela ne reflétera pas les changements de suivi des ouvertures/clicks.

Cela signifie que soit le serveur doit stocker l'e-mail, soit offrir d'une manière ou d'une autre une copie de cet e-mail pour vous à stocker. Étant donné que SparkPost n'a pas de mécanisme de stockage pour les corps d'e-mail mais a la possibilité de créer une copie de l'e-mail, nous allons demander à SparkPost de nous envoyer un duplicata de l'e-mail à stocker dans S3.

Ceci est réalisé en utilisant la fonctionnalité Archive de SparkPost. La fonctionnalité Archive de SparkPost donne à l'expéditeur la possibilité de demander à SparkPost d'envoyer un duplicata de l'e-mail à une ou plusieurs adresses e-mail et d'utiliser les mêmes liens de suivi et d'ouverture que l'original. La documentation de SparkPost définit sa fonctionnalité 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'e-mail RCPT TO sont que certains des en-têtes seront différents puisque l'adresse cible pour l'e-mail d'archivage est différente, mais le corps de l'e-mail 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 dupliquées (ou archivées) d'un e-mail.

En passant, SparkPost vous permet en fait d'envoyer des e-mails vers des adresses cc, bcc et d'archivage. Pour cette solution, nous nous concentrons sur les adresses d'archivage.

* Remarque * Les e-mails archivés ne peuvent ÊTRE créés que lorsque les e-mails sont injectés dans SparkPost via SMTP !

Maintenant que nous savons comment obtenir une copie de l'e-mail original, nous devons examiner les données de journal produites et certaines des subtilités de ces données. SparkPost suit tout ce qui se passe sur ses serveurs et vous 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 d'envoyer ces événements à un certain nombre d'applications de collecte de votre choix.  Le mécanisme de push se fait via des webhooks et est réalisé en temps réel.

Actuellement, il y a 14 événements différents qui peuvent arriver à un e-mail.  Voici une liste des événements actuels :

• Rebond

• Délai de clic

• Livraison

• Échec de génération

• Rejet de génération

• Ouverture initiale

• Désinscription par InjectionLink

• Désinscription de la liste

• Ouvert

• Hors bande

• Rejet de politique Plaintes 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 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 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.  Tous les enregistrements d'événements de message pour l'e-mail original, l'e-mail archivé, et toute adresse cc et bcc partageront le même transmission_id.

Il y a aussi une entrée commune appelée message_id qui aura le même identifiant pour chaque entrée de l'e-mail original et de l'e-mail archivé. Toute adresse cc ou bcc aura son propre identifiant pour l'entrée message_id .

Jusqu'à présent, cela semble super, et franchement assez facile, mais la partie difficile arrive maintenant. Rappelez-vous, pour obtenir l'e-mail archivés, nous demandons à SparkPost d'envoyer un duplicata de l'e-mail original à une autre adresse e-mail correspondant à une boîte de réception à laquelle vous avez accès. Mais pour automatiser cette solution et stocker le corps de l'e-mail, je vais utiliser une autre fonctionnalité de SparkPost appelée Relais d'e-mail entrant. Ce que cela fait, c'est de prendre tous les e-mails envoyés à un domaine spécifique et de les traiter. En les traitant, il décompose l'e-mail 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 un champ très important : le transmission_id. Bien que tous les e-mails sortants aient le transmission_id avec la même entrée liant toutes les données de l'e-mail original, de l'archive, des adresses cc et bcc ; SparkPost n'a aucun moyen de savoir que l'e-mail capturé par le processus entrant est connecté à l'un des e-mails sortants. Le processus entrant sait simplement qu'un e-mail a été envoyé à un domaine spécifique et de l'analyser. C'est tout. Il traitera tout e-mail envoyé à ce domaine de la même manière, qu'il s'agisse d'une réponse d'un client ou de l'e-mail d'archive envoyé par SparkPost.

Donc, la question est ; comment coller les données sortantes au processus entrant qui vient de saisir la version archivée de l'e-mail ? Ce que j'ai décidé de faire est de cacher un identifiant unique dans le corps de l'e-mail. Comment cela est fait dépend de vous, mais j'ai simplement créé un champ d'entrée avec le tag caché activé.

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

J'ai également ajouté ce champ au bloc de métadonnées de l'en-tête X-MSYS-API qui est passé à SparkPost lors de l'injection. Cette UID cachée sera l'élément qui reliera tout le processus, et c'est un élément principal du projet qui sera discuté en profondeur dans les blogs suivants.

Maintenant que nous avons l'UID qui reliera ce projet et comprenons pourquoi il est nécessaire, je peux commencer à construire la vision du projet global et des blogs correspondants.

1. Capturer et stocker l'e-mail d'archive ainsi qu'une entrée de base de données pour la recherche/l'indexation

2. Capturer toutes les données des événements de message

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

Voici un diagramme simple du projet :

Le premier lot de code couvrira le processus d'archivage et le stockage de l'e-mail sur S3, tandis que le deuxième lot de code couvrira le stockage de toutes les données de journal des événements de message dans MySQL. Vous pouvez vous attendre aux deux premiers lots de code et aux entrées de blog début 2019.  Si vous avez des questions ou des suggestions, n'hésitez pas à les partager.

Bon envoi.

– Jeff

Annexe A :