Sekitar setahun yang lalu saya menulis sebuah blog tentang bagaimana cara mengambil salinan email untuk arsip dan tampilan, tetapi saya tidak membahas tentang penyimpanan email atau data terkait, dan baru-baru ini saya menulis sebuah blog tentang menyimpan semua data acara (misalnya kapan email dikirim, dibuka, diklik, ditolak, berhenti berlangganan, dll) pada email untuk tujuan audit, tetapi memilih untuk tidak membuat kode pendukung.
Dengan meningkatnya penggunaan email dalam lingkungan regulasi, saya memutuskan sudah saatnya untuk memulai proyek baru yang mengumpulkan semua ini dengan contoh kode tentang bagaimana menyimpan isi email dan semua data terkait. Selama tahun depan, saya akan terus membangun 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 sebenarnya memudahkan untuk membangun platform arsip.
Dalam rangkaian blog ini, saya akan menjelaskan proses yang saya lalui untuk menyimpan isi email ke S3 (Layanan Penyimpanan Sederhana Amazon) dan semua data log relevan di MySQL untuk referensi silang yang mudah. Pada akhirnya, ini adalah titik awal untuk membangun aplikasi yang akan memungkinkan pencarian email yang diarsipkan dengan mudah, kemudian menampilkan email tersebut bersama dengan data acara (log). Kode untuk proyek ini dapat ditemukan di repositori GitHub berikut: https://github.com/jeff-goldstein/PHPArchivePlatform
Entri pertama dari rangkaian blog ini akan menggambarkan tantangan dan merancang sebuah arsitektur untuk solusi. Sisa blog akan menjabarkan bagian-bagian dari solusi bersama dengan contoh kode.
Langkah pertama dalam proses saya adalah mencari tahu bagaimana saya akan mendapatkan salinan dari email yang dikirim kepada penerima asli. Untuk mendapatkan salinan dari isi email, Anda perlu:
Menangkap isi email sebelum mengirim email
Mendapatkan server email untuk menyimpan salinan
Meminta server email untuk membuat salinan untuk Anda simpan
Jika server email menambahkan item seperti pelacakan tautan atau pelacakan pembukaan, Anda tidak dapat menggunakan #1 karena itu tidak akan mencerminkan perubahan pelacakan pembukaan/klik.
Itu berarti bahwa baik server harus menyimpan email atau dengan cara tertentu menawarkan salinan dari email tersebut kepada Anda untuk disimpan. Karena SparkPost tidak memiliki mekanisme penyimpanan untuk isi email tetapi memiliki cara untuk membuat salinan email, kami akan meminta SparkPost untuk mengirimkan kami duplikat dari email tersebut untuk disimpan di S3.
Ini dilakukan dengan menggunakan fitur Arsip SparkPost. Fitur Arsip SparkPost memberi pengirim kemampuan untuk memberi tahu SparkPost agar mengirimkan duplikat dari email ke satu atau lebih alamat email dan menggunakan tautan pelacakan dan pembukaan yang sama dengan yang asli. Dokumentasi SparkPost mendefinisikan fitur Arsip mereka sebagai berikut:
Penerima dalam daftar arsip akan menerima replika yang persis dari pesan yang dikirim ke alamat RCPT TO. Secara khusus, setiap tautan yang dikodekan yang ditujukan untuk penerima RCPT TO akan identik dalam pesan arsip
Satu-satunya perbedaan dari email RCPT TO adalah bahwa beberapa header akan berbeda karena alamat target untuk email arsip berbeda, tetapi isi emailnya akan menjadi replika yang persis!
Jika Anda ingin penjelasan yang lebih mendalam, berikut adalah tautan ke dokumentasi SparkPost tentang cara membuat salinan duplikat (atau arsip) dari sebuah email.
Sebagai catatan sampingan, SparkPost sebenarnya memungkinkan Anda untuk mengirim email ke cc, bcc, dan alamat email arsip. Untuk solusi ini, kami fokus pada alamat arsip.
* Pemberitahuan * Email yang diarsipkan hanya dapat dibuat saat menyuntikkan email ke SparkPost melalui SMTP!
Sekarang setelah kita tahu bagaimana cara mendapatkan salinan dari email asli, kita perlu melihat data log yang dihasilkan dan beberapa nuansa halus dalam data itu. SparkPost melacak segala sesuatu yang terjadi di servernya dan menawarkan informasi itu kepada Anda dalam bentuk peristiwa pesan. Peristiwa tersebut disimpan di SparkPost selama 10 hari dan dapat diambil dari server melalui API RESTful yang disebut peristiwa pesan, atau Anda dapat meminta SparkPost untuk mengirimkan peristiwa tersebut ke sejumlah aplikasi pengumpul yang Anda inginkan. Mekanisme dorongan ini dilakukan melalui webhook dan berlangsung secara real-time.
Saat ini, ada 14 peristiwa berbeda yang mungkin terjadi pada sebuah email. Berikut adalah daftar peristiwa yang ada saat ini:
Ditolak
ClickDelay
Pengiriman
Gagal Generasi
Penolakan Generasi
Pembukaan Awal
Unsubscribe Tautan Injeksi
Unsubscribe Daftar
Membuka
Di Luar Jalur
Penolakan KebijakanKeluhan Spam
* Ikuti tautan ini untuk panduan referensi terkini untuk deskripsi setiap peristiwa bersama dengan data yang dibagikan untuk setiap peristiwa.
Setiap peristiwa memiliki banyak bidang yang cocok dengan jenis peristiwa. Beberapa bidang seperti transmission_id ditemukan di setiap peristiwa, tetapi bidang lainnya mungkin lebih spesifik untuk peristiwa tersebut; misalnya, hanya peristiwa pembukaan 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 memiliki 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 arsip. Alamat cc atau bcc akan memiliki id mereka sendiri untuk entri message_id tersebut.
Sejauh ini terdengar hebat dan jujur 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 beberapa kotak masuk yang Anda akses. Tetapi untuk mengotomatisasi solusi ini dan menyimpan isi email, saya akan menggunakan fitur lain dari SparkPost yang disebut Pengiriman Email Masuk. Apa yang dilakukan fitur ini adalah mengambil semua email yang dikirim ke domain tertentu dan memprosesnya. Dengan memprosesnya, email akan dipisahkan menjadi bagian-bagiannya dan membuat struktur JSON yang kemudian dikirimkan ke aplikasi melalui webhook. Lihat Lampiran A untuk contoh JSON.
Jika Anda melihat dengan sangat teliti, Anda akan menyadari bahwa struktur JSON dari pengalihan masuk hilang satu bidang 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 memiliki cara untuk mengetahui bahwa email yang ditangkap oleh proses masuk tersebut terhubung dengan email keluar mana pun. Proses masuk hanya tahu bahwa sebuah email telah dikirim ke domain tertentu dan untuk mem-parsi email tersebut. Itu saja. Proses ini akan memperlakukan setiap email yang dikirim ke domain tersebut dengan cara yang sama, baik itu balasan dari pelanggan atau email arsip yang dikirim dari SparkPost.
Jadi, triknya adalah; bagaimana Anda menghubungkan data keluar ke proses masuk yang baru saja menangkap versi email yang diarsipkan? Apa yang saya putuskan untuk dilakukan adalah menyembunyikan id unik di dalam isi email. Bagaimana ini dilakukan terserah Anda, tetapi saya hanya membuat bidang input dengan tag tersembunyi yang aktif.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Saya juga menambahkan bidang itu ke dalam blok metadata dari header X-MSYS-API yang diteruskan ke SparkPost selama injeksi. UID tersembunyi ini akan menjadi pengikat untuk seluruh proses ini, dan merupakan komponen utama dari proyek dan akan dibahas secara mendalam dalam blog-post berikutnya.
Sekarang setelah kami memiliki UID yang akan mengikat proyek ini bersama dan memahami mengapa itu diperlukan, saya dapat mulai membangun visi keseluruhan proyek dan blog-post yang sesuai.
Menangkap dan menyimpan email arsip bersama dengan entri database untuk pencarian/pengindeksan
Menangkap semua data peristiwa pesan
Membuat aplikasi untuk melihat email dan semua data terkait
Berikut adalah diagram sederhana dari proyek:
Penurunan kode pertama akan mencakup proses arsip dan menyimpan email ke S3, sedangkan penurunan kode kedua akan mencakup penyimpanan semua data log dari peristiwa pesan ke dalam MySQL. Anda dapat mengharapkan dua penurunan kode pertama dan entri blog pada awal tahun 2019. Jika Anda memiliki pertanyaan atau saran, silakan kirimkan kepada kami.
Selamat Mengirim.
– Jeff
Lampiran A:
