Costruire un sistema di archiviazione delle email: le sfide e naturalmente la soluzione – Parte 1
Jeff Goldstein
4 feb 2019
1 min read
Conclusioni principali
L'archiviazione delle email è sempre più essenziale per ambienti di normazione, conformità e verifica.
SparkPost non memorizza il corpo delle email, ma la sua funzionalità Archive consente ai mittenti di ricevere messaggi duplicati che rispecchiano i link di tracciamento e i contenuti.
I corpi delle email possono essere memorizzati in Amazon S3, mentre i metadati degli eventi dei messaggi possono essere memorizzati in MySQL per interrogazioni e referenze incrociate.
Gli eventi dei messaggi di SparkPost forniscono ricchi registri di attività (rimbalzi, consegne, clic, aperture, cancellazioni di iscrizione, reclami e altro).
Le copie d'archivio vengono generate solo inviando email tramite SMTP.
Gli eventi dei messaggi per email originali, archivio, CC e BCC condividono un comune transmission_id.
Il sistema Inbound Email Relay può assorbire messaggi archiviati ma non include il transmission_id, creando una sfida per il collegamento dei dati.
L'inserimento di un hidden unique identifier (UID) nel corpo del messaggio colma quel divario e collega i contenuti in entrata ai registri in uscita.
La combinazione di email archiviate + eventi dei messaggi consente la costruzione di un sistema d'archivio ricercabile e verificabile.
Il progetto a lungo termine include versioni di codice per memorizzare email archiviate in S3 e registrare dati di eventi in MySQL.
L'applicazione finale consentirà una facile ricerca, visualizzazione e riconciliazione del contenuto delle email con tutta la storia degli eventi correlati.
Ideale per industrie con forte regolamentazione che necessitano di completa visibilità su ogni messaggio inviato.
Q&A Highlights
Perché costruire il proprio sistema di archiviazione email?
Le industrie regolamentate spesso richiedono l'archiviazione a lungo termine sia del corpo dell'email sia di tutti i log degli eventi associati. SparkPost non memorizza i corpi dei messaggi, quindi la creazione di un sistema personalizzato garantisce conformità, controllo e visibilità.
Come si ottiene una copia esatta dell'email originale inviata?
La funzione Archive di SparkPost invia una copia di ogni email in uscita agli indirizzi di archivio designati, preservando tutti i link codificati e i comportamenti di tracciamento.
Perché non puoi catturare il corpo dell'email prima di inviare?
La cattura pre-invio non include le modifiche di SparkPost (tracciamento delle aperture, tracciamento dei clic, codifica dei link). L'utilizzo delle copie di Archivio garantisce che la vostra versione salvata corrisponda esattamente a ciò che i destinatari ricevono.
SparkPost archivia automaticamente le email?
No. SparkPost non memorizza i corpi dei messaggi. Le copie archiviate devono essere richieste specificando gli indirizzi dell'archivio durante l'iniezione SMTP.
Cosa viene archiviato dove in questo sistema di archiviazione?
Email body → Amazon S3
Registri degli eventi di messaggio → MySQL
Questa separazione supporta la ricerca veloce, le query strutturate e lo storage degli oggetti a basso costo.
Per quanto tempo SparkPost conserva i dati degli eventi?
SparkPost memorizza gli eventi dei messaggi per 10 giorni. Dopo questo periodo, i dati devono essere acquisiti tramite webhook o interrogati e archiviati altrove.
Quali eventi di messaggi sono disponibili?
Attualmente SparkPost espone 14 eventi, inclusi consegne, rimbalzi, clic, aperture, rifiuti, problemi di policy, reclami di spam, cancellazioni e altro.
Quali identificatori uniscono tutti gli eventi?
Tutti i messaggi in uscita (originale, archivio, CC, BCC) condividono lo stesso transmission_id. L'email originale e di archivio condividono anche lo stesso message_id.
Perché il processamento inbound è una sfida?
Il Relay Email Inbound di SparkPost converte l'email in arrivo in JSON, ma questo JSON non include transmission_id. Senza dati aggiuntivi, la copia in entrata non può essere collegata alla sua cronologia di log in uscita.
Come si collegano le email d'archivio inbound agli eventi di messaggi outbound?
Incorpora un identificatore unico (UID) nascosto nel corpo dell'email e passa lo stesso UID nei metadati. Questo UID diventa il riferimento condiviso tra i record in entrata e in uscita.
Come aiuta Inbound Email Relay ad automatizzare l'archiviazione?
Riceve le email archiviate inviate al tuo dominio di archiviazione, le analizza in JSON strutturato e le invia alla tua applicazione tramite webhook—consentendo l'estrazione e la conservazione automatica.
Qual è la visione a lungo termine del progetto?
Un'applicazione completa che:
Archivia le email in S3
Memorizza tutti i log degli eventi in MySQL
Permette agli utenti di cercare le email
Mostra l'email originale e ogni evento associato in un'interfaccia unificata
About a year ago I wrote a blog on how to retrieve copies of emails for archival and viewing but I did not broach the actual storing of the email or related data, and recently I wrote a blog on storing all of the event data (i.e. when the email was sent, opens, clicks bounces, unsubscribes, etc) on an email for the purpose of auditing, but chose not to create any supporting code.
With the increase of email usage in regulatory environments, I have decided it is time to start a new project that pulls all of this together with code samples on how to store the email body and all of its associated data. Over the next year, I will continue to build on this project with the aim to create a working storage and viewing application for archived emails and all log information produced by SparkPost. SparkPost does not have a system that archives the email body but it does make building an archival platform fairly easy.
In this blog series, I will describe the process I went through in order to store the email body onto S3 (Amazon’s Simple Store Service) and all relevant log data in MySQL for easy cross-referencing. For production archiving systems that require robust database backup strategies, consider implementing a comprehensive PostgreSQL backup and restore process to ensure your archival data is properly protected. Ultimately, this is the starting point for building an application that will allow for easy searching of archived emails, then displaying those emails along with the event (log) data. The code for this project can be found in the following GitHub repository: PHPArchivePlatform on GitHub
This first entry of the blog series is going to describe the challenge and lay out an architecture for the solution. The rest of the blogs will detail out portions of the solution along with code samples.
The first step in my process was to figure out how I was going to obtain a copy of the email sent to the original recipient. In order to obtain a copy of the email body, you need to either:
Email Body Capture Options
Method | Who creates the copy | Reflects tracking changes | Automation friendly | Used in this solution |
|---|---|---|---|---|
Capture before send | Application | ❌ No | ✅ Yes | ❌ |
Email server stores copy | Mail server | ✅ Yes | ❌ Limited | ❌ |
SparkPost Archive feature | SparkPost | ✅ Yes | ✅ Yes | ✅ |
Capture the email body before sending the email
Get the email server to store a copy
Have the email server create a copy for you to store
If the email server is adding items like link tracking or open tracking, you can’t use #1 because it won’t reflect the open/click tracking changes.
That means that either the server has to store the email or somehow offer a copy of that email to you for storage. Since SparkPost does not have a storage mechanism for email bodies but does have a way to create a copy of the email, we will have SparkPost send us a duplicate of the email for us to store in S3.
This is done by using SparkPost’s Archive feature. SparkPost’s Archive feature gives the sender the ability to tell SparkPost to send a duplicate of the email to one or more email addresses and use the same tracking and open links as the original. SparkPost documentation defines their Archive feature in the following manner:
Recipients in the archive list will receive an exact replica of the message that was sent to the RCPT TO address. In particular, any encoded links intended for the RCPT TO recipient will be identical in the archive messages
The only differences from the RCPT TO email are that some of the headers will be different since the target address for the archiving email is different, but the body of the email will be an exact replica!
If you want a deeper explanation here is a link to the SparkPost documentation on creating duplicate (or archive) copies of an email.
As a side note, SparkPost actually allows you to send emails to cc, bcc, and archive email addresses. For this solution, we are focused on the archive addresses.
* Notice * Archived emails can ONLY be created when injecting emails into SparkPost via SMTP!
Now that we know how to obtain a copy of the original email, we need to look at the log data that is produced and some of the subtle nuances within that data. SparkPost tracks everything that happens on its servers and offers that information up to you in the form of message-events. Those events are stored on SparkPost for 10 days and can be pulled from the server via a RESTful API called message-events, or you can have SparkPost push those events to any number of collecting applications that you wish. The push mechanism is done through webhooks and is done in real time.
Currently, there are 14 different events that may happen to an email. Here is a list of the current events:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Follow this link for an up to date reference guide for a description of each event along with the data that is shared for each event.
Each event has numerous fields that match the event type. Some fields like the transmission_id are found in every event, but other fields may be more event-specific; for example, only open and click events have geotag information.
Identifiers Used in the Archiving System
Identifier | Where it originates | Shared across | Purpose | Limitation |
|---|---|---|---|---|
transmission_id | SparkPost outbound | Original, archive, cc, bcc | Correlates all message events | Not available in inbound relay |
message_id | SparkPost outbound | Original + archive | Identifies individual messages | Different for cc/bcc |
Hidden UID | Injected by sender | Outbound + inbound | Links archived email body to events | Must be custom-implemented |
One very important message event entry to this project is the transmission_id. All of the message event entries for the original email, archived email, and any cc and bcc addresses will share the same transmission_id.
There is also a common entry called the message_id that will have the same id for each entry of the original email and the archived email. Any cc or bcc addresses will have their own id for the message_id entry.
So far this sounds great and frankly fairly easy, but now is the challenging part. Remember, in order to get the archive email, we have SparkPost send a duplicate of the original email to another email address which corresponds to some inbox that you have access to. But in order to automate this solution and store the email body, I’m going to use another feature of SparkPost’s called Inbound Email Relaying. What that does, is take all emails sent to a specific domain and process them. By processing them, it rips the email apart and creates a JSON structure which is then delivered to an application via a webhook. See Appendix A for a sample JSON.
If you look real carefully, you will notice that the JSON structure from the inbound relay is missing a very important field; the transmission_id. While all of the outbound emails have the transmission_id with the same entry which binds all of the data from the original email, archive, cc, and bcc addresses; SparkPost has no way to know that the email captured by the inbound process is connected to any of the outbound emails. The inbound process simply knows that an email was sent to a specific domain and to parse the email. That’s it. It will treat any email sent to that domain the same way, be it a reply from a customer or the archive email send from SparkPost.
So the trick is; how do you glue the outbound data to the inbound process that just grabbed the archived version of the email? What I decided to do is to hide a unique id in the body of the email. How this is done is up to you, but I simply created an input field with the hidden tag turned on.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
I also added that field into the metadata block of the X-MSYS-API header which is passed to SparkPost during injection. This hidden UID will end up being the glue to the whole process, and is a main component of the project and will be discussed in depth in the following blog posts.
Now that we have the UID that will glue this project together and understand why it’s necessary, I can start to build the vision of the overall project and corresponding blog posts.
Capturing and storing the archive email along with a database entry for searching/indexing
Capture all message event data
Create an application to view the email and all corresponding data
Here is a simple diagram of the project:
The first drop of code will cover the archive process and storing the email onto S3, while the second code drop will cover storing all of the log data from message-events into MySQL. You can expect the first two code drops and blog entries sometime in early 2019. If you have any questions or suggestions, please feel free to pass them along.
Happy Sending.
– Jeff
Appendix A:
About a year ago I wrote a blog on how to retrieve copies of emails for archival and viewing but I did not broach the actual storing of the email or related data, and recently I wrote a blog on storing all of the event data (i.e. when the email was sent, opens, clicks bounces, unsubscribes, etc) on an email for the purpose of auditing, but chose not to create any supporting code.
With the increase of email usage in regulatory environments, I have decided it is time to start a new project that pulls all of this together with code samples on how to store the email body and all of its associated data. Over the next year, I will continue to build on this project with the aim to create a working storage and viewing application for archived emails and all log information produced by SparkPost. SparkPost does not have a system that archives the email body but it does make building an archival platform fairly easy.
In this blog series, I will describe the process I went through in order to store the email body onto S3 (Amazon’s Simple Store Service) and all relevant log data in MySQL for easy cross-referencing. For production archiving systems that require robust database backup strategies, consider implementing a comprehensive PostgreSQL backup and restore process to ensure your archival data is properly protected. Ultimately, this is the starting point for building an application that will allow for easy searching of archived emails, then displaying those emails along with the event (log) data. The code for this project can be found in the following GitHub repository: PHPArchivePlatform on GitHub
This first entry of the blog series is going to describe the challenge and lay out an architecture for the solution. The rest of the blogs will detail out portions of the solution along with code samples.
The first step in my process was to figure out how I was going to obtain a copy of the email sent to the original recipient. In order to obtain a copy of the email body, you need to either:
Email Body Capture Options
Method | Who creates the copy | Reflects tracking changes | Automation friendly | Used in this solution |
|---|---|---|---|---|
Capture before send | Application | ❌ No | ✅ Yes | ❌ |
Email server stores copy | Mail server | ✅ Yes | ❌ Limited | ❌ |
SparkPost Archive feature | SparkPost | ✅ Yes | ✅ Yes | ✅ |
Capture the email body before sending the email
Get the email server to store a copy
Have the email server create a copy for you to store
If the email server is adding items like link tracking or open tracking, you can’t use #1 because it won’t reflect the open/click tracking changes.
That means that either the server has to store the email or somehow offer a copy of that email to you for storage. Since SparkPost does not have a storage mechanism for email bodies but does have a way to create a copy of the email, we will have SparkPost send us a duplicate of the email for us to store in S3.
This is done by using SparkPost’s Archive feature. SparkPost’s Archive feature gives the sender the ability to tell SparkPost to send a duplicate of the email to one or more email addresses and use the same tracking and open links as the original. SparkPost documentation defines their Archive feature in the following manner:
Recipients in the archive list will receive an exact replica of the message that was sent to the RCPT TO address. In particular, any encoded links intended for the RCPT TO recipient will be identical in the archive messages
The only differences from the RCPT TO email are that some of the headers will be different since the target address for the archiving email is different, but the body of the email will be an exact replica!
If you want a deeper explanation here is a link to the SparkPost documentation on creating duplicate (or archive) copies of an email.
As a side note, SparkPost actually allows you to send emails to cc, bcc, and archive email addresses. For this solution, we are focused on the archive addresses.
* Notice * Archived emails can ONLY be created when injecting emails into SparkPost via SMTP!
Now that we know how to obtain a copy of the original email, we need to look at the log data that is produced and some of the subtle nuances within that data. SparkPost tracks everything that happens on its servers and offers that information up to you in the form of message-events. Those events are stored on SparkPost for 10 days and can be pulled from the server via a RESTful API called message-events, or you can have SparkPost push those events to any number of collecting applications that you wish. The push mechanism is done through webhooks and is done in real time.
Currently, there are 14 different events that may happen to an email. Here is a list of the current events:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Follow this link for an up to date reference guide for a description of each event along with the data that is shared for each event.
Each event has numerous fields that match the event type. Some fields like the transmission_id are found in every event, but other fields may be more event-specific; for example, only open and click events have geotag information.
Identifiers Used in the Archiving System
Identifier | Where it originates | Shared across | Purpose | Limitation |
|---|---|---|---|---|
transmission_id | SparkPost outbound | Original, archive, cc, bcc | Correlates all message events | Not available in inbound relay |
message_id | SparkPost outbound | Original + archive | Identifies individual messages | Different for cc/bcc |
Hidden UID | Injected by sender | Outbound + inbound | Links archived email body to events | Must be custom-implemented |
One very important message event entry to this project is the transmission_id. All of the message event entries for the original email, archived email, and any cc and bcc addresses will share the same transmission_id.
There is also a common entry called the message_id that will have the same id for each entry of the original email and the archived email. Any cc or bcc addresses will have their own id for the message_id entry.
So far this sounds great and frankly fairly easy, but now is the challenging part. Remember, in order to get the archive email, we have SparkPost send a duplicate of the original email to another email address which corresponds to some inbox that you have access to. But in order to automate this solution and store the email body, I’m going to use another feature of SparkPost’s called Inbound Email Relaying. What that does, is take all emails sent to a specific domain and process them. By processing them, it rips the email apart and creates a JSON structure which is then delivered to an application via a webhook. See Appendix A for a sample JSON.
If you look real carefully, you will notice that the JSON structure from the inbound relay is missing a very important field; the transmission_id. While all of the outbound emails have the transmission_id with the same entry which binds all of the data from the original email, archive, cc, and bcc addresses; SparkPost has no way to know that the email captured by the inbound process is connected to any of the outbound emails. The inbound process simply knows that an email was sent to a specific domain and to parse the email. That’s it. It will treat any email sent to that domain the same way, be it a reply from a customer or the archive email send from SparkPost.
So the trick is; how do you glue the outbound data to the inbound process that just grabbed the archived version of the email? What I decided to do is to hide a unique id in the body of the email. How this is done is up to you, but I simply created an input field with the hidden tag turned on.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
I also added that field into the metadata block of the X-MSYS-API header which is passed to SparkPost during injection. This hidden UID will end up being the glue to the whole process, and is a main component of the project and will be discussed in depth in the following blog posts.
Now that we have the UID that will glue this project together and understand why it’s necessary, I can start to build the vision of the overall project and corresponding blog posts.
Capturing and storing the archive email along with a database entry for searching/indexing
Capture all message event data
Create an application to view the email and all corresponding data
Here is a simple diagram of the project:
The first drop of code will cover the archive process and storing the email onto S3, while the second code drop will cover storing all of the log data from message-events into MySQL. You can expect the first two code drops and blog entries sometime in early 2019. If you have any questions or suggestions, please feel free to pass them along.
Happy Sending.
– Jeff
Appendix A:
About a year ago I wrote a blog on how to retrieve copies of emails for archival and viewing but I did not broach the actual storing of the email or related data, and recently I wrote a blog on storing all of the event data (i.e. when the email was sent, opens, clicks bounces, unsubscribes, etc) on an email for the purpose of auditing, but chose not to create any supporting code.
With the increase of email usage in regulatory environments, I have decided it is time to start a new project that pulls all of this together with code samples on how to store the email body and all of its associated data. Over the next year, I will continue to build on this project with the aim to create a working storage and viewing application for archived emails and all log information produced by SparkPost. SparkPost does not have a system that archives the email body but it does make building an archival platform fairly easy.
In this blog series, I will describe the process I went through in order to store the email body onto S3 (Amazon’s Simple Store Service) and all relevant log data in MySQL for easy cross-referencing. For production archiving systems that require robust database backup strategies, consider implementing a comprehensive PostgreSQL backup and restore process to ensure your archival data is properly protected. Ultimately, this is the starting point for building an application that will allow for easy searching of archived emails, then displaying those emails along with the event (log) data. The code for this project can be found in the following GitHub repository: PHPArchivePlatform on GitHub
This first entry of the blog series is going to describe the challenge and lay out an architecture for the solution. The rest of the blogs will detail out portions of the solution along with code samples.
The first step in my process was to figure out how I was going to obtain a copy of the email sent to the original recipient. In order to obtain a copy of the email body, you need to either:
Email Body Capture Options
Method | Who creates the copy | Reflects tracking changes | Automation friendly | Used in this solution |
|---|---|---|---|---|
Capture before send | Application | ❌ No | ✅ Yes | ❌ |
Email server stores copy | Mail server | ✅ Yes | ❌ Limited | ❌ |
SparkPost Archive feature | SparkPost | ✅ Yes | ✅ Yes | ✅ |
Capture the email body before sending the email
Get the email server to store a copy
Have the email server create a copy for you to store
If the email server is adding items like link tracking or open tracking, you can’t use #1 because it won’t reflect the open/click tracking changes.
That means that either the server has to store the email or somehow offer a copy of that email to you for storage. Since SparkPost does not have a storage mechanism for email bodies but does have a way to create a copy of the email, we will have SparkPost send us a duplicate of the email for us to store in S3.
This is done by using SparkPost’s Archive feature. SparkPost’s Archive feature gives the sender the ability to tell SparkPost to send a duplicate of the email to one or more email addresses and use the same tracking and open links as the original. SparkPost documentation defines their Archive feature in the following manner:
Recipients in the archive list will receive an exact replica of the message that was sent to the RCPT TO address. In particular, any encoded links intended for the RCPT TO recipient will be identical in the archive messages
The only differences from the RCPT TO email are that some of the headers will be different since the target address for the archiving email is different, but the body of the email will be an exact replica!
If you want a deeper explanation here is a link to the SparkPost documentation on creating duplicate (or archive) copies of an email.
As a side note, SparkPost actually allows you to send emails to cc, bcc, and archive email addresses. For this solution, we are focused on the archive addresses.
* Notice * Archived emails can ONLY be created when injecting emails into SparkPost via SMTP!
Now that we know how to obtain a copy of the original email, we need to look at the log data that is produced and some of the subtle nuances within that data. SparkPost tracks everything that happens on its servers and offers that information up to you in the form of message-events. Those events are stored on SparkPost for 10 days and can be pulled from the server via a RESTful API called message-events, or you can have SparkPost push those events to any number of collecting applications that you wish. The push mechanism is done through webhooks and is done in real time.
Currently, there are 14 different events that may happen to an email. Here is a list of the current events:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Follow this link for an up to date reference guide for a description of each event along with the data that is shared for each event.
Each event has numerous fields that match the event type. Some fields like the transmission_id are found in every event, but other fields may be more event-specific; for example, only open and click events have geotag information.
Identifiers Used in the Archiving System
Identifier | Where it originates | Shared across | Purpose | Limitation |
|---|---|---|---|---|
transmission_id | SparkPost outbound | Original, archive, cc, bcc | Correlates all message events | Not available in inbound relay |
message_id | SparkPost outbound | Original + archive | Identifies individual messages | Different for cc/bcc |
Hidden UID | Injected by sender | Outbound + inbound | Links archived email body to events | Must be custom-implemented |
One very important message event entry to this project is the transmission_id. All of the message event entries for the original email, archived email, and any cc and bcc addresses will share the same transmission_id.
There is also a common entry called the message_id that will have the same id for each entry of the original email and the archived email. Any cc or bcc addresses will have their own id for the message_id entry.
So far this sounds great and frankly fairly easy, but now is the challenging part. Remember, in order to get the archive email, we have SparkPost send a duplicate of the original email to another email address which corresponds to some inbox that you have access to. But in order to automate this solution and store the email body, I’m going to use another feature of SparkPost’s called Inbound Email Relaying. What that does, is take all emails sent to a specific domain and process them. By processing them, it rips the email apart and creates a JSON structure which is then delivered to an application via a webhook. See Appendix A for a sample JSON.
If you look real carefully, you will notice that the JSON structure from the inbound relay is missing a very important field; the transmission_id. While all of the outbound emails have the transmission_id with the same entry which binds all of the data from the original email, archive, cc, and bcc addresses; SparkPost has no way to know that the email captured by the inbound process is connected to any of the outbound emails. The inbound process simply knows that an email was sent to a specific domain and to parse the email. That’s it. It will treat any email sent to that domain the same way, be it a reply from a customer or the archive email send from SparkPost.
So the trick is; how do you glue the outbound data to the inbound process that just grabbed the archived version of the email? What I decided to do is to hide a unique id in the body of the email. How this is done is up to you, but I simply created an input field with the hidden tag turned on.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
I also added that field into the metadata block of the X-MSYS-API header which is passed to SparkPost during injection. This hidden UID will end up being the glue to the whole process, and is a main component of the project and will be discussed in depth in the following blog posts.
Now that we have the UID that will glue this project together and understand why it’s necessary, I can start to build the vision of the overall project and corresponding blog posts.
Capturing and storing the archive email along with a database entry for searching/indexing
Capture all message event data
Create an application to view the email and all corresponding data
Here is a simple diagram of the project:
The first drop of code will cover the archive process and storing the email onto S3, while the second code drop will cover storing all of the log data from message-events into MySQL. You can expect the first two code drops and blog entries sometime in early 2019. If you have any questions or suggestions, please feel free to pass them along.
Happy Sending.
– Jeff
Appendix A:
Circa un anno fa ho scritto un blog su come recuperare copie delle email per archiviazione e visualizzazione, ma non ho affrontato la questione dell'effettiva memorizzazione dell'email o dei dati correlati, e recentemente ho scritto un blog su come memorizzare tutti i dati dell'evento (ovvero quando l'email è stata inviata, aperture, clic, rimbalzi, cancellazioni dell'iscrizione, ecc.) su un'email per scopi di auditing, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso dell'email in ambienti normativi, ho deciso che è il momento di avviare un nuovo progetto che raccolga tutto ciò insieme a campioni di codice su come memorizzare il corpo dell'email e tutti i suoi dati associati. Nel prossimo anno, continuerò a costruire su questo progetto con l'obiettivo di creare una applicazione funzionante per la memorizzazione e visualizzazione delle email archiviate e tutte le informazioni di log prodotte da SparkPost. SparkPost non ha un sistema che archivia il corpo dell'email, ma rende abbastanza facile costruire una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per memorizzare il corpo dell'email su S3 (Amazon’s Simple Store Service) e tutti i dati di log rilevanti in MySQL per un facile incrocio delle referenze. Per i sistemi di archiviazione in produzione che richiedono strategie robuste di backup dei database, considera di implementare un processo completo di backup e ripristino PostgreSQL per garantire che i tuoi dati di archiviazione siano correttamente protetti. In definitiva, questo è il punto di partenza per costruire un'applicazione che consenta la facile ricerca delle email archiviate, quindi visualizzare quelle email insieme ai dati dell'evento (log). Il codice per questo progetto può essere trovato nel seguente repository GitHub: PHPArchivePlatform su GitHub
Questa prima voce della serie di blog descriverà la sfida e delinerà un'architettura per la soluzione. Il resto dei blog dettagliarà parti della soluzione insieme a campioni di codice.
Il primo passo nel mio processo è stato capire come avrei ottenuto una copia dell'email inviata al destinatario originale. Per ottenere una copia del corpo dell'email, è necessario:
Catturare il corpo dell'email prima di inviare l'email
Far sì che il server email memorizzi una copia
Far sì che il server email crei una copia per te da memorizzare
Se il server email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non puoi utilizzare il #1 perché non rifletterà le modifiche di tracciamento delle aperture/clic.
Ciò significa che il server deve memorizzare l'email o in qualche modo offrire una copia di quella email a te per la memorizzazione. Poiché SparkPost non ha un meccanismo di memorizzazione per i corpi delle email, ma ha un modo per creare una copia dell'email, faremo sì che SparkPost ci invii un duplicato dell'email da memorizzare in S3.
Questo è fatto usando la funzione Archive di SparkPost. La funzione Archive di SparkPost dà al mittente la possibilità di dire a SparkPost di inviare un duplicato dell'email a uno o più indirizzi email e utilizzare gli stessi link di tracciamento e apertura dell'originale. La documentazione di SparkPost definisce la loro funzione Archive nel seguente modo:
I destinatari nella lista di archivio riceveranno una replica esatta del messaggio che è stato inviato all'indirizzo RCPT TO. In particolare, qualsiasi link codificato destinato al destinatario RCPT TO sarà identico nei messaggi di archivio
Le uniche differenze rispetto all'email RCPT TO sono che alcune delle intestazioni saranno diverse poiché l'indirizzo di destinazione per l'email di archiviazione è diverso, ma il corpo dell'email sarà una replica esatta!
Se vuoi una spiegazione più approfondita, ecco un link alla documentazione di SparkPost su come creare copie duplicate (o archivio) di un'email.
Come nota a margine, SparkPost in realtà ti permette di inviare email a indirizzi cc, bcc e di archivio. Per questa soluzione, ci concentriamo sugli indirizzi di archivio.
* Avviso * Le email archiviate possono essere create SOLO quando si iniettano email in SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo osservare i dati di log che vengono prodotti e alcune delle sfumature sottili all'interno di quei dati. SparkPost traccia tutto ciò che accade sui suoi server e offre quell'informazione a te sotto forma di eventi del messaggio. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere estratti dal server tramite un'API RESTful chiamata message-events, oppure puoi far sì che SparkPost spedisca quegli eventi a un numero qualsiasi di applicazioni di raccolta che desideri. Il meccanismo di push è fatto tramite webhook ed è eseguito in tempo reale.
Attualmente, ci sono 14 diversi eventi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Segui questo link per una guida di riferimento aggiornata per una descrizione di ogni evento insieme ai dati condivisi per ciascun evento.
Ogni evento ha numerosi campi che corrispondono al tipo di evento. Alcuni campi come il transmission_id si trovano in ogni evento, ma altri campi possono essere più specifici per l'evento; ad esempio, solo gli eventi open e clic hanno informazioni geografiche.
Un elemento molto importante del messaggio-evento per questo progetto è il transmission_id. Tutti gli elementi del messaggio-evento per l'email originale, l'email archiviata, e qualsiasi indirizzo cc e bcc condivideranno lo stesso transmission_id.
C'è anche un elemento comune chiamato message_id che avrà lo stesso id per ogni entrata dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per l'elemento message_id.
Finora questo sembra ottimo e, francamente, abbastanza facile, ma ora arriva la parte difficile. Ricorda, per ottenere l'email di archivio, facciamo in modo che SparkPost invii un duplicato dell'email originale a un altro indirizzo email che corrisponde a una casella di posta a cui hai accesso. Ma al fine di automatizzare questa soluzione e memorizzare il corpo dell'email, utilizzerò un'altra funzione di SparkPost chiamata Relay Email Inbound. Quello che fa, è prendere tutte le email inviate a un dominio specifico e processarle. Processandole, smonta l'email e crea una struttura JSON che viene poi inviata a un'applicazione tramite un webhook. Vedi l'Appendice A per un esempio di JSON.
Se guardi attentamente, noterai che la struttura JSON dal relé di input manca un campo molto importante; la transmission_id. Mentre tutte le email in uscita hanno la transmission_id con la stessa voce che lega tutti i dati dall'email originale, archivio, cc e bcc indirizzi; SparkPost non ha modo di sapere che l'email catturata dal processo in entrata è collegata a qualsiasi delle email in uscita. Il processo in entrata sa semplicemente che un'email è stata inviata a un dominio specifico e analizzare l'email. Questo è tutto. Tratterà qualsiasi email inviata a quel dominio nello stesso modo, sia che si tratti di una risposta da un cliente o dell'email di archivio inviata da SparkPost.
Quindi l'astuzia è: come si collega i dati in uscita al processo in entrata che ha appena catturato la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id univoco nel corpo dell'email. Come questo viene fatto dipende da te, ma ho semplicemente creato un campo di input con il tag hidden attivato.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Ho anche aggiunto quel campo nel blocco metadata dell'intestazione X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto finirà per essere il collante per l'intero processo ed è un componente principale del progetto, sarà discusso in profondità nei post di blog seguenti.
Ora che abbiamo l'UID che collegherà questo progetto e capiamo perché è necessario, posso iniziare a costruire la visione del progetto globale e i post di blog corrispondenti.
Catturare e memorizzare l'email di archivio insieme a una voce di database per la ricerca/la indicizzazione
Catturare tutti i dati degli eventi del messaggio
Creare un'applicazione per visualizzare l'email e tutti i dati corrispondenti
Ecco un semplice diagramma del progetto:
Il primo gruppo di codice coprirà il processo di archiviazione e memorizzazione dell'email su S3, mentre il secondo gruppo di codice coprirà la memorizzazione di tutti i dati di log degli eventi del messaggio in MySQL. Puoi aspettarti i primi due gruppi di codice e voci di blog nel primo trimestre del 2019. Se hai domande o suggerimenti, non esitare a comunicarli.
Buon invio.
– Jeff
Appendice A:
Circa un anno fa ho scritto un blog su come recuperare copie delle email per archiviazione e visualizzazione, ma non ho affrontato la questione dell'effettiva memorizzazione dell'email o dei dati correlati, e recentemente ho scritto un blog su come memorizzare tutti i dati dell'evento (ovvero quando l'email è stata inviata, aperture, clic, rimbalzi, cancellazioni dell'iscrizione, ecc.) su un'email per scopi di auditing, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso dell'email in ambienti normativi, ho deciso che è il momento di avviare un nuovo progetto che raccolga tutto ciò insieme a campioni di codice su come memorizzare il corpo dell'email e tutti i suoi dati associati. Nel prossimo anno, continuerò a costruire su questo progetto con l'obiettivo di creare una applicazione funzionante per la memorizzazione e visualizzazione delle email archiviate e tutte le informazioni di log prodotte da SparkPost. SparkPost non ha un sistema che archivia il corpo dell'email, ma rende abbastanza facile costruire una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per memorizzare il corpo dell'email su S3 (Amazon’s Simple Store Service) e tutti i dati di log rilevanti in MySQL per un facile incrocio delle referenze. Per i sistemi di archiviazione in produzione che richiedono strategie robuste di backup dei database, considera di implementare un processo completo di backup e ripristino PostgreSQL per garantire che i tuoi dati di archiviazione siano correttamente protetti. In definitiva, questo è il punto di partenza per costruire un'applicazione che consenta la facile ricerca delle email archiviate, quindi visualizzare quelle email insieme ai dati dell'evento (log). Il codice per questo progetto può essere trovato nel seguente repository GitHub: PHPArchivePlatform su GitHub
Questa prima voce della serie di blog descriverà la sfida e delinerà un'architettura per la soluzione. Il resto dei blog dettagliarà parti della soluzione insieme a campioni di codice.
Il primo passo nel mio processo è stato capire come avrei ottenuto una copia dell'email inviata al destinatario originale. Per ottenere una copia del corpo dell'email, è necessario:
Catturare il corpo dell'email prima di inviare l'email
Far sì che il server email memorizzi una copia
Far sì che il server email crei una copia per te da memorizzare
Se il server email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non puoi utilizzare il #1 perché non rifletterà le modifiche di tracciamento delle aperture/clic.
Ciò significa che il server deve memorizzare l'email o in qualche modo offrire una copia di quella email a te per la memorizzazione. Poiché SparkPost non ha un meccanismo di memorizzazione per i corpi delle email, ma ha un modo per creare una copia dell'email, faremo sì che SparkPost ci invii un duplicato dell'email da memorizzare in S3.
Questo è fatto usando la funzione Archive di SparkPost. La funzione Archive di SparkPost dà al mittente la possibilità di dire a SparkPost di inviare un duplicato dell'email a uno o più indirizzi email e utilizzare gli stessi link di tracciamento e apertura dell'originale. La documentazione di SparkPost definisce la loro funzione Archive nel seguente modo:
I destinatari nella lista di archivio riceveranno una replica esatta del messaggio che è stato inviato all'indirizzo RCPT TO. In particolare, qualsiasi link codificato destinato al destinatario RCPT TO sarà identico nei messaggi di archivio
Le uniche differenze rispetto all'email RCPT TO sono che alcune delle intestazioni saranno diverse poiché l'indirizzo di destinazione per l'email di archiviazione è diverso, ma il corpo dell'email sarà una replica esatta!
Se vuoi una spiegazione più approfondita, ecco un link alla documentazione di SparkPost su come creare copie duplicate (o archivio) di un'email.
Come nota a margine, SparkPost in realtà ti permette di inviare email a indirizzi cc, bcc e di archivio. Per questa soluzione, ci concentriamo sugli indirizzi di archivio.
* Avviso * Le email archiviate possono essere create SOLO quando si iniettano email in SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo osservare i dati di log che vengono prodotti e alcune delle sfumature sottili all'interno di quei dati. SparkPost traccia tutto ciò che accade sui suoi server e offre quell'informazione a te sotto forma di eventi del messaggio. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere estratti dal server tramite un'API RESTful chiamata message-events, oppure puoi far sì che SparkPost spedisca quegli eventi a un numero qualsiasi di applicazioni di raccolta che desideri. Il meccanismo di push è fatto tramite webhook ed è eseguito in tempo reale.
Attualmente, ci sono 14 diversi eventi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Segui questo link per una guida di riferimento aggiornata per una descrizione di ogni evento insieme ai dati condivisi per ciascun evento.
Ogni evento ha numerosi campi che corrispondono al tipo di evento. Alcuni campi come il transmission_id si trovano in ogni evento, ma altri campi possono essere più specifici per l'evento; ad esempio, solo gli eventi open e clic hanno informazioni geografiche.
Un elemento molto importante del messaggio-evento per questo progetto è il transmission_id. Tutti gli elementi del messaggio-evento per l'email originale, l'email archiviata, e qualsiasi indirizzo cc e bcc condivideranno lo stesso transmission_id.
C'è anche un elemento comune chiamato message_id che avrà lo stesso id per ogni entrata dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per l'elemento message_id.
Finora questo sembra ottimo e, francamente, abbastanza facile, ma ora arriva la parte difficile. Ricorda, per ottenere l'email di archivio, facciamo in modo che SparkPost invii un duplicato dell'email originale a un altro indirizzo email che corrisponde a una casella di posta a cui hai accesso. Ma al fine di automatizzare questa soluzione e memorizzare il corpo dell'email, utilizzerò un'altra funzione di SparkPost chiamata Relay Email Inbound. Quello che fa, è prendere tutte le email inviate a un dominio specifico e processarle. Processandole, smonta l'email e crea una struttura JSON che viene poi inviata a un'applicazione tramite un webhook. Vedi l'Appendice A per un esempio di JSON.
Se guardi attentamente, noterai che la struttura JSON dal relé di input manca un campo molto importante; la transmission_id. Mentre tutte le email in uscita hanno la transmission_id con la stessa voce che lega tutti i dati dall'email originale, archivio, cc e bcc indirizzi; SparkPost non ha modo di sapere che l'email catturata dal processo in entrata è collegata a qualsiasi delle email in uscita. Il processo in entrata sa semplicemente che un'email è stata inviata a un dominio specifico e analizzare l'email. Questo è tutto. Tratterà qualsiasi email inviata a quel dominio nello stesso modo, sia che si tratti di una risposta da un cliente o dell'email di archivio inviata da SparkPost.
Quindi l'astuzia è: come si collega i dati in uscita al processo in entrata che ha appena catturato la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id univoco nel corpo dell'email. Come questo viene fatto dipende da te, ma ho semplicemente creato un campo di input con il tag hidden attivato.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Ho anche aggiunto quel campo nel blocco metadata dell'intestazione X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto finirà per essere il collante per l'intero processo ed è un componente principale del progetto, sarà discusso in profondità nei post di blog seguenti.
Ora che abbiamo l'UID che collegherà questo progetto e capiamo perché è necessario, posso iniziare a costruire la visione del progetto globale e i post di blog corrispondenti.
Catturare e memorizzare l'email di archivio insieme a una voce di database per la ricerca/la indicizzazione
Catturare tutti i dati degli eventi del messaggio
Creare un'applicazione per visualizzare l'email e tutti i dati corrispondenti
Ecco un semplice diagramma del progetto:
Il primo gruppo di codice coprirà il processo di archiviazione e memorizzazione dell'email su S3, mentre il secondo gruppo di codice coprirà la memorizzazione di tutti i dati di log degli eventi del messaggio in MySQL. Puoi aspettarti i primi due gruppi di codice e voci di blog nel primo trimestre del 2019. Se hai domande o suggerimenti, non esitare a comunicarli.
Buon invio.
– Jeff
Appendice A:
Circa un anno fa ho scritto un blog su come recuperare copie delle email per archiviazione e visualizzazione, ma non ho affrontato la questione dell'effettiva memorizzazione dell'email o dei dati correlati, e recentemente ho scritto un blog su come memorizzare tutti i dati dell'evento (ovvero quando l'email è stata inviata, aperture, clic, rimbalzi, cancellazioni dell'iscrizione, ecc.) su un'email per scopi di auditing, ma ho scelto di non creare alcun codice di supporto.
Con l'aumento dell'uso dell'email in ambienti normativi, ho deciso che è il momento di avviare un nuovo progetto che raccolga tutto ciò insieme a campioni di codice su come memorizzare il corpo dell'email e tutti i suoi dati associati. Nel prossimo anno, continuerò a costruire su questo progetto con l'obiettivo di creare una applicazione funzionante per la memorizzazione e visualizzazione delle email archiviate e tutte le informazioni di log prodotte da SparkPost. SparkPost non ha un sistema che archivia il corpo dell'email, ma rende abbastanza facile costruire una piattaforma di archiviazione.
In questa serie di blog, descriverò il processo che ho seguito per memorizzare il corpo dell'email su S3 (Amazon’s Simple Store Service) e tutti i dati di log rilevanti in MySQL per un facile incrocio delle referenze. Per i sistemi di archiviazione in produzione che richiedono strategie robuste di backup dei database, considera di implementare un processo completo di backup e ripristino PostgreSQL per garantire che i tuoi dati di archiviazione siano correttamente protetti. In definitiva, questo è il punto di partenza per costruire un'applicazione che consenta la facile ricerca delle email archiviate, quindi visualizzare quelle email insieme ai dati dell'evento (log). Il codice per questo progetto può essere trovato nel seguente repository GitHub: PHPArchivePlatform su GitHub
Questa prima voce della serie di blog descriverà la sfida e delinerà un'architettura per la soluzione. Il resto dei blog dettagliarà parti della soluzione insieme a campioni di codice.
Il primo passo nel mio processo è stato capire come avrei ottenuto una copia dell'email inviata al destinatario originale. Per ottenere una copia del corpo dell'email, è necessario:
Catturare il corpo dell'email prima di inviare l'email
Far sì che il server email memorizzi una copia
Far sì che il server email crei una copia per te da memorizzare
Se il server email sta aggiungendo elementi come il tracciamento dei link o il tracciamento delle aperture, non puoi utilizzare il #1 perché non rifletterà le modifiche di tracciamento delle aperture/clic.
Ciò significa che il server deve memorizzare l'email o in qualche modo offrire una copia di quella email a te per la memorizzazione. Poiché SparkPost non ha un meccanismo di memorizzazione per i corpi delle email, ma ha un modo per creare una copia dell'email, faremo sì che SparkPost ci invii un duplicato dell'email da memorizzare in S3.
Questo è fatto usando la funzione Archive di SparkPost. La funzione Archive di SparkPost dà al mittente la possibilità di dire a SparkPost di inviare un duplicato dell'email a uno o più indirizzi email e utilizzare gli stessi link di tracciamento e apertura dell'originale. La documentazione di SparkPost definisce la loro funzione Archive nel seguente modo:
I destinatari nella lista di archivio riceveranno una replica esatta del messaggio che è stato inviato all'indirizzo RCPT TO. In particolare, qualsiasi link codificato destinato al destinatario RCPT TO sarà identico nei messaggi di archivio
Le uniche differenze rispetto all'email RCPT TO sono che alcune delle intestazioni saranno diverse poiché l'indirizzo di destinazione per l'email di archiviazione è diverso, ma il corpo dell'email sarà una replica esatta!
Se vuoi una spiegazione più approfondita, ecco un link alla documentazione di SparkPost su come creare copie duplicate (o archivio) di un'email.
Come nota a margine, SparkPost in realtà ti permette di inviare email a indirizzi cc, bcc e di archivio. Per questa soluzione, ci concentriamo sugli indirizzi di archivio.
* Avviso * Le email archiviate possono essere create SOLO quando si iniettano email in SparkPost tramite SMTP!
Ora che sappiamo come ottenere una copia dell'email originale, dobbiamo osservare i dati di log che vengono prodotti e alcune delle sfumature sottili all'interno di quei dati. SparkPost traccia tutto ciò che accade sui suoi server e offre quell'informazione a te sotto forma di eventi del messaggio. Quegli eventi sono memorizzati su SparkPost per 10 giorni e possono essere estratti dal server tramite un'API RESTful chiamata message-events, oppure puoi far sì che SparkPost spedisca quegli eventi a un numero qualsiasi di applicazioni di raccolta che desideri. Il meccanismo di push è fatto tramite webhook ed è eseguito in tempo reale.
Attualmente, ci sono 14 diversi eventi che possono accadere a un'email. Ecco un elenco degli eventi attuali:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Segui questo link per una guida di riferimento aggiornata per una descrizione di ogni evento insieme ai dati condivisi per ciascun evento.
Ogni evento ha numerosi campi che corrispondono al tipo di evento. Alcuni campi come il transmission_id si trovano in ogni evento, ma altri campi possono essere più specifici per l'evento; ad esempio, solo gli eventi open e clic hanno informazioni geografiche.
Un elemento molto importante del messaggio-evento per questo progetto è il transmission_id. Tutti gli elementi del messaggio-evento per l'email originale, l'email archiviata, e qualsiasi indirizzo cc e bcc condivideranno lo stesso transmission_id.
C'è anche un elemento comune chiamato message_id che avrà lo stesso id per ogni entrata dell'email originale e dell'email archiviata. Qualsiasi indirizzo cc o bcc avrà il proprio id per l'elemento message_id.
Finora questo sembra ottimo e, francamente, abbastanza facile, ma ora arriva la parte difficile. Ricorda, per ottenere l'email di archivio, facciamo in modo che SparkPost invii un duplicato dell'email originale a un altro indirizzo email che corrisponde a una casella di posta a cui hai accesso. Ma al fine di automatizzare questa soluzione e memorizzare il corpo dell'email, utilizzerò un'altra funzione di SparkPost chiamata Relay Email Inbound. Quello che fa, è prendere tutte le email inviate a un dominio specifico e processarle. Processandole, smonta l'email e crea una struttura JSON che viene poi inviata a un'applicazione tramite un webhook. Vedi l'Appendice A per un esempio di JSON.
Se guardi attentamente, noterai che la struttura JSON dal relé di input manca un campo molto importante; la transmission_id. Mentre tutte le email in uscita hanno la transmission_id con la stessa voce che lega tutti i dati dall'email originale, archivio, cc e bcc indirizzi; SparkPost non ha modo di sapere che l'email catturata dal processo in entrata è collegata a qualsiasi delle email in uscita. Il processo in entrata sa semplicemente che un'email è stata inviata a un dominio specifico e analizzare l'email. Questo è tutto. Tratterà qualsiasi email inviata a quel dominio nello stesso modo, sia che si tratti di una risposta da un cliente o dell'email di archivio inviata da SparkPost.
Quindi l'astuzia è: come si collega i dati in uscita al processo in entrata che ha appena catturato la versione archiviata dell'email? Quello che ho deciso di fare è nascondere un id univoco nel corpo dell'email. Come questo viene fatto dipende da te, ma ho semplicemente creato un campo di input con il tag hidden attivato.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Ho anche aggiunto quel campo nel blocco metadata dell'intestazione X-MSYS-API che viene passato a SparkPost durante l'iniezione. Questo UID nascosto finirà per essere il collante per l'intero processo ed è un componente principale del progetto, sarà discusso in profondità nei post di blog seguenti.
Ora che abbiamo l'UID che collegherà questo progetto e capiamo perché è necessario, posso iniziare a costruire la visione del progetto globale e i post di blog corrispondenti.
Catturare e memorizzare l'email di archivio insieme a una voce di database per la ricerca/la indicizzazione
Catturare tutti i dati degli eventi del messaggio
Creare un'applicazione per visualizzare l'email e tutti i dati corrispondenti
Ecco un semplice diagramma del progetto:
Il primo gruppo di codice coprirà il processo di archiviazione e memorizzazione dell'email su S3, mentre il secondo gruppo di codice coprirà la memorizzazione di tutti i dati di log degli eventi del messaggio in MySQL. Puoi aspettarti i primi due gruppi di codice e voci di blog nel primo trimestre del 2019. Se hai domande o suggerimenti, non esitare a comunicarli.
Buon invio.
– Jeff
Appendice A:
