Con el aumento del uso del correo electrónico en entornos regulatorios, he decidido que es momento de iniciar 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.
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 del evento (es decir, cuando se envió el correo electrónico, aperturas, clics, rebotes, bajas, etc.) en un correo electrónico para fines de auditoría, pero decidí no crear ningún código de soporte.
Con el aumento del uso del correo electrónico en entornos regulatorios, he decidido que es hora de iniciar un nuevo proyecto que reúna todo esto con muestras de código sobre cómo almacenar el cuerpo del correo electrónico y todos sus datos asociados. Durante el próximo año, continuaré construyendo sobre este proyecto con el objetivo de crear una aplicación de almacenamiento y visualización funcional 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 relevantes del registro en MySQL para una fácil referencia cruzada. Para sistemas de archivado de producción que requieran estrategias robustas de respaldo de bases de datos, considere implementar un proceso integral de copia de seguridad y restauración de PostgreSQL para asegurar que sus datos de archivo estén debidamente protegidos. En última instancia, este es el punto de partida para construir una aplicación que permitirá la fácil búsqueda de correos electrónicos archivados, mostrando luego 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 plantear una arquitectura para la solución. El resto de los blogs detallarán partes de la solución junto con muestras de código.
El primer paso en mi proceso fue averiguar 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, necesita:
Capturar el cuerpo del correo antes de enviar el correo electrónico
Hacer que el servidor de correo almacene una copia
Hacer que el servidor de correo cree una copia para que usted la almacene
Si el servidor de correo está agregando elementos como seguimiento de enlaces o seguimiento de aperturas, no puede usar la opción #1 porque no reflejará los cambios de seguimiento de aperturas/clic.
Eso significa que o el servidor debe almacenar el correo electrónico o de alguna manera ofrecerle una copia de ese correo para almacenamiento. Dado que SparkPost no tiene un mecanismo de almacenamiento para cuerpos de correos electrónicos 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 almacenar en S3.
Esto se hace utilizando la función de Archivo de SparkPost. La función de Archivo 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 de Archivo de la siguiente manera:
Los destinatarios en la lista de archivo recibirán una réplica exacta del mensaje que fue enviado a la dirección RCPT TO. En particular, cualquier enlace codificado destinado al destinatario RCPT TO será idéntico en los mensajes de 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 desea una explicación más profunda, aquí hay un enlace a la documentación de SparkPost sobre la creación de copias duplicadas (o de archivo) de un correo electrónico.
Como nota al margen, SparkPost en realidad le permite enviar correos electrónicos a direcciones cc, bcc y de archivo. Para esta solución, nos centramos en las direcciones de archivo.
* Aviso * Los correos archivados SOLO pueden ser creados al inyectar correos en SparkPost a través de SMTP!
Ahora que sabemos cómo obtener una copia del correo original, necesitamos mirar los datos de registro que se producen y algunas de las sutilezas dentro de esos datos. SparkPost rastrea todo lo que sucede en sus servidores y le ofrece esa información en forma de eventos de mensajes. Esos eventos se almacenan en SparkPost por 10 días y se pueden recuperar del servidor a través de una API RESTful llamada eventos de mensajes, o puede hacer que SparkPost envíe esos eventos a cualquier cantidad de aplicaciones de recolección que desee. El mecanismo de envío 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:
Rebote
Retraso de Clic
Entrega
Fallo de Generación
Rechazo de Generación
Apertura Inicial
Desuscripción de Enlace de Inyección
Desuscripción de Lista
Apertura
Fuera de Banda
Rechazo de PolíticaQueja de Spam
* Siga este enlace para una guía de referencia actualizada con 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 eventos de mensajes para el correo original, el correo archivado y cualquier dirección cc y bcc compartirán el mismo transmission_id.
También hay una entrada común llamada message_id que tendrá el mismo id para cada entrada del correo original y el correo archivado. Cualquier dirección cc o bcc tendrá su propio id para la entrada de message_id .
Hasta ahora suena genial y francamente bastante fácil, pero ahora viene la parte desafiante. Recuerde, para obtener el correo archivado, hacemos que SparkPost envíe un duplicado del correo original a otra dirección de correo electrónico que corresponda a algún Inbox al que tenga acceso. Pero para automatizar esta solución y almacenar el cuerpo del correo, voy a usar otra característica de SparkPost llamada Relevo de Correo Inbound. Lo que hace eso, es tomar todos los correos electrónicos enviados a un dominio específico y procesarlos. Al procesarlos, descompone el correo en partes y crea una estructura JSON que luego se entrega a una aplicación a través de un webhook. Ver el Apéndice A para un ejemplo de JSON.
Si observa detenidamente, verá que a la estructura JSON del relevo inbound le falta un campo muy importante; el transmission_id. Mientras que todos los correos salientes tienen el transmission_id con la misma entrada que une todos los datos del correo original, archivo, cc y bcc; SparkPost no tiene manera de saber que el correo capturado por el proceso de inbound está conectado a cualquiera de los correos salientes. El proceso de inbound simplemente sabe que se envió un correo a un dominio específico y a analizar el correo. Eso es todo. Tratará cualquier correo enviado a ese dominio de la misma manera, ya sea una respuesta de un cliente o el correo de archivo enviado por SparkPost.
Entonces, el truco es; ¿cómo conectar los datos de salida con el proceso de inbound que acaba de capturar la versión archivada del correo? Lo que decidí hacer fue ocultar un id único en el cuerpo del correo. Cómo se hace esto depende de usted, pero simplemente creé un campo de entrada con la etiqueta oculta activada.
También agregué 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 publicaciones 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 publicaciones de blog correspondientes.
Capturar y almacenar el correo archivado junto con una entrada de base de datos para búsqueda/indexación
Capturar todos los datos de eventos de mensajes
Crear una aplicación para ver el correo y todos los datos correspondientes
Aquí hay un diagrama simple del proyecto:
La primera entrega de código cubrirá el proceso de archivo y almacenamiento del correo en S3, mientras que la segunda entrega de código cubrirá el almacenamiento de todos los datos de registro desde eventos de mensajes en MySQL. Puede esperar las dos primeras entregas de código y entradas de blog en algún momento a principios de 2019. Si tiene alguna pregunta o sugerencia, por favor, no dude en comunicárnoslo.
Feliz Envío.
– Jeff
Apéndice A:
