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 bagaimana mendapatkan salinan email untuk arsip dan peninjauan tetapi saya tidak membahas penyimpanan email atau data terkait secara langsung, dan baru-baru ini saya menulis sebuah blog tentang penyimpanan semua data acara (misalnya saat email dikirim, dibuka, klik, pantulan, berhenti berlangganan, dll) pada sebuah email untuk tujuan audit, tetapi memilih untuk tidak membuat kode pendukung.
Dengan meningkatnya penggunaan email di lingkungan regulasi, saya memutuskan inilah saatnya untuk memulai proyek baru yang menyatukan semua ini dengan contoh kode tentang bagaimana menyimpan badan email dan semua data terkaitnya. Selama tahun depan, saya akan terus mengembangkan proyek ini dengan tujuan menciptakan aplikasi penyimpanan dan peninjauan yang berfungsi untuk email yang diarsipkan dan semua informasi log yang dihasilkan oleh SparkPost. SparkPost tidak memiliki sistem yang mengarsipkan badan email tetapi membuat pembuatan platform arsip cukup mudah.
Dalam seri blog ini, saya akan menjelaskan proses yang saya lalui untuk menyimpan badan email ke S3 (Layanan Penyimpanan Sederhana Amazon) dan semua data log terkait di MySQL untuk referensi silang yang mudah. Untuk sistem pengarsipan produksi yang memerlukan strategi pencadangan basis data yang kuat, pertimbangkan untuk menerapkan proses pencadangan 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 dengan data acara (log). Kode untuk proyek ini dapat ditemukan dalam repositori GitHub berikut: https://github.com/jeff-goldstein/PHPArchivePlatform
Entri pertama dari seri blog ini akan menggambarkan tantangan dan menetapkan arsitektur untuk solusinya. Selanjutnya, blog lain akan merincikan bagian dari solusi ini beserta contoh kodenya.
Langkah pertama dalam proses saya adalah mencari cara bagaimana saya akan mendapatkan salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan badan email, Anda perlu:
Menangkap badan email sebelum mengirim email
Membuat server email menyimpan salinan
Membuat server email menghasilkan salinan untuk Anda simpan
Jika server email menambahkan item seperti pelacakan link atau pelacakan pembukaan, Anda tidak dapat menggunakan #1 karena itu tidak akan mencerminkan perubahan pelacakan pembukaan/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 badan 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 dari SparkPost. Fitur Arsip dari SparkPost memberikan kemampuan kepada pengirim untuk memberitahu SparkPost agar mengirimkan duplikat email ke satu atau lebih alamat email dan menggunakan pelacakan yang sama dan tautan terbuka yang sama dengan aslinya. Dokumentasi SparkPost mendefinisikan fitur Arsip mereka dengan cara berikut:
Penerima dalam daftar arsip akan menerima replika persis dari pesan yang dikirim ke alamat RCPT TO. Khususnya, tautan yang dikodekan yang dimaksudkan 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 yang diarsipkan berbeda, tetapi badan email akan menjadi replika persis!
Jika Anda menginginkan penjelasan lebih dalam, berikut adalah tautan ke dokumentasi SparkPost tentang cara membuat salinan duplikat (atau arsip) dari sebuah email.
Sebagai catatan tambahan, SparkPost sebenarnya memungkinkan Anda mengirim email ke alamat cc, bcc, dan arsip. Untuk solusi ini, kami fokus pada alamat arsip.
* Pemberitahuan * Email yang diarsipkan hanya dapat dibuat ketika menyuntikkan email ke SparkPost via SMTP!
Sekarang setelah kami tahu cara mendapatkan salinan dari email asli, kami 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 event-message. Acara tersebut disimpan di SparkPost selama 10 hari dan dapat diambil dari server melalui API RESTful yang disebut message-events, atau Anda dapat meminta SparkPost mengirimkan acara tersebut ke sejumlah aplikasi pengumpul yang Anda inginkan. Mekanisme pengiriman dilakukan melalui webhook dan dilakukan secara real-time.
Saat ini, ada 14 acara berbeda yang dapat terjadi pada sebuah email. Berikut adalah daftar acara saat ini:
Pantulan
ClickDelay
Pengiriman
Kegagalan Generasi
Penolakan Generasi
Pembukaan Awal
InjectionLink Berhenti Berlangganan
Berhenti Berlangganan Daftar
Pembukaan
Out of Band
Kebijakan Penolakan Keluhan Spam
* Ikuti tautan ini untuk panduan referensi terbaru untuk deskripsi setiap acara beserta data yang dibagikan untuk setiap acara.
Setiap acara memiliki banyak bidang yang sesuai dengan jenis acara tersebut. Beberapa bidang seperti transmission_id ditemukan dalam setiap event, tetapi bidang lainnya mungkin lebih spesifik pada event tertentu; misalnya, hanya acara buka dan klik yang memiliki informasi geotag.
Salah satu entri acara pesan yang sangat penting untuk proyek ini adalah transmission_id. Semua entri acara pesan untuk email asli, email yang diarsipkan, dan semua alamat cc dan bcc akan berbagi transmission_id yang sama.
Juga terdapat entri umum bernama 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, ini terdengar bagus dan jujur cukup mudah, tetapi sekarang adalah bagian yang menantang. Ingat, agar mendapatkan email arsip, kami meminta SparkPost mengirimkan duplikat dari email asli ke alamat email lain yang sesuai dengan inbox yang Anda miliki aksesnya. Namun untuk mengotomatisasi solusi ini dan menyimpan badan email, saya akan menggunakan fitur lain dari SparkPost yang disebut Inbound Email Relaying. Apa yang dilakukan adalah mengambil semua email yang dikirim ke domain tertentu dan memprosesnya. Dengan memprosesnya, ia memecah email dan membuat struktur JSON yang kemudian dikirim ke aplikasi melalui webhook. Lihat Lampiran A untuk contoh JSON.
Jika Anda melihat dengan sangat hati-hati, Anda akan melihat bahwa struktur JSON dari inbound relay kehilangan 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, cc, dan bcc; SparkPost tidak memiliki cara untuk mengetahui bahwa email yang ditangkap oleh proses inbound terhubung ke salah satu email keluar. Proses inbound hanya tahu bahwa email telah dikirim ke domain tertentu dan memparse email tersebut. Itu saja. Ia akan memperlakukan setiap email yang dikirim ke domain tersebut dengan cara yang sama, baik itu balasan dari pelanggan atau email yang diarsipkan yang dikirim dari SparkPost.
Jadi triknya adalah; bagaimana Anda menghubungkan data keluar dengan proses inbound yang baru saja mengambil versi email yang diarsipkan? Apa yang saya putuskan untuk lakukan adalah menyembunyikan id unik di badan email. Bagaimana ini dilakukan terserah Anda, tetapi saya hanya membuat field input dengan tag tersembunyi diaktifkan.
Saya juga menambahkan field tersebut ke dalam blok metadata dari header X-MSYS-API yang diteruskan ke SparkPost selama penyuntikan. UID tersembunyi ini akan menjadi pengikat untuk seluruh proses, dan merupakan komponen utama dari proyek ini yang akan dibahas secara mendalam dalam posting blog berikutnya.
Sekarang setelah kami memiliki UID yang akan menghubungkan proyek ini bersama-sama dan memahami mengapa itu perlu, saya dapat mulai membangun visi dari keseluruhan proyek dan posting blog yang sesuai.
Menangkap dan menyimpan email arsip bersama dengan entri basis data untuk pencarian/indeksasi
Menangkap semua data acara pesan
Membuat aplikasi untuk melihat email dan semua data yang sesuai
Berikut adalah diagram sederhana dari proyek:
Drop code pertama akan mencakup proses arsip dan menyimpan email ke S3, sedangkan drop code kedua akan mencakup penyimpanan semua data log dari message-events ke MySQL. Anda dapat mengharapkan drop code pertama dan blog entri pada awal 2019. Jika Anda memiliki pertanyaan atau saran, jangan ragu untuk menyampaikannya.
Selamat Mengirim.
– Jeff
Lampiran A:
