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 tampilan namun saya tidak membahas penyimpanan email atau data terkait, dan baru-baru ini saya menulis sebuah blog tentang penyimpanan semua data acara (misalnya saat email dikirim, dibuka, klik yang terpental, berhenti berlangganan, dll) pada sebuah email untuk tujuan audit, tetapi memilih untuk tidak membuat kode pendukung apapun.
Dengan meningkatnya penggunaan email dalam lingkungan regulasi, saya memutuskan bahwa sekarang adalah waktu yang tepat untuk memulai proyek baru yang menggabungkan semua ini dengan contoh kode tentang cara menyimpan badan email dan semua data terkaitnya. Selama tahun depan, saya akan terus mengembangkan proyek ini dengan tujuan untuk menciptakan aplikasi penyimpanan dan tampilan yang berfungsi untuk email yang diarsipkan dan semua informasi log yang dihasilkan oleh SparkPost. SparkPost tidak memiliki sistem yang mengarsipkan badan email tetapi memudahkan pembuatan platform arsip.
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 yang relevan 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 dilindungi dengan baik. Akhirnya, ini adalah titik awal untuk membangun aplikasi yang memungkinkan pencarian mudah email yang diarsipkan, 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 seri blog ini akan menggambarkan tantangan dan menyusun arsitektur untuk solusinya. Sisa dari blog akan merinci bagian-bagian dari solusi bersama dengan contoh kode.
Langkah pertama dalam proses saya adalah mencari cara untuk mendapatkan salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan badan email, Anda perlu melakukan salah satu dari berikut ini:
Mengambil badan email sebelum mengirim email
Mendapatkan server email untuk menyimpan salinan
Meminta server email membuat salinan untuk Anda simpan
Jika server email menambahkan item seperti pelacakan tautan atau pelacakan pembukaan, Anda tidak bisa menggunakan #1 karena itu tidak akan mencerminkan perubahan pelacakan pembukaan/klik.
Itu berarti bahwa server harus menyimpan email atau menawarkan salinan email tersebut untuk Anda simpan. 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 SparkPost. Fitur Arsip SparkPost memberi pengirim kemampuan untuk memberitahu SparkPost untuk mengirimkan duplikat email ke satu atau lebih alamat email dan menggunakan tautan pelacakan dan pembukaan yang sama seperti 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, setiap tautan yang dikodekan yang dimaksudkan 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 arsip berbeda, tetapi badan email akan merupakan replika persis!
Jika Anda ingin penjelasan lebih dalam, berikut adalah tautan ke dokumentasi SparkPost tentang membuat salinan duplikat (atau arsip) dari sebuah email.
Sebagai catatan sampingan, SparkPost sebenarnya memungkinkan Anda mengirim email ke alamat cc, bcc, dan arsip. Untuk solusi ini, kami berfokus pada alamat arsip.
* Perhatian * Email yang diarsipkan hanya dapat dibuat saat menginjeksi email ke SparkPost melalui SMTP!
Sekarang kita tahu cara mendapatkan salinan email asli, kita perlu melihat data log yang dihasilkan dan beberapa kehalusan dalam data tersebut. SparkPost melacak semua yang terjadi di servernya dan menawarkan informasi tersebut kepada Anda dalam bentuk acara pesan. Acara-acara tersebut disimpan di SparkPost selama 10 hari dan dapat diambil dari server melalui API RESTful yang disebut acara-pesan, atau Anda dapat meminta SparkPost mendorong acara-acara tersebut ke sejumlah aplikasi pengumpul yang Anda inginkan. Mekanisme push dilakukan melalui webhook dan dilakukan secara real-time.
Saat ini, ada 14 acara berbeda yang dapat terjadi pada sebuah email. Berikut ini adalah daftar acara saat ini:
Unbounced
KlikTunda
Pengiriman
Kegagalan Pembuatan
Penolakan Pembuatan
Pembukaan Awal
InjeksiTaut Berhenti Berlangganan
Daftar Berhenti Berlangganan
Pembukaan
Diluar Band
Penolakan KebijakanKeluhan Spam
* Ikuti tautan ini untuk panduan referensi terkini untuk deskripsi setiap acara bersama dengan data yang dibagikan untuk setiap acara.
Setiap acara memiliki banyak bidang yang cocok dengan jenis acaranya. Beberapa bidang seperti transmission_id ditemukan dalam setiap acara, tetapi bidang lain mungkin lebih spesifik acara; misalnya, hanya acara pembukaan dan klik yang memiliki informasi geotag.
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.
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 sendiri untuk entri message_id.
Sampai saat ini ini terdengar bagus 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 inbox yang Anda miliki aksesnya. Tetapi untuk mengotomatisasi solusi ini dan menyimpan badan email tersebut, saya akan menggunakan fitur lain dari SparkPost yang disebut Inbound Email Relaying. Apa yang dilakukannya adalah mengambil semua email yang dikirim ke domain tertentu dan memprosesnya. Dengan memprosesnya, ia memecah email tersebut dan menciptakan struktur JSON yang kemudian dikirim ke aplikasi melalui webhook. Lihat Lampiran A untuk contoh JSON.
Jika Anda melihat dengan teliti, Anda akan melihat bahwa struktur JSON dari inbound relay tidak memiliki satu bidang yang sangat penting; transmission_id. Sementara semua email keluar memiliki transmission_id yang sama yang mengikat semua data dari email asli, arsip, cc, dan alamat bcc; SparkPost tidak memiliki cara untuk mengetahui bahwa email yang ditangkap oleh proses inbound terhubung dengan email keluar mana pun. Proses inbound hanya tahu bahwa email dikirim ke domain tertentu dan untuk memparsing email tersebut. Itu saja. Ia akan memperlakukan email mana pun yang dikirim ke domain itu sama, baik itu balasan dari pelanggan atau email arsip yang dikirim dari SparkPost.
Jadi triknya adalah; bagaimana Anda menempelkan data keluar ke proses inbound yang baru saja mengambil versi arsip dari email? Yang saya putuskan untuk lakukan adalah menyembunyikan id unik di dalam badan email. Bagaimana hal ini dilakukan terserah Anda, tetapi saya hanya membuat field input dengan menyembunyikan tag menyala.
Saya juga menambahkan field itu ke dalam blok metadata dari header X-MSYS-API yang dilewatkan ke SparkPost saat penyuntikan. UID tersembunyi ini akan menjadi lem untuk seluruh proses, dan merupakan komponen utama dari proyek ini dan akan dibahas secara mendalam dalam posting blog berikutnya.
Sekarang kita memiliki UID yang akan merekatkan proyek ini bersama-sama dan memahami mengapa itu diperlukan, 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 terkait
Berikut adalah diagram sederhana dari proyek ini:
Pengeluaran pertama kode akan mencakup proses arsip dan menyimpan email ke S3, sedangkan pengeluaran kode kedua akan mencakup penyimpanan semua data log dari acara-pesan ke MySQL. Anda dapat mengharapkan dua pengeluaran kode pertama dan entri blog pada awal 2019. Jika Anda memiliki pertanyaan atau saran, silakan sampaikan.
Selamat Mengirim.
– Jeff
Lampiran A:
