Mengapa membangun sistem pengarsipan email Anda sendiri?

Industri yang diatur sering kali memerlukan penyimpanan jangka panjang baik isi email maupun semua catatan kejadian terkait. SparkPost tidak menyimpan isi pesan, sehingga membangun sistem kustom memastikan kepatuhan, audit, dan visibilitas.

Bagaimana cara Anda mendapatkan salinan persis dari email terkirim yang asli?

Fitur Archive dari SparkPost mengirim salinan setiap email keluar ke alamat arsip yang ditentukan, mempertahankan semua tautan yang terkode dan perilaku pelacakan.

Mengapa Anda tidak bisa menangkap isi email sebelum mengirim?

Penangkapan sebelum mengirim tidak termasuk modifikasi SparkPost (pelacakan pembukaan, pelacakan klik, pengkodean tautan). Menggunakan salinan Arsip memastikan versi yang Anda simpan persis sesuai dengan apa yang diterima penerima.

Apakah SparkPost menyimpan email secara otomatis?

Tidak. SparkPost tidak menyimpan isi pesan. Salinan arsip harus diminta dengan menentukan alamat arsip selama injeksi SMTP.

Apa yang disimpan di mana dalam sistem pengarsipan ini?

Isi email → Amazon S3 Log acara pesan → MySQL Pemisahan ini mendukung pencarian cepat, kueri terstruktur, dan penyimpanan objek yang hemat biaya.

Berapa lama SparkPost menyimpan data acara?

SparkPost menyimpan acara pesan selama 10 hari . Setelah itu, data harus diambil melalui webhook atau ditanyakan dan disimpan di tempat lain.

Apa saja acara pesan yang tersedia?

SparkPost saat ini mengungkapkan 14 kejadian, termasuk pengiriman, pantulan, klik, terbuka, penolakan, masalah kebijakan, keluhan spam, berhenti berlangganan, dan lainnya.

Apa pengenal yang menghubungkan semua acara bersama?

Semua pesan keluar (asli, arsip, CC, BCC) berbagi transmission_id yang sama. Email asli dan arsip juga berbagi message_id yang sama.

Mengapa pemrosesan inbound menjadi tantangan?

SparkPost’s Inbound Email Relay mengubah email masuk menjadi JSON, tetapi JSON ini tidak termasuk transmission_id. Tanpa data tambahan, salinan masuk tidak dapat dihubungkan ke riwayat log keluarannya.

Bagaimana cara Anda menghubungkan email arsip masuk ke acara pesan keluar?

Sisipkan unique identifier (UID) tersembunyi di dalam badan email dan lewati UID yang sama dalam metadata. UID ini menjadi referensi bersama di antara catatan masuk dan keluar.

Bagaimana Inbound Email Relay membantu otomatisasi pengarsipan?

Ini menerima email arsip yang dikirim ke domain arsip Anda, menguraikannya menjadi JSON terstruktur, dan mengirimkannya ke aplikasi Anda melalui webhook—memungkinkan ekstraksi dan penyimpanan otomatis.

Apa visi jangka panjang dari proyek ini?

Aplikasi lengkap yang: Menyimpan email arsip di S3 Menyimpan semua log acara di MySQL Memungkinkan pengguna mencari email Menampilkan email asli dan setiap acara terkait dalam satu antarmuka terpadu

Mengatasi Tantangan dalam Membangun Sistem Pengarsipan Email

Setahun yang lalu saya menulis sebuah blog tentang cara mengambil salinan email untuk keperluan arsip dan peninjauan tetapi saya tidak membahas penyimpanan email atau data terkait, dan baru-baru ini saya menulis sebuah blog tentang penyimpanan semua data acara (misalnya kapan email dikirim, terbuka, klik bounce, 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 menggabungkan semua ini dengan contoh kode tentang cara menyimpan tubuh email dan semua data terkaitnya. Selama tahun depan, saya akan terus membangun 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 tubuh email tetapi memungkinkan pembuatan platform arsip menjadi cukup mudah.

Dalam rangkaian blog ini, saya akan menjelaskan proses yang saya lalui untuk menyimpan tubuh email ke S3 (Layanan Penyimpanan Sederhana Amazon) dan semua data log relevan di MySQL untuk referensi silang yang mudah. Untuk sistem arsip produksi yang memerlukan strategi cadangan 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 akan 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: PHPArchivePlatform di GitHub

Entri pertama dari rangkaian blog ini akan menggambarkan tantangan dan menyusun arsitektur untuk solusi. Sisanya dari blog akan merinci bagian-bagian dari solusi bersama dengan contoh kode.

Langkah pertama dalam proses saya adalah memikirkan cara saya akan mendapatkan salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan tubuh email, Anda perlu:

Menangkap tubuh email sebelum mengirim email
Meminta server email menyimpan salinannya
Meminta server email membuat 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 terbuka/klik.

Artinya, server harus menyimpan email atau dengan cara tertentu 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 duplikasi 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 dari email ke satu atau lebih alamat email dan menggunakan tautan pelacakan dan terbuka yang sama dengan yang asli. Dokumentasi SparkPost mendefinisikan fitur Arsip mereka sebagai berikut:

Penerima dalam daftar arsip akan menerima replika persis pesan yang dikirim ke alamat RCPT TO. Khususnya, setiap tautan yang dienkode 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 pengarsip berbeda, tetapi tubuh email akan menjadi replika persis!

Jika Anda menginginkan penjelasan lebih dalam, berikut adalah tautan ke dokumentasi SparkPost tentang membuat salinan duplikat (atau arsip) dari email.

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

* Perhatian * Email yang diarsipkan HANYA dapat dibuat saat menyuntikkan email ke SparkPost melalui SMTP!

Sekarang setelah kita tahu cara mendapatkan 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 peristiwa pesan. Peristiwa-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 mendorong peristiwa-peristiwa tersebut ke sejumlah aplikasi pengumpulan yang Anda inginkan. Mekanisme pendorongan dilakukan melalui webhook dan dilakukan secara real-time.

Saat ini, ada 14 peristiwa berbeda yang mungkin terjadi pada sebuah 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 terkini 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 dalam setiap peristiwa, tetapi bidang lain mungkin lebih spesifik peristiwa; misalnya, hanya peristiwa terbuka 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 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. Semua alamat cc atau bcc akan memiliki id mereka sendiri untuk entri message_id.

Sejauh ini terdengar bagus dan cukup mudah, tetapi sekarang adalah bagian yang menantang. Ingat, untuk mendapatkan email arsip, kami meminta SparkPost mengirimkan duplikat email asli ke alamat email lain yang sesuai dengan beberapa inbox yang Anda akses. Tetapi untuk mengotomatiskan solusi ini dan menyimpan tubuh 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, itu memisahkan email dan membuat struktur JSON yang kemudian dikirimkan ke aplikasi melalui webhook. Lihat Lampiran A untuk sampel JSON.

Jika Anda melihat dengan sangat cermat, Anda akan menyadari bahwa struktur JSON dari relay masuk tidak memiliki 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, cc, dan bcc; SparkPost tidak memiliki cara untuk mengetahui bahwa email yang ditangkap oleh proses masuk terhubung dengan email keluar mana pun. Proses masuk hanya tahu bahwa email dikirim ke domain tertentu dan untuk mem-parsing email. Itu saja. Ini akan memperlakukan email yang dikirim ke domain itu dengan cara yang sama, baik itu balasan dari pelanggan atau email arsip yang dikirim dari SparkPost.

Jadi triknya adalah; bagaimana Anda 'merekatkan' data keluar ke proses masuk yang baru saja menangkap versi arsip dari email? Apa yang saya putuskan untuk dilakukan adalah menyembunyikan ID unik dalam tubuh email. Bagaimana ini dilakukan terserah Anda, tetapi saya hanya membuat field input dengan tag tersembunyi diaktifkan.

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

Saya juga menambahkan field itu ke dalam blok metadata dari header X-MSYS-API yang diteruskan ke SparkPost selama penyuntikan. UID tersembunyi ini akan menjadi lem untuk seluruh proses, dan merupakan komponen utama dari proyek dan akan dibahas secara mendalam dalam posting blog berikutnya.

Sekarang kita memiliki UID yang akan menghubungkan proyek ini dan memahami mengapa itu diperlukan, saya dapat mulai membangun visi proyek secara keseluruhan dan posting blog terkait.

Menangkap dan menyimpan email arsip bersama dengan entri database untuk pencarian/pengkatalogan
Menangkap semua data peristiwa pesan
Membuat aplikasi untuk melihat email dan semua data terkait

Berikut adalah diagram sederhana dari proyek:

build an email archiving system - diagram

Penurunan kode pertama akan mencakup proses arsip dan menyimpan email ke S3, sementara penurunan kode kedua akan mencakup menyimpan semua data log dari peristiwa-pesan ke MySQL. Anda dapat mengharapkan dua penurunan kode pertama dan entri blog sekitar awal 2019. Jika Anda memiliki pertanyaan atau saran, silakan kirimkan.

Selamat Mengirim.
– Jeff

Lampiran A:

JSON file example - email archiving system

Setahun yang lalu saya menulis sebuah blog tentang cara mengambil salinan email untuk keperluan arsip dan peninjauan tetapi saya tidak membahas penyimpanan email atau data terkait, dan baru-baru ini saya menulis sebuah blog tentang penyimpanan semua data acara (misalnya kapan email dikirim, terbuka, klik bounce, 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 menggabungkan semua ini dengan contoh kode tentang cara menyimpan tubuh email dan semua data terkaitnya. Selama tahun depan, saya akan terus membangun 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 tubuh email tetapi memungkinkan pembuatan platform arsip menjadi cukup mudah.

Dalam rangkaian blog ini, saya akan menjelaskan proses yang saya lalui untuk menyimpan tubuh email ke S3 (Layanan Penyimpanan Sederhana Amazon) dan semua data log relevan di MySQL untuk referensi silang yang mudah. Untuk sistem arsip produksi yang memerlukan strategi cadangan 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 akan 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: PHPArchivePlatform di GitHub

Entri pertama dari rangkaian blog ini akan menggambarkan tantangan dan menyusun arsitektur untuk solusi. Sisanya dari blog akan merinci bagian-bagian dari solusi bersama dengan contoh kode.

Langkah pertama dalam proses saya adalah memikirkan cara saya akan mendapatkan salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan tubuh email, Anda perlu:

Menangkap tubuh email sebelum mengirim email
Meminta server email menyimpan salinannya
Meminta server email membuat salinan untuk Anda simpan