Sekitar setahun yang lalu saya menulis sebuah blog tentang bagaimana mendapatkan salinan email untuk pengarsipan dan peninjauan, tetapi saya tidak membahas penyimpanan email atau data terkait, dan baru-baru ini saya menulis sebuah blog tentang penyimpanan semua data acara (yaitu ketika email dikirim, dibuka, diklik, bounced, berhenti berlangganan, dll.) pada sebuah email untuk keperluan audit, tetapi memilih untuk tidak membuat kode pendukung.

Dengan meningkatnya penggunaan email di lingkungan regulasi, saya memutuskan sudah waktunya untuk memulai proyek baru yang mengumpulkan semua ini dengan contoh kode tentang bagaimana menyimpan badan email dan semua data terkaitnya. Selama setahun ke depan, saya akan terus membangun proyek ini dengan tujuan menciptakan aplikasi penyimpanan dan peninjauan untuk email yang diarsipkan dan semua informasi log yang dihasilkan oleh SparkPost. SparkPost tidak memiliki sistem yang mengarsipkan badan email tetapi memudahkan membangun platform pengarsipan.

Dalam rangkaian blog ini, saya akan menggambarkan proses yang saya lalui untuk menyimpan badan email ke S3 (Amazon's Simple Store Service) dan semua data log yang relevan di MySQL untuk referensi silang yang mudah. Ini adalah titik awal untuk membangun aplikasi yang memungkinkan pencarian yang mudah dari 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 rangkaian blog ini akan menggambarkan tantangan dan menyusun arsitektur untuk solusinya. Blog lainnya akan merinci bagian-bagian dari solusi bersama dengan contoh kode.

Langkah pertama dalam proses saya adalah mencari tahu bagaimana cara memperoleh salinan email yang dikirim ke penerima asli. Untuk memperoleh salinan badan email, Anda harus:

1. Menangkap badan email sebelum mengirim email

2. Mendapatkan server email untuk menyimpan salinan

3. Meminta server email membuat salinan untuk Anda 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 server harus menyimpan email atau menawarkan salinannya kepada Anda untuk disimpan. Karena SparkPost tidak memiliki mekanisme penyimpanan untuk badan email tetapi memiliki cara untuk membuat salinan email, kami akan memintanya mengirimkan duplikat email untuk disimpan di S3.

Ini dilakukan dengan menggunakan fitur Arsip dari SparkPost. Fitur Arsip dari SparkPost memberikan pengirim kesempatan untuk meminta SparkPost mengirimkan duplikat email ke satu atau lebih alamat email dan menggunakan tautan pelacakan dan buka yang sama dengan email 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. Secara khusus, tautan yang dienkripsi 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 badan email akan menjadi replika yang tepat!

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

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

* Perhatikan * Email yang diarsipkan HANYA dapat dibuat ketika menyuntikkan email ke SparkPost melalui SMTP!

Setelah kita tahu cara memperoleh salinan dari email asli, kita perlu melihat data log yang dihasilkan dan beberapa nuansa halus dalam data tersebut. SparkPost melacak segala sesuatu yang terjadi pada server mereka dan menawarkan informasi tersebut 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 pengiriman ini dilakukan melalui webhooks 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 dari 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 di setiap peristiwa, tetapi bidang lainnya mungkin lebih spesifik untuk peristiwa tertentu; misalnya, hanya peristiwa open dan klik yang memiliki informasi geotag.

Salah 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 memiliki transmission_id yang sama.

Juga ada 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 mereka sendiri untuk entri message_id.

Sejauh ini terlihat bagus dan cukup mudah, tetapi inilah bagian yang menantang. Ingat, untuk mendapatkan email yang diarsipkan, kita meminta SparkPost mengirimkan duplikat email asli ke alamat email lain yang sesuai dengan suatu inbox yang Anda akses. Namun untuk mengotomatisasi solusi ini dan menyimpan badan email, saya akan menggunakan fitur lain dari SparkPost yang disebut Inbound Email Relaying. Dengan fitur ini, semua email yang dikirim ke domain tertentu diambil dan diproses. Dalam prosesnya, email tersebut dibongkar dan dibuatkan struktur JSON yang kemudian dikirim ke aplikasi melalui webhook. Lihat Lampiran A untuk contoh JSON.

Jika Anda melihat dengan sangat teliti, Anda akan menyadari bahwa struktur JSON dari inbound relay kehilangan field penting; yaitu transmission_id. Sementara semua email yang dikirim memiliki transmission_id 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 email apapun dari outbounds. Proses inbound hanya tahu bahwa sebuah email dikirim ke domain tertentu dan akan memprosesnya. Itu saja. Email dari pelanggan atau email arsip dari SparkPost akan diperlakukan dengan cara yang sama jika dikirim ke domain tersebut.

Jadi triknya adalah; bagaimana Anda menghubungkan data outbound dengan proses inbound yang baru saja menangkap versi arsip dari email tersebut? Yang saya lakukan adalah menyembunyikan id unik di badan email. Bagaimana cara melakukannya terserah Anda, tetapi saya hanya membuat field input dengan tag tersembunyi diaktifkan.

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

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

Setelah kita memiliki UID yang akan menghubungkan proyek ini dan memahami mengapa itu perlu, saya bisa mulai membangun visi dari proyek keseluruhan dan posting blog terkait.

1. Menangkap dan menyimpan email arsip bersama dengan entri database untuk pencarian/indeksasi

2. Menangkap semua data peristiwa pesan

3. Membuat aplikasi untuk melihat email dan semua data terkait

   
   

Berikut adalah diagram sederhana dari proyek ini:

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

Senang Mengirim.

– Jeff

Lampiran A: