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

Dengan meningkatnya penggunaan email di lingkungan regulasi, saya telah memutuskan bahwa inilah saatnya untuk memulai sebuah proyek baru yang menggabungkan semua ini dengan contoh kode tentang cara menyimpan badan email dan semua data terkait. Selama setahun ke depan, saya akan terus mengembangkan proyek ini dengan tujuan untuk membuat aplikasi penyimpanan dan tampilan yang berfungsi untuk email yang diarsipkan dan semua informasi log yang dihasilkan oleh SparkPost. SparkPost tidak memiliki sistem yang mengarsipkan isi email, tetapi SparkPost membuat pembuatan platform pengarsipan menjadi cukup mudah.

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

Entri pertama dari seri blog ini akan menjelaskan tantangan dan menjabarkan arsitektur untuk solusinya. Blog selanjutnya akan merinci bagian-bagian dari solusi bersama dengan contoh kode.

Langkah pertama dalam proses saya adalah mencari tahu bagaimana saya akan mendapatkan salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan isi email, Anda perlu melakukan salah satu dari dua hal berikut ini:

1. Abadikan isi email sebelum mengirim email

2. Dapatkan server email untuk menyimpan salinan

3. Minta server email membuat salinan untuk Anda simpan

Jika server email menambahkan item seperti pelacakan tautan atau pelacakan terbuka, Anda tidak dapat menggunakan #1 karena tidak akan mencerminkan perubahan pelacakan terbuka/klik.

Itu berarti bahwa server harus menyimpan email atau entah bagaimana menawarkan salinan email tersebut kepada Anda untuk disimpan. Karena SparkPost tidak memiliki mekanisme penyimpanan untuk badan email, tetapi memiliki cara untuk membuat salinan email, kami akan meminta SparkPost mengirimkan duplikat email untuk kami simpan di 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. Dokumentasi SparkPost defines their Archive feature in the following manner:

Penerima dalam daftar arsip akan menerima replika yang sama persis dengan pesan yang dikirim ke alamat RCPT TO. Khususnya, setiap tautan yang disandikan yang ditujukan untuk penerima RCPT TO akan identik dalam pesan arsip

Satu-satunya perbedaan dari email RCPT TO adalah beberapa header akan berbeda karena alamat target untuk email pengarsipan berbeda, tetapi isi email akan menjadi replika yang sama persis!

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

Sebagai catatan tambahan, SparkPost sebenarnya memungkinkan Anda untuk mengirim email ke alamat email cc, bcc, dan arsip. Untuk solusi ini, kami fokus pada alamat arsip.

* Pemberitahuan * Email yang diarsipkan HANYA dapat dibuat ketika memasukkan email ke SparkPost melalui SMTP!

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

• Memantul

• KlikTunda

• Pengiriman

• Kegagalan Generasi

• Penolakan Generasi

• Buka Awal

• InjectionLink Berhenti Berlangganan

• Daftar Berhenti Berlangganan

• Buka

• Keluar dari Band

• Penolakan KebijakanPengaduan Spam

* Follow tautan ini 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 Penyampaian Email Masuk. 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.

Jadi triknya adalah; bagaimana Anda merekatkan data keluar ke proses masuk yang baru saja mengambil versi email yang diarsipkan? Yang saya putuskan untuk dilakukan adalah menyembunyikan id unik di badan email. Bagaimana cara melakukannya terserah Anda, tetapi saya hanya membuat kolom input dengan tag tersembunyi yang diaktifkan.

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

Saya juga menambahkan bidang tersebut ke dalam blok metadata header X-MSYS-API yang diteruskan ke SparkPost selama injeksi. UID tersembunyi ini pada akhirnya akan menjadi perekat seluruh proses, dan merupakan komponen utama dari proyek ini dan akan dibahas secara mendalam dalam posting blog berikut.

Sekarang setelah kita memiliki UID yang akan merekatkan proyek ini dan memahami mengapa hal ini diperlukan, saya dapat mulai membangun visi proyek secara keseluruhan dan posting blog yang sesuai.

1. Menangkap dan menyimpan arsip email bersama dengan entri basis data untuk pencarian/pengindeksan

2. Menangkap semua data peristiwa pesan

3. Buat aplikasi untuk melihat email dan semua data terkait

Berikut ini adalah diagram sederhana dari proyek ini:

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.

Selamat mengirim.

- Jeff

Lampiran A: