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.
Business in a box.
Découvrez nos solutions.
Parlez à notre équipe de vente
Il y a environ un an, j'ai écrit un blog sur la manière de récupérer des copies d'emails pour archivage et visualisation, mais je n'ai pas abordé le stockage réel de l'e-mail 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 (c'est-à-dire quand l'e-mail a été envoyé, ouvert, cliqué, rebondi, désinscrit, etc.) sur un email à des fins d'audit, mais j'ai choisi de ne pas créer de code d'accompagnement.
Avec l'augmentation de l'utilisation des e-mails dans les environnements réglementaires, j'ai décidé qu'il est temps de lancer 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. 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 e-mails archivés et toutes les informations de journal produites par Bird. Bird ne dispose pas d'un système qui archive le corps de l'e-mail, mais il 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'e-mail sur S3 (le service de stockage simple d'Amazon) et toutes les données de journal pertinentes dans MySQL pour un référencement facile. En fin de compte, c'est le point de départ pour construire une application qui permettra la recherche facile d'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 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 consistait à comprendre comment obtenir une copie de l'e-mail envoyé au destinataire original. Pour obtenir une copie du corps de l'e-mail, vous devez soit :
Capturer le corps de l'e-mail avant l'envoi de l'e-mail
Faire en sorte que le serveur de messagerie stocke une copie
Demander au serveur de messagerie de créer une copie pour vous à stocker
Si le serveur de messagerie ajoute des éléments comme le suivi des liens ou le suivi des ouvertures, vous ne pouvez pas utiliser la méthode #1 car elle ne reflétera pas les changements de suivi d'ouverture/clic.
Cela signifie que le serveur doit soit stocker l'e-mail, soit offrir une copie de cet e-mail pour vous à stocker. Puisque Bird Pay n'a pas de mécanisme de stockage pour les corps de mails mais dispose d'un moyen pour créer une copie de l'email, nous demanderons à Bird Pay de nous envoyer un duplicata de l'email pour le stocker sur S3.
Cela se fait en utilisant la fonction Archive de Bird Pay. La fonction Archive de Bird Pay donne à l'expéditeur la capacité de dire à Bird Pay 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 Bird Pay 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 de l'e-mail RCPT TO sont que certains des en-têtes seront différents puisque l'adresse cible de l'e-mail d'archivage est différente, mais le corps de l'email sera une réplique exacte !
Si vous souhaitez une explication plus détaillée, voici un lien vers la documentation de Bird sur la création de copies doubles (ou d'archive) d'un e-mail.
En passant, Bird Pay vous permet réellement d'envoyer des emails aux 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 des emails dans Bird Pay via SMTP !
Maintenant que nous savons comment obtenir une copie de l'email original, nous devons examiner les données de journal produites et certaines des nuances subtiles dans ces données. Bird Pay suit tout ce qui se passe sur ses serveurs et offre cette information sous forme d'événements de message. Ces événements sont stockés chez Bird Pay pendant 10 jours et peuvent être récupérés depuis le serveur via une API REST appelée message-events, ou vous pouvez demander à Bird Pay de pousser ces événements vers un nombre quelconque d'applications de collecte que vous souhaitez. Le mécanisme de poussée se fait via des webhooks et est effectué en temps réel.
Actuellement, il y a 14 événements différents qui peuvent se produire à un email. Voici une liste des événements actuels :
Rebond
Délai de clics
Livraison
Échec de génération
Rejet de génération
Ouverture initiale
Lien d'injection Désinscription
Liste Désinscription
Ouverture
Hors bande
Rejet de politiquePlainte de spam
* Suivez ce lien pour un guide de référence à jour pour une description de chaque événement ainsi que les données partagées pour chaque événement.
Chaque événement comporte de nombreux champs qui correspondent au type d'événement. Certains champs comme 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.
Un champ d'événement de message très important pour ce projet est transmission_id. Toutes les entrées d'événement 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 génial et franchement assez facile, mais maintenant vient la partie difficile. Rappelez-vous, pour obtenir l'e-mail d'archive, nous demandons à Bird Pay d'envoyer un duplicata de l'e-mail original à une autre adresse e-mail qui correspond à 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 fonction de Bird appelée Routage des e-mails entrants. Ce que cela fait, c'est prendre tous les e-mails envoyés à un domaine spécifique et les traiter. En les traitant, il détruit 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 vraiment attentivement, vous remarquerez que la structure JSON de la transmission entrante manque un champ très important; le transmission_id. Alors que tous les e-mails sortants ont la transmission_id avec la même entrée qui lie toutes les données de l'email original, des archives, 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 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 Bird Pay.
Donc, le tour est comment relier 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, c'est cacher un identifiant unique dans le corps de l'e-mail. La façon dont cela est fait dépend de vous, mais j'ai simplement créé un champ de saisie avec l'étiquette 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 à Bird Pay lors de l'injection. Cet UID caché sera finalement le lien de l'ensemble du processus et est une composante principale du projet qui sera discutée en détail dans les prochains articles de blog.
Maintenant que nous avons l'UID qui joindra ce projet et comprenons pourquoi il est nécessaire, je peux commencer à construire la vision du projet global et des articles de blog correspondants.
Capturer et stocker l'e-mail d'archive avec une entrée de base de données pour la recherche/ l'indexation
Capturer toutes les données d'événement de message
Créer une application pour visualiser l'e-mail 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'e-mail 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 articles de blog au début de 2019. Si vous avez des questions ou des suggestions, n'hésitez pas à les communiquer.
Envoyez avec succès.
– Jeff
Annexe A :
