Om 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.

Med den ökade användningen av e-post i regulatoriska miljöer har jag beslutat att det är dags att starta ett nytt projekt som samlar allt detta med kodexempel på hur man lagrar e-postmeddelandet och alla dess tillhörande data. Under nästa år kommer jag att fortsätta att bygga på detta projekt med målet att skapa en fungerande lagrings- och visningsapplikation för arkiverade e-postmeddelanden och all logginformation som produceras av SparkPost. SparkPost har inget system som arkiverar e-postmeddelanden, men det gör det ganska enkelt att bygga en arkiveringsplattform.

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.  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. Den code for this project can be found in the following GitHub repository: https://github.com/jeff-goldstein/PHPArchivePlatform

Det första inlägget i bloggserien kommer att beskriva utmaningen och lägga upp en arkitektur för lösningen. Resten av bloggarna kommer att beskriva delar av lösningen tillsammans med kodexempel.

Det första steget i min process var att ta reda på hur jag skulle få en kopia av det e-postmeddelande som skickades till den ursprungliga mottagaren. För att få en kopia av e-postmeddelandet måste du antingen:

1. Fånga upp e-posttexten innan du skickar e-postmeddelandet

2. Få e-postservern att lagra en kopia

3. Låt e-postservern skapa en kopia som du kan lagra

Om e-postservern lägger till objekt som länkspårning eller öppen spårning kan du inte använda #1 eftersom den inte kommer att återspegla ändringarna i öppen/klickspårning.

Det innebär att servern antingen måste lagra e-postmeddelandet eller på något sätt erbjuda en kopia av e-postmeddelandet till dig för lagring. Eftersom SparkPost inte har någon lagringsmekanism för e-postmeddelanden men har ett sätt att skapa en kopia av e-postmeddelandet, kommer vi att låta SparkPost skicka oss en kopia av e-postmeddelandet som vi kan lagra i 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-dokumentation defines their Archive feature in the following manner:

Mottagare i arkivlistan kommer att få en exakt kopia av det meddelande som skickades till RCPT TO-adressen. I synnerhet kommer alla kodade länkar som är avsedda för RCPT TO-mottagaren att vara identiska i arkivmeddelandena

De enda skillnaderna från RCPT TO-e-postmeddelandet är att vissa av rubrikerna kommer att vara annorlunda eftersom måladressen för arkiveringsmeddelandet är annorlunda, men e-postmeddelandets kropp kommer att vara en exakt kopia!

If you want a deeper explanation here is a link till SparkPost documentation on creating duplicate (or archive) copies of an email.

SparkPost låter dig faktiskt skicka e-postmeddelanden till cc-, bcc- och arkiv-e-postadresser. För den här lösningen fokuserar vi på arkivadresserna.

* Observera * Arkiverade e-postmeddelanden kan ENDAST skapas när e-postmeddelanden injiceras i SparkPost via SMTP!

Now that we know how to obtain a copy of the original email, we need to look vid 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:

• Studs

• Klickfördröjning

• Leverans

• Generation misslyckad

• Generation Avvisning

• Initialt öppen

• InjectionLink Avsluta prenumeration

• Lista Avsluta prenumeration

• Öppna

• Utanför band

• Policy AvvisningSpam Klagomål

* Follow denna länk 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.

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 Förmedling av inkommande e-post. 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.

Så tricket är; hur limmar du den utgående datan till den inkommande processen som bara tog tag i den arkiverade versionen av e-postmeddelandet? Det jag bestämde mig för att göra är att dölja ett unikt id i e-postmeddelandet. Hur detta görs är upp till dig, men jag skapade helt enkelt ett inmatningsfält med den dolda taggen påslagen.

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

Jag lade också till det fältet i metadatablocket i X-MSYS-API-headern som skickas till SparkPost under injektionen. Detta dolda UID kommer i slutändan att vara limmet i hela processen, och är en huvudkomponent i projektet och kommer att diskuteras ingående i följande blogginlägg.

Nu när vi har det UID som kommer att hålla ihop projektet och förstår varför det är nödvändigt, kan jag börja bygga upp visionen för det övergripande projektet och motsvarande blogginlägg.

1. Fånga upp och lagra arkivmeddelandet tillsammans med en databaspost för sökning/indexering

2. Fånga upp alla data om meddelandehändelser

3. Skapa en applikation för att visa e-postmeddelandet och alla tillhörande data

Här är ett enkelt diagram över projektet:

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.

Lycklig sändning.

- Jeff

Bilaga A: