Dengan meningkatnya penggunaan email dalam lingkungan regulasi, saya memutuskan bahwa ini saatnya untuk memulai proyek baru yang mengumpulkan semua ini dengan contoh kode tentang cara menyimpan isi email dan semua data terkaitnya.
Sekitar setahun yang lalu, saya menulis sebuah blog tentang cara mengambil salinan email untuk arsip dan penayangan tetapi saya tidak membahas penyimpanan email atau data terkait, dan baru-baru ini saya menulis sebuah blog tentang penyimpanan semua data peristiwa (misalnya kapan email dikirim, dibuka, klik, terpental, berhenti berlangganan, dll) pada email untuk tujuan audit, tetapi memilih untuk tidak membuat kode pendukung.
Dengan meningkatnya penggunaan email di lingkungan peraturan, saya memutuskan bahwa sudah waktunya untuk memulai proyek baru yang menggabungkan semuanya dengan contoh kode tentang cara menyimpan tubuh email dan semua data yang terkait. Selama tahun depan, saya akan terus membangun proyek ini dengan tujuan membuat aplikasi penyimpanan dan penayangan yang berfungsi untuk email yang diarsipkan dan semua informasi log yang dihasilkan oleh SparkPost. SparkPost tidak memiliki sistem yang mengarsipkan tubuh email, tetapi memudahkan membangun platform arsip.
Dalam seri blog ini, saya akan menjelaskan proses yang saya lalui untuk menyimpan tubuh email ke S3 (Amazon's Simple Store Service) dan semua data log terkait di MySQL untuk referensi silang yang mudah. Untuk sistem pengarsipan produksi yang memerlukan strategi cadangan database yang kuat, pertimbangkan mengimplementasikan proses cadangan dan pemulihan PostgreSQL yang komprehensif untuk memastikan data arsip Anda terlindungi dengan baik. Akhirnya, ini adalah titik awal untuk membangun aplikasi yang memungkinkan pencarian email yang diarsipkan dengan mudah, lalu menampilkan email tersebut bersama data peristiwa (log). Kode untuk proyek ini dapat ditemukan dalam repositori GitHub berikut: PHPArchivePlatform di GitHub
Entree pertama dari seri blog ini akan menjelaskan tantangan dan membuat arsitektur untuk solusinya. Blog-blog lainnya akan merinci bagian-bagian dari solusi bersama dengan contoh kode.
Langkah pertama dalam proses saya adalah menentukan cara saya akan memperoleh salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan tubuh email, Anda perlu:
Menangkap tubuh email sebelum mengirim email
Membiarkan server email menyimpan salinan
Meminta server email membuatkan salinan untuk Anda simpan
Jika server email menambahkan item seperti pelacakan tautan atau pelacakan terbuka, Anda tidak dapat menggunakan #1 karena itu tidak akan mencerminkan perubahan pelacakan membuka/klik.
Itu berarti server harus menyimpan email atau entah bagaimana menawarkan salinan email tersebut kepada Anda untuk disimpan. Karena SparkPost tidak memiliki mekanisme penyimpanan untuk tubuh email tetapi memiliki cara untuk membuat salinan email, kami akan meminta SparkPost mengirimkan duplikat email kepada kami untuk disimpan di S3.
Ini dilakukan dengan menggunakan fitur Arsip SparkPost. Fitur Arsip SparkPost memberi pengirim kemampuan untuk memberi tahu SparkPost untuk mengirim duplikat email ke satu atau lebih alamat email dan menggunakan tautan pelacakan dan buka yang sama seperti aslinya. Dokumentasi SparkPost mendefinisikan fitur Arsip mereka dengan cara berikut:
Penerima dalam daftar arsip akan menerima replika identik dari pesan yang dikirim ke alamat RCPT TO. Secara khusus, setiap tautan yang dikodekan yang ditujukan untuk penerima RCPT TO akan sama dalam pesan arsip
Satu-satunya perbedaan dari email RCPT TO adalah bahwa beberapa header akan berbeda karena alamat target untuk email pengarsipan berbeda, tetapi tubuh email akan menjadi replika identik!
Jika Anda ingin penjelasan yang lebih mendalam, berikut adalah tautan ke dokumentasi SparkPost tentang membuat salinan (atau arsip) lawan email.
Sebagai catatan, SparkPost sebenarnya memungkinkan Anda untuk mengirim email ke alamat cc, bcc, dan arsip. Untuk solusi ini, kami berfokus pada alamat arsip.
* Peringatan * Email yang diarsipkan HANYA dapat dibuat saat meneruskan email ke SparkPost melalui SMTP!
Sekarang setelah kita tahu cara memperoleh salinan email asli, kita perlu melihat data log yang dihasilkan dan beberapa nuansa halus dalam data tersebut. SparkPost melacak semua yang terjadi di servernya dan menawarkan informasi tersebut kepada Anda dalam bentuk pesan-peristiwa. Peristiwa tersebut disimpan di SparkPost selama 10 hari dan dapat diambil dari server melalui API RESTful yang disebut pesan-peristiwa, atau Anda dapat meminta SparkPost mendorong peristiwa tersebut ke sejumlah aplikasi pengumpul yang Anda inginkan. Mekanisme dorongan dilakukan melalui webhooks dan dilakukan secara waktu nyata.
Saat ini, ada 14 peristiwa berbeda yang dapat terjadi pada email. Berikut adalah daftar peristiwa saat ini:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Ikuti tautan ini untuk panduan referensi terbaru untuk deskripsi setiap peristiwa bersama dengan data yang dibagikan untuk setiap peristiwa.
Setiap peristiwa memiliki banyak bidang yang sesuai dengan jenis peristiwa. Beberapa bidang seperti transmission_id ditemukan di setiap peristiwa, tetapi bidang lainnya mungkin lebih khusus untuk peristiwa tersebut; misalnya, hanya peristiwa buka dan klik yang memiliki informasi geotag.
Satu entri peristiwa pesan yang sangat penting untuk proyek ini adalah transmission_id. Semua entri peristiwa pesan untuk email asli, email arsip, dan alamat cc dan bcc akan berbagi transmission_id yang sama.
Ada juga entri umum yang disebut message_id yang akan memiliki id yang sama untuk setiap entri dari email asli dan email yang diarsipkan. Setiap alamat cc atau bcc akan memiliki id mereka sendiri untuk entri message_id.
Sejauh ini semua terdengar bagus dan sejujurnya cukup mudah, tetapi sekarang adalah bagian yang menantang. Ingat, untuk mendapatkan email arsip, kami meminta SparkPost mengirimkan duplikat dari email asli ke alamat email lain yang sesuai dengan kotak masuk yang Anda miliki aksesnya. Tetapi untuk mengotomatisasi solusi ini dan menyimpan tubuh email, saya akan menggunakan fitur SparkPost yang lain yang disebut Inbound Email Relaying. Apa yang dilakukan adalah mengambil semua email yang dikirim ke domain tertentu dan memprosesnya. Dengan memprosesnya, ia memisahkan email dan membuat struktur JSON yang kemudian disampaikan ke aplikasi melalui webhook. Lihat Lampiran A untuk contoh JSON.
Jika Anda memperhatikan dengan sangat cermat, Anda akan melihat bahwa struktur JSON dari inbound relay kehilangan satu field yang sangat penting; transmission_id. Sementara semua email keluar memiliki transmission_id dengan entri yang sama yang mengikat semua data dari email asli, arsip, alamat cc, dan bcc; SparkPost tidak punya cara untuk mengetahui bahwa email yang ditangkap oleh proses inbound terhubung ke salah satu email keluar. Proses inbound hanya tahu bahwa email dikirim ke domain tertentu dan untuk menganalisis email tersebut. Itu saja. Itu akan memperlakukan email apa pun yang dikirim ke domain tersebut dengan cara yang sama, entah itu balasan dari pelanggan atau email arsip yang dikirim dari SparkPost.
Jadi triknya adalah; bagaimana cara Anda menghubungkan data keluar dengan proses masuk yang baru saja mengambil versi arsip dari email tersebut? Apa yang saya putuskan untuk lakukan adalah menyembunyikan id unik di dalam tubuh email. Bagaimana ini dilakukan terserah Anda, tetapi saya hanya membuat field input dengan tag tersembunyi diaktifkan.
Saya juga menambahkan field itu ke dalam blok metadata dari header X-MSYS-API yang diteruskan ke SparkPost saat penyuntikan. UID tersembunyi ini akan menjadi pengait untuk seluruh proses, dan merupakan komponen utama dari proyek dan akan dibahas secara mendalam di posting blog berikutnya.
Sekarang setelah kita memiliki UID yang akan menghubungkan proyek ini dan memahami mengapa itu perlu, saya dapat mulai membangun visi dari keseluruhan proyek dan posting blog yang sesuai.
Menangkap dan menyimpan email arsip beserta entri database untuk pencarian/indeksasi
Menangkap semua data peristiwa pesan
Membuat aplikasi untuk melihat email dan semua data terkait
Berikut adalah diagram sederhana dari proyek ini:
Penurunan kode pertama akan mencakup proses arsip dan menyimpan email ke S3, sedangkan penurunan kode kedua akan mencakup penyimpanan semua data log dari message-events ke dalam MySQL. Anda dapat mengharapkan dua penurunan kode pertama dan entri blog di awal 2019. Jika Anda memiliki pertanyaan atau saran, jangan ragu untuk menyampaikannya.
Selamat Mengirim.
– Jeff
Lampiran A:
