Membangun Sistem Arsitektur Email: Tantangan dan Tentu Saja Solusi – Bagian 1
Jeff Goldstein
4 Feb 2019
1 min read
Poin Penting
Penyimpanan email semakin penting untuk lingkungan regulasi, kepatuhan, dan audit.
SparkPost tidak menyimpan badan email, tetapi fitur Arsip memungkinkan pengirim menerima pesan duplikat yang mencerminkan tautan pelacakan dan konten.
Badan email dapat disimpan di Amazon S3, sementara metadata peristiwa pesan dapat disimpan di MySQL untuk kueri dan referensi silang.
Peristiwa pesan SparkPost memberikan catatan aktivitas yang kaya (pantulan, pengiriman, klik, pembukaan, penghapusan langganan, keluhan, dan lainnya).
Salinan arsip hanya dihasilkan ketika mengirim email melalui SMTP.
Peristiwa pesan untuk email asli, arsip, CC, dan BCC memiliki transmission_id yang sama.
Relay Email Masuk dapat mengolah pesan yang diarsipkan tetapi tidak menyertakan transmission_id, menciptakan tantangan penghubungan data.
Menanamkan pengidentifikasi unik tersembunyi (UID) dalam badan pesan menutup celah itu dan menghubungkan konten masuk dengan catatan keluar.
Menggabungkan email arsip + peristiwa pesan memungkinkan membangun sistem arsip yang dapat dicari dan diaudit.
Proyek jangka panjang mencakup rilis kode untuk menyimpan email arsip di S3 dan mencatat data peristiwa di MySQL.
Aplikasi akhir akan memungkinkan pencarian, melihat, dan rekonsiliasi konten email dengan seluruh riwayat peristiwa terkait dengan mudah.
Ideal untuk industri yang berat terhadap kepatuhan yang membutuhkan visibilitas lengkap ke setiap pesan yang dikirim.
Sorotan Tanya jawab
Mengapa membangun sistem pengarsipan email Anda sendiri?
Industri yang diatur sering kali memerlukan penyimpanan jangka panjang dari baik isi email maupun semua log acara terkait. SparkPost tidak menyimpan isi pesan, jadi membangun sistem kustom memastikan kepatuhan, audit, dan visibilitas.
Bagaimana cara Anda mendapatkan salinan tepat dari email asli yang dikirim?
Fitur Arsip SparkPost mengirimkan salinan setiap email keluar ke alamat arsip yang ditentukan, mempertahankan semua tautan yang di-encode dan perilaku pelacakan.
Mengapa Anda tidak dapat menangkap isi email sebelum mengirimnya?
Penangkapan pra-kirim tidak termasuk modifikasi SparkPost (pelacakan buka, pelacakan klik, pengkodean tautan). Menggunakan salinan Arsip memastikan versi yang disimpan Anda tepat mencocokkan apa yang diterima oleh penerima.
Apakah SparkPost mengarsipkan email secara otomatis?
Tidak. SparkPost tidak menyimpan badan 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
Logs peristiwa pesan → MySQL
Pemisahan ini mendukung pencarian cepat, kueri terstruktur, dan penyimpanan objek yang terjangkau.
Berapa lama SparkPost menyimpan data acara?
SparkPost menyimpan peristiwa pesan selama 10 hari. Setelah itu, data harus diambil melalui webhook atau dikueri dan disimpan di tempat lain.
Event pesan apa yang tersedia?
SparkPost saat ini menampilkan 14 peristiwa, termasuk pengiriman, pantulan, klik, pembukaan, penolakan, masalah kebijakan, keluhan spam, berhenti berlangganan, dan lainnya.
Apa saja pengidentifikasi yang menghubungkan semua acara?
Semua pesan keluar (original, arsip, CC, BCC) berbagi transmission_id yang sama. Email original dan arsip juga berbagi message_id yang sama.
Mengapa pemrosesan masuk menjadi tantangan?
Inbound Email Relay SparkPost mengubah email masuk menjadi JSON, tetapi JSON ini tidak menyertakan transmission_id. Tanpa data tambahan, salinan yang masuk tidak dapat dihubungkan ke riwayat log keluar.
Bagaimana Anda menghubungkan email arsip masuk dengan peristiwa pesan keluar?
Sematkan pengenal unik (UID) yang tersembunyi di dalam badan email dan sampaikan UID yang sama dalam metadata. UID ini menjadi referensi bersama di seluruh catatan masuk dan keluar.
Bagaimana Inbound Email Relay membantu mengotomatiskan pengarsipan?
Ini menerima email arsip yang dikirim ke domain arsip Anda, menguraikannya menjadi JSON terstruktur, dan mempostingnya 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 peristiwa di MySQL
Membolehkan pengguna mencari email
Menampilkan email asli dan setiap peristiwa terkait dalam satu antarmuka yang terpadu
Tepat setahun yang lalu saya menulis sebuah blog tentang bagaimana cara mengambil salinan email untuk pengarsipan dan tampilan 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, dibuka, diklik, bouncing, berhenti berlangganan, dll) pada email untuk tujuan auditing, tetapi memilih untuk tidak membuat kode pendukung.
Dengan meningkatnya penggunaan email di lingkungan regulasi, saya telah memutuskan bahwa sudah waktunya untuk memulai proyek baru yang menggabungkan semua ini dengan contoh kode tentang cara menyimpan isi email dan semua data terkaitnya. Selama tahun depan, saya akan terus membangun 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 isi email tetapi sangat mudah untuk membangun platform arsip.
Dalam seri blog ini, saya akan menjelaskan proses yang saya lalui untuk menyimpan isi email ke S3 (Layanan Penyimpanan Sederhana Amazon) dan semua data log relevan dalam MySQL untuk memudahkan referensi silang. Untuk sistem pengarsipan produksi yang memerlukan strategi cadangan basis data yang kuat, pertimbangkan untuk 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 akan memungkinkan pencarian mudah email yang diarsipkan, kemudian menampilkan email tersebut bersamaan dengan data acara (log). Kode untuk proyek ini dapat ditemukan di repositori GitHub berikut: PHPArchivePlatform di GitHub
Entri pertama dari seri blog ini akan menjelaskan tantangan dan menyusun arsitektur untuk solusi. Blog lainnya akan merinci bagian dari solusi bersama dengan contoh kode.
Langkah pertama dalam proses saya adalah mencari tahu bagaimana saya akan mendapatkan salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan isi email, Anda perlu:
Opsi Penangkapan Isi Email
Metode | Siapa yang membuat salinan | Memantulkan perubahan pelacakan | Ramah otomatisasi | Digunakan dalam solusi ini |
|---|---|---|---|---|
Tangkap sebelum mengirim | Aplikasi | ❌ Tidak | ✅ Ya | ❌ |
Server email menyimpan salinan | Server email | ✅ Ya | ❌ Terbatas | ❌ |
Fungsi Arsip SparkPost | SparkPost | ✅ Ya | ✅ Ya | ✅ |
Menangkap isi email sebelum mengirim email
Mendapatkan server email untuk menyimpan salinan
Memberi server email untuk membuat salinan bagi Anda untuk simpan
Jika server email menambahkan item seperti pelacakan tautan atau pelacakan buka, Anda tidak dapat menggunakan #1 karena tidak akan mencerminkan perubahan pelacakan buka/klik.
Itu berarti bahwa server harus menyimpan email atau entah bagaimana menawarkan salinan email itu 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 salinan email kepada kami untuk disimpan di S3.
Ini dilakukan dengan menggunakan fungsi Arsip SparkPost. Fungsi Arsip SparkPost memberikan kemampuan kepada pengirim untuk memberi tahu SparkPost untuk mengirimkan salinan duplikat email kepada satu atau lebih alamat email dan menggunakan tautan pelacakan dan buka yang sama seperti yang asli. Dokumentasi SparkPost mendefinisikan fitur Arsip mereka sebagai berikut:
Penerima dalam daftar arsip akan menerima replika persis dari pesan yang dikirim ke alamat RCPT TO. Khususnya, setiap tautan yang dikodekan yang ditujukan 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 pengarsipan berbeda, tetapi isi email akan menjadi replika persis!
Jika Anda menginginkan penjelasan yang lebih mendalam, berikut adalah tautan ke dokumentasi SparkPost tentang cara membuat salinan duplikat (atau arsip) dari 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 melalui SMTP!
Sekarang bahwa kita tahu bagaimana cara mendapatkan salinan email asli, kita perlu melihat data log yang dihasilkan dan beberapa nuansa halus dalam data tersebut. SparkPost melacak segala sesuatu yang terjadi di servernya dan menawarkan informasi itu kepada Anda dalam bentuk peristiwa pesan. Peristiwa itu disimpan di SparkPost selama 10 hari dan dapat ditarik dari server melalui API RESTful yang disebut peristiwa pesan, atau Anda dapat meminta SparkPost untuk mengirimkan peristiwa tersebut ke aplikasi pengumpul yang Anda inginkan. Mekanisme dorong 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
Pengiriman
Kesalahan Generasi
Penolakan Generasi
Pembukaan Awal
Unsubscribe Tautan Penyuntikan
Unsubscribe Daftar
Buka
Out of Band
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 berbagai bidang yang sesuai dengan tipe peristiwa. Beberapa bidang seperti transmission_id ditemukan di setiap peristiwa, tetapi bidang lain mungkin lebih spesifik terhadap peristiwa; misalnya, hanya peristiwa buka dan klik yang memiliki informasi geotag.
Identifikasi yang Digunakan dalam Sistem Pengarsipan
Identifikasi | Dari mana asalnya | Terbagi di antara | Tujuan | Limitasi |
|---|---|---|---|---|
transmission_id | SparkPost outbound | Asli, arsip, cc, bcc | Mengorelasikan semua peristiwa pesan | Tidak tersedia dalam relay masuk |
message_id | SparkPost outbound | Asli + arsip | Mengidentifikasi pesan individual | Berbeda untuk cc/bcc |
UID Tersembunyi | Dikenal oleh pengirim | Keluar + masuk | Menghubungkan isi email yang diarsipkan dengan peristiwa | Harus diimplementasikan secara kustom |
Satu entri peristiwa pesan yang sangat penting untuk proyek ini adalah transmission_id. Semua entri peristiwa pesan untuk email asli, email yang diarsipkan, 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 email asli dan email yang diarsipkan. Setiap alamat cc atau bcc akan memiliki idnya sendiri untuk entri message_id tersebut.
Sampai di sini mungkin terdengar hebat dan sebenarnya cukup mudah, tetapi sekarang adalah bagian yang menantang. Ingat, untuk mendapatkan email arsip, kami meminta SparkPost untuk mengirimkan salinan duplikat dari email asli ke alamat email lain yang sesuai dengan kotak masuk yang Anda akses. Tetapi untuk mengotomatiskan solusi ini dan menyimpan isi email, saya akan menggunakan fitur SparkPost lainnya yang disebut Pengalihan Email Masuk. Apa yang dilakukan fitur ini adalah mengambil semua email yang dikirim ke domain tertentu dan memprosesnya. Dengan memprosesnya, email tersebut dipecah dan membuat struktur JSON yang kemudian dikirimkan ke aplikasi melalui webhook. Lihat Lampiran A untuk contoh JSON.
Jika Anda lihat dengan teliti, Anda akan menyadari bahwa struktur JSON dari pengalihan masuk kekurangan 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 alamat bcc; SparkPost tidak memiliki cara untuk mengetahui bahwa email yang tertangkap oleh proses inbound terhubung dengan email keluar mana pun. Proses inbound hanya tahu bahwa email terkirim ke domain tertentu dan parse email tersebut. Itu saja. Itu 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 cara menjodohkan data keluar dengan proses inbound yang baru saja menangkap versi terarsip dari email? Apa yang saya putuskan adalah menyembunyikan id unik dalam isi email. Bagaimana cara ini dilakukan terserah Anda, tetapi saya hanya membuat bidang input dengan tag tersembunyi yang dihidupkan.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Saya juga menambahkan bidang itu ke dalam blok metadata yang terdapat pada header X-MSYS-API yang diteruskan ke SparkPost selama penyuntikan. UID yang tersembunyi ini akan menjadi perekat untuk seluruh proses, dan merupakan komponen utama dari proyek ini dan akan dibahas lebih dalam dalam posting blog berikutnya.
Sekarang bahwa kita memiliki UID yang akan menggabungkan 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 bersama dengan 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:
Penggalan kode pertama akan mencakup proses arsip dan menyimpan email ke S3, sementara penggalan kode kedua akan mencakup penyimpanan semua data log dari peristiwa pesan ke dalam MySQL. Anda dapat mengharapkan dua penggalan kode pertama dan entri blog pada awal tahun 2019. Jika Anda memiliki pertanyaan atau saran, silakan berikan kepada kami.
Selamat Mengirim.
– Jeff
Lampiran A:
Tepat setahun yang lalu saya menulis sebuah blog tentang bagaimana cara mengambil salinan email untuk pengarsipan dan tampilan 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, dibuka, diklik, bouncing, berhenti berlangganan, dll) pada email untuk tujuan auditing, tetapi memilih untuk tidak membuat kode pendukung.
Dengan meningkatnya penggunaan email di lingkungan regulasi, saya telah memutuskan bahwa sudah waktunya untuk memulai proyek baru yang menggabungkan semua ini dengan contoh kode tentang cara menyimpan isi email dan semua data terkaitnya. Selama tahun depan, saya akan terus membangun 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 isi email tetapi sangat mudah untuk membangun platform arsip.
Dalam seri blog ini, saya akan menjelaskan proses yang saya lalui untuk menyimpan isi email ke S3 (Layanan Penyimpanan Sederhana Amazon) dan semua data log relevan dalam MySQL untuk memudahkan referensi silang. Untuk sistem pengarsipan produksi yang memerlukan strategi cadangan basis data yang kuat, pertimbangkan untuk 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 akan memungkinkan pencarian mudah email yang diarsipkan, kemudian menampilkan email tersebut bersamaan dengan data acara (log). Kode untuk proyek ini dapat ditemukan di repositori GitHub berikut: PHPArchivePlatform di GitHub
Entri pertama dari seri blog ini akan menjelaskan tantangan dan menyusun arsitektur untuk solusi. Blog lainnya akan merinci bagian dari solusi bersama dengan contoh kode.
Langkah pertama dalam proses saya adalah mencari tahu bagaimana saya akan mendapatkan salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan isi email, Anda perlu:
Opsi Penangkapan Isi Email
Metode | Siapa yang membuat salinan | Memantulkan perubahan pelacakan | Ramah otomatisasi | Digunakan dalam solusi ini |
|---|---|---|---|---|
Tangkap sebelum mengirim | Aplikasi | ❌ Tidak | ✅ Ya | ❌ |
Server email menyimpan salinan | Server email | ✅ Ya | ❌ Terbatas | ❌ |
Fungsi Arsip SparkPost | SparkPost | ✅ Ya | ✅ Ya | ✅ |
Menangkap isi email sebelum mengirim email
Mendapatkan server email untuk menyimpan salinan
Memberi server email untuk membuat salinan bagi Anda untuk simpan
Jika server email menambahkan item seperti pelacakan tautan atau pelacakan buka, Anda tidak dapat menggunakan #1 karena tidak akan mencerminkan perubahan pelacakan buka/klik.
Itu berarti bahwa server harus menyimpan email atau entah bagaimana menawarkan salinan email itu 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 salinan email kepada kami untuk disimpan di S3.
Ini dilakukan dengan menggunakan fungsi Arsip SparkPost. Fungsi Arsip SparkPost memberikan kemampuan kepada pengirim untuk memberi tahu SparkPost untuk mengirimkan salinan duplikat email kepada satu atau lebih alamat email dan menggunakan tautan pelacakan dan buka yang sama seperti yang asli. Dokumentasi SparkPost mendefinisikan fitur Arsip mereka sebagai berikut:
Penerima dalam daftar arsip akan menerima replika persis dari pesan yang dikirim ke alamat RCPT TO. Khususnya, setiap tautan yang dikodekan yang ditujukan 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 pengarsipan berbeda, tetapi isi email akan menjadi replika persis!
Jika Anda menginginkan penjelasan yang lebih mendalam, berikut adalah tautan ke dokumentasi SparkPost tentang cara membuat salinan duplikat (atau arsip) dari 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 melalui SMTP!
Sekarang bahwa kita tahu bagaimana cara mendapatkan salinan email asli, kita perlu melihat data log yang dihasilkan dan beberapa nuansa halus dalam data tersebut. SparkPost melacak segala sesuatu yang terjadi di servernya dan menawarkan informasi itu kepada Anda dalam bentuk peristiwa pesan. Peristiwa itu disimpan di SparkPost selama 10 hari dan dapat ditarik dari server melalui API RESTful yang disebut peristiwa pesan, atau Anda dapat meminta SparkPost untuk mengirimkan peristiwa tersebut ke aplikasi pengumpul yang Anda inginkan. Mekanisme dorong 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
Pengiriman
Kesalahan Generasi
Penolakan Generasi
Pembukaan Awal
Unsubscribe Tautan Penyuntikan
Unsubscribe Daftar
Buka
Out of Band
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 berbagai bidang yang sesuai dengan tipe peristiwa. Beberapa bidang seperti transmission_id ditemukan di setiap peristiwa, tetapi bidang lain mungkin lebih spesifik terhadap peristiwa; misalnya, hanya peristiwa buka dan klik yang memiliki informasi geotag.
Identifikasi yang Digunakan dalam Sistem Pengarsipan
Identifikasi | Dari mana asalnya | Terbagi di antara | Tujuan | Limitasi |
|---|---|---|---|---|
transmission_id | SparkPost outbound | Asli, arsip, cc, bcc | Mengorelasikan semua peristiwa pesan | Tidak tersedia dalam relay masuk |
message_id | SparkPost outbound | Asli + arsip | Mengidentifikasi pesan individual | Berbeda untuk cc/bcc |
UID Tersembunyi | Dikenal oleh pengirim | Keluar + masuk | Menghubungkan isi email yang diarsipkan dengan peristiwa | Harus diimplementasikan secara kustom |
Satu entri peristiwa pesan yang sangat penting untuk proyek ini adalah transmission_id. Semua entri peristiwa pesan untuk email asli, email yang diarsipkan, 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 email asli dan email yang diarsipkan. Setiap alamat cc atau bcc akan memiliki idnya sendiri untuk entri message_id tersebut.
Sampai di sini mungkin terdengar hebat dan sebenarnya cukup mudah, tetapi sekarang adalah bagian yang menantang. Ingat, untuk mendapatkan email arsip, kami meminta SparkPost untuk mengirimkan salinan duplikat dari email asli ke alamat email lain yang sesuai dengan kotak masuk yang Anda akses. Tetapi untuk mengotomatiskan solusi ini dan menyimpan isi email, saya akan menggunakan fitur SparkPost lainnya yang disebut Pengalihan Email Masuk. Apa yang dilakukan fitur ini adalah mengambil semua email yang dikirim ke domain tertentu dan memprosesnya. Dengan memprosesnya, email tersebut dipecah dan membuat struktur JSON yang kemudian dikirimkan ke aplikasi melalui webhook. Lihat Lampiran A untuk contoh JSON.
Jika Anda lihat dengan teliti, Anda akan menyadari bahwa struktur JSON dari pengalihan masuk kekurangan 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 alamat bcc; SparkPost tidak memiliki cara untuk mengetahui bahwa email yang tertangkap oleh proses inbound terhubung dengan email keluar mana pun. Proses inbound hanya tahu bahwa email terkirim ke domain tertentu dan parse email tersebut. Itu saja. Itu 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 cara menjodohkan data keluar dengan proses inbound yang baru saja menangkap versi terarsip dari email? Apa yang saya putuskan adalah menyembunyikan id unik dalam isi email. Bagaimana cara ini dilakukan terserah Anda, tetapi saya hanya membuat bidang input dengan tag tersembunyi yang dihidupkan.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Saya juga menambahkan bidang itu ke dalam blok metadata yang terdapat pada header X-MSYS-API yang diteruskan ke SparkPost selama penyuntikan. UID yang tersembunyi ini akan menjadi perekat untuk seluruh proses, dan merupakan komponen utama dari proyek ini dan akan dibahas lebih dalam dalam posting blog berikutnya.
Sekarang bahwa kita memiliki UID yang akan menggabungkan 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 bersama dengan 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:
Penggalan kode pertama akan mencakup proses arsip dan menyimpan email ke S3, sementara penggalan kode kedua akan mencakup penyimpanan semua data log dari peristiwa pesan ke dalam MySQL. Anda dapat mengharapkan dua penggalan kode pertama dan entri blog pada awal tahun 2019. Jika Anda memiliki pertanyaan atau saran, silakan berikan kepada kami.
Selamat Mengirim.
– Jeff
Lampiran A:
Tepat setahun yang lalu saya menulis sebuah blog tentang bagaimana cara mengambil salinan email untuk pengarsipan dan tampilan 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, dibuka, diklik, bouncing, berhenti berlangganan, dll) pada email untuk tujuan auditing, tetapi memilih untuk tidak membuat kode pendukung.
Dengan meningkatnya penggunaan email di lingkungan regulasi, saya telah memutuskan bahwa sudah waktunya untuk memulai proyek baru yang menggabungkan semua ini dengan contoh kode tentang cara menyimpan isi email dan semua data terkaitnya. Selama tahun depan, saya akan terus membangun 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 isi email tetapi sangat mudah untuk membangun platform arsip.
Dalam seri blog ini, saya akan menjelaskan proses yang saya lalui untuk menyimpan isi email ke S3 (Layanan Penyimpanan Sederhana Amazon) dan semua data log relevan dalam MySQL untuk memudahkan referensi silang. Untuk sistem pengarsipan produksi yang memerlukan strategi cadangan basis data yang kuat, pertimbangkan untuk 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 akan memungkinkan pencarian mudah email yang diarsipkan, kemudian menampilkan email tersebut bersamaan dengan data acara (log). Kode untuk proyek ini dapat ditemukan di repositori GitHub berikut: PHPArchivePlatform di GitHub
Entri pertama dari seri blog ini akan menjelaskan tantangan dan menyusun arsitektur untuk solusi. Blog lainnya akan merinci bagian dari solusi bersama dengan contoh kode.
Langkah pertama dalam proses saya adalah mencari tahu bagaimana saya akan mendapatkan salinan email yang dikirim ke penerima asli. Untuk mendapatkan salinan isi email, Anda perlu:
Opsi Penangkapan Isi Email
Metode | Siapa yang membuat salinan | Memantulkan perubahan pelacakan | Ramah otomatisasi | Digunakan dalam solusi ini |
|---|---|---|---|---|
Tangkap sebelum mengirim | Aplikasi | ❌ Tidak | ✅ Ya | ❌ |
Server email menyimpan salinan | Server email | ✅ Ya | ❌ Terbatas | ❌ |
Fungsi Arsip SparkPost | SparkPost | ✅ Ya | ✅ Ya | ✅ |
Menangkap isi email sebelum mengirim email
Mendapatkan server email untuk menyimpan salinan
Memberi server email untuk membuat salinan bagi Anda untuk simpan
Jika server email menambahkan item seperti pelacakan tautan atau pelacakan buka, Anda tidak dapat menggunakan #1 karena tidak akan mencerminkan perubahan pelacakan buka/klik.
Itu berarti bahwa server harus menyimpan email atau entah bagaimana menawarkan salinan email itu 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 salinan email kepada kami untuk disimpan di S3.
Ini dilakukan dengan menggunakan fungsi Arsip SparkPost. Fungsi Arsip SparkPost memberikan kemampuan kepada pengirim untuk memberi tahu SparkPost untuk mengirimkan salinan duplikat email kepada satu atau lebih alamat email dan menggunakan tautan pelacakan dan buka yang sama seperti yang asli. Dokumentasi SparkPost mendefinisikan fitur Arsip mereka sebagai berikut:
Penerima dalam daftar arsip akan menerima replika persis dari pesan yang dikirim ke alamat RCPT TO. Khususnya, setiap tautan yang dikodekan yang ditujukan 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 pengarsipan berbeda, tetapi isi email akan menjadi replika persis!
Jika Anda menginginkan penjelasan yang lebih mendalam, berikut adalah tautan ke dokumentasi SparkPost tentang cara membuat salinan duplikat (atau arsip) dari 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 melalui SMTP!
Sekarang bahwa kita tahu bagaimana cara mendapatkan salinan email asli, kita perlu melihat data log yang dihasilkan dan beberapa nuansa halus dalam data tersebut. SparkPost melacak segala sesuatu yang terjadi di servernya dan menawarkan informasi itu kepada Anda dalam bentuk peristiwa pesan. Peristiwa itu disimpan di SparkPost selama 10 hari dan dapat ditarik dari server melalui API RESTful yang disebut peristiwa pesan, atau Anda dapat meminta SparkPost untuk mengirimkan peristiwa tersebut ke aplikasi pengumpul yang Anda inginkan. Mekanisme dorong 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
Pengiriman
Kesalahan Generasi
Penolakan Generasi
Pembukaan Awal
Unsubscribe Tautan Penyuntikan
Unsubscribe Daftar
Buka
Out of Band
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 berbagai bidang yang sesuai dengan tipe peristiwa. Beberapa bidang seperti transmission_id ditemukan di setiap peristiwa, tetapi bidang lain mungkin lebih spesifik terhadap peristiwa; misalnya, hanya peristiwa buka dan klik yang memiliki informasi geotag.
Identifikasi yang Digunakan dalam Sistem Pengarsipan
Identifikasi | Dari mana asalnya | Terbagi di antara | Tujuan | Limitasi |
|---|---|---|---|---|
transmission_id | SparkPost outbound | Asli, arsip, cc, bcc | Mengorelasikan semua peristiwa pesan | Tidak tersedia dalam relay masuk |
message_id | SparkPost outbound | Asli + arsip | Mengidentifikasi pesan individual | Berbeda untuk cc/bcc |
UID Tersembunyi | Dikenal oleh pengirim | Keluar + masuk | Menghubungkan isi email yang diarsipkan dengan peristiwa | Harus diimplementasikan secara kustom |
Satu entri peristiwa pesan yang sangat penting untuk proyek ini adalah transmission_id. Semua entri peristiwa pesan untuk email asli, email yang diarsipkan, 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 email asli dan email yang diarsipkan. Setiap alamat cc atau bcc akan memiliki idnya sendiri untuk entri message_id tersebut.
Sampai di sini mungkin terdengar hebat dan sebenarnya cukup mudah, tetapi sekarang adalah bagian yang menantang. Ingat, untuk mendapatkan email arsip, kami meminta SparkPost untuk mengirimkan salinan duplikat dari email asli ke alamat email lain yang sesuai dengan kotak masuk yang Anda akses. Tetapi untuk mengotomatiskan solusi ini dan menyimpan isi email, saya akan menggunakan fitur SparkPost lainnya yang disebut Pengalihan Email Masuk. Apa yang dilakukan fitur ini adalah mengambil semua email yang dikirim ke domain tertentu dan memprosesnya. Dengan memprosesnya, email tersebut dipecah dan membuat struktur JSON yang kemudian dikirimkan ke aplikasi melalui webhook. Lihat Lampiran A untuk contoh JSON.
Jika Anda lihat dengan teliti, Anda akan menyadari bahwa struktur JSON dari pengalihan masuk kekurangan 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 alamat bcc; SparkPost tidak memiliki cara untuk mengetahui bahwa email yang tertangkap oleh proses inbound terhubung dengan email keluar mana pun. Proses inbound hanya tahu bahwa email terkirim ke domain tertentu dan parse email tersebut. Itu saja. Itu 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 cara menjodohkan data keluar dengan proses inbound yang baru saja menangkap versi terarsip dari email? Apa yang saya putuskan adalah menyembunyikan id unik dalam isi email. Bagaimana cara ini dilakukan terserah Anda, tetapi saya hanya membuat bidang input dengan tag tersembunyi yang dihidupkan.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Saya juga menambahkan bidang itu ke dalam blok metadata yang terdapat pada header X-MSYS-API yang diteruskan ke SparkPost selama penyuntikan. UID yang tersembunyi ini akan menjadi perekat untuk seluruh proses, dan merupakan komponen utama dari proyek ini dan akan dibahas lebih dalam dalam posting blog berikutnya.
Sekarang bahwa kita memiliki UID yang akan menggabungkan 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 bersama dengan 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:
Penggalan kode pertama akan mencakup proses arsip dan menyimpan email ke S3, sementara penggalan kode kedua akan mencakup penyimpanan semua data log dari peristiwa pesan ke dalam MySQL. Anda dapat mengharapkan dua penggalan kode pertama dan entri blog pada awal tahun 2019. Jika Anda memiliki pertanyaan atau saran, silakan berikan kepada kami.
Selamat Mengirim.
– Jeff
Lampiran A:
