Construyendo un sistema de archivo de correo electrónico: los desafíos y, por supuesto, la solución – Parte 1

Hace aproximadamente un año, escribí un blog sobre cómo recuperar copias de correos electrónicos para archivo y visualización, pero no abordé el almacenamiento real del correo electrónico o los datos relacionados, y recientemente escribí un blog sobre el almacenamiento de todos los datos de eventos (es decir, cuándo se envió el correo electrónico, aperturas, clics, rebotes, bajas, etc.) de un correo electrónico con fines de auditoría, pero opté por no crear ningún código de soporte.

Con el aumento del uso de correos electrónicos en entornos regulatorios, he decidido que es hora de comenzar un nuevo proyecto que reúna todo esto con ejemplos de código sobre cómo almacenar el cuerpo del correo electrónico y todos sus datos asociados. A lo largo del próximo año, continuaré construyendo sobre este proyecto con el objetivo de crear una aplicación funcional de almacenamiento y visualización para correos electrónicos archivados y toda la información de registro producida por SparkPost. SparkPost no tiene un sistema que archive el cuerpo del correo electrónico, pero facilita bastante la construcción de una plataforma de archivo.

En esta serie de blogs, describiré el proceso que seguí para almacenar el cuerpo del correo electrónico en S3 (el Servicio de Almacenamiento Simple de Amazon) y todos los datos de registro relevantes en MySQL para una fácil referencia cruzada. Para sistemas de archivado en producción que requieren estrategias robustas de respaldo de base de datos, considere implementar un proceso comprensivo de backup y restauración de PostgreSQL para asegurar que sus datos de archivo estén debidamente protegidos. En última instancia, este es el punto de inicio para construir una aplicación que permita la búsqueda fácil de correos electrónicos archivados y luego mostrar esos correos junto con los datos de eventos (registro). El código para este proyecto se puede encontrar en el siguiente repositorio de GitHub: PHPArchivePlatform en GitHub

Esta primera entrada de la serie de blogs va a describir el desafío y presentar una arquitectura para la solución. El resto de los blogs detallará partes de la solución junto con ejemplos de código.

El primer paso en mi proceso fue entender cómo iba a obtener una copia del correo electrónico enviado al destinatario original. Para obtener una copia del cuerpo del correo electrónico, necesitas ya sea:

1. Capturar el cuerpo del correo electrónico antes de enviar el correo

2. Hacer que el servidor de correo almacene una copia

3. Hacer que el servidor de correo cree una copia para que la almacenes
   
   

Si el servidor de correo está agregando elementos como rastreo de enlaces o aperturas, no puedes usar el #1 porque no reflejará los cambios de rastreo de apertura/clic.

Eso significa que el servidor tiene que almacenar el correo o de alguna manera ofrecer una copia de ese correo para que lo almacenes. Dado que SparkPost no tiene un mecanismo de almacenamiento para cuerpos de correo electrónico pero sí tiene una forma de crear una copia del correo electrónico, haremos que SparkPost nos envíe un duplicado del correo electrónico para que lo almacenemos en S3.

Esto se hace utilizando la función Archive de SparkPost. La función Archive de SparkPost le da al remitente la capacidad de decirle a SparkPost que envíe un duplicado del correo electrónico a una o más direcciones de correo electrónico y use los mismos enlaces de seguimiento y apertura que el original. La documentación de SparkPost define su función Archive de la siguiente manera:

Los destinatarios en la lista de archivo recibirán una réplica exacta del mensaje que se envió a la dirección RCPT TO. En particular, cualquier enlace codificado destinado al destinatario RCPT TO será idéntico en los mensajes del archivo

Las únicas diferencias con el correo RCPT TO son que algunos de los encabezados serán diferentes ya que la dirección de destino para el correo de archivo es diferente, pero el cuerpo del correo será una réplica exacta!

Si deseas una explicación más profunda, aquí tienes un enlace a la documentación de SparkPost sobre cómo crear copias duplicadas (o de archivo) de un correo electrónico.

Como nota al margen, SparkPost realmente te permite enviar correos electrónicos a direcciones de cc, bcc y archivo. Para esta solución, nos centramos en las direcciones de archivo.

* Aviso * ¡Los correos electrónicos archivados SOLO pueden crearse al inyectar correos electrónicos en SparkPost a través de SMTP!

Ahora que sabemos cómo obtener una copia del correo electrónico original, necesitamos ver los datos de registro que se producen y algunas de las sutiles particularidades dentro de esos datos. SparkPost rastrea todo lo que sucede en sus servidores y ofrece esa información en forma de eventos de mensaje. Esos eventos se almacenan en SparkPost durante 10 días y se pueden extraer del servidor a través de una API RESTful llamada message-events, o puedes hacer que SparkPost envíe esos eventos a cualquier número de aplicaciones recopiladoras que desees. El mecanismo de empuje se realiza a través de webhooks y se hace en tiempo real.

Actualmente, hay 14 eventos diferentes que pueden sucederle a un correo electrónico. Aquí hay una lista de los eventos actuales:

• Bounce

• ClickDelay

• Delivery

• Generation Failure

• Generation Rejection

• Initial Open

• InjectionLink Unsubscribe

• List Unsubscribe

• Open

• Out of Band

• Policy RejectionSpam Complaint

  
  

* Sigue este enlace para una guía de referencia actualizada para obtener una descripción de cada evento junto con los datos que se comparten para cada evento.

Cada evento tiene numerosos campos que coinciden con el tipo de evento. Algunos campos como el transmission_id se encuentran en cada evento, pero otros campos pueden ser más específicos del evento; por ejemplo, solo los eventos de apertura y clic tienen información de geolocalización.

Una entrada de evento de mensaje muy importante para este proyecto es el transmission_id. Todas las entradas de evento de mensaje para el correo electrónico original, el correo electrónico archivado y cualquier dirección cc y bcc compartirán el mismo transmission_id.

También hay una entrada común llamada el message_id que tendrá el mismo id para cada entrada del correo electrónico original y el correo electrónico archivado. Cualquier dirección cc o bcc tendrá su propio id para la entrada message_id.

Hasta ahora suena genial y bastante fácil, pero ahora viene la parte desafiante. Recuerda, para obtener el correo electrónico de archivo, hemos hecho que SparkPost envíe un duplicado del correo electrónico original a otra dirección de correo electrónico que corresponde a alguna bandeja de entrada a la que tienes acceso. Pero para automatizar esta solución y almacenar el cuerpo del correo electrónico, voy a usar otra función de SparkPost llamada Reenvío de Correos Electrónicos Entrantes. Lo que hace es tomar todos los correos enviados a un dominio específico y procesarlos. Al procesarlos, divide el correo electrónico y crea una estructura JSON que luego se entrega a una aplicación a través de un webhook. Consulte el Apéndice A para un ejemplo de JSON.

Si miras con cuidado, notarás que la estructura JSON del reenvío entrante carece de un campo muy importante; el transmission_id. Mientras que todos los correos electrónicos salientes tienen el transmission_id con la misma entrada que une todos los datos del correo electrónico original, archivo, cc y bcc; SparkPost no tiene forma de saber que el correo electrónico capturado por el proceso de entrada está conectado a cualquiera de los correos electrónicos salientes. El proceso de entrada simplemente sabe que se envió un correo a un dominio específico y lo analiza. Eso es todo. Tratará cualquier correo enviado a ese dominio de la misma manera, ya sea una respuesta de un cliente o el correo electrónico de archivo enviado desde SparkPost.

Entonces el truco es; ¿cómo vinculas los datos salientes con el proceso de entrada que acaba de capturar la versión archivada del correo electrónico? Lo que decidí hacer es ocultar un id único en el cuerpo del correo electrónico. Cómo se hace esto depende de ti, pero simplemente creé un campo de entrada con la etiqueta oculta activada.

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

También añadí ese campo en el bloque de metadatos del encabezado X-MSYS-API que se pasa a SparkPost durante la inyección. Este UID oculto terminará siendo el pegamento de todo el proceso y es un componente principal del proyecto y se discutirá en profundidad en las siguientes entradas del blog.

Ahora que tenemos el UID que unirá este proyecto y entendemos por qué es necesario, puedo comenzar a construir la visión del proyecto general y las entradas correspondientes del blog.

1. Capturar y almacenar el correo electrónico de archivo junto con una entrada de base de datos para búsqueda/indexación

2. Capturar todos los datos del evento de mensaje

3. Crear una aplicación para ver el correo electrónico y todos los datos correspondientes

Aquí hay un diagrama simple del proyecto:

La primera entrega de código cubrirá el proceso de archivo y el almacenamiento del correo electrónico en S3, mientras que la segunda entrega de código cubrirá el almacenamiento de todos los datos de registro de message-events en MySQL. Puedes esperar las dos primeras entregas de código y entradas de blog a principios de 2019. Si tienes alguna pregunta o sugerencia, no dudes en compartirlas.

Envíos Felices.
– Jeff

Apéndice A: