Berhenti berlangganan sekali klik menghubungkan dua sistem: pesan yang mengiklankan tindakan dan layanan yang memprosesnya. Header yang tampak benar hanyalah setengah dari implementasi. Titik akhir harus mengidentifikasi langganan yang dimaksud, menerima permintaan yang ditentukan tanpa login, dan membuat pilihan untuk tidak ikut serta menjadi efektif.
Bangun pesan sebelum menandatanganinya
RFC 8058 memanggil satu bidang List-Unsubscribe yang berisi URI HTTPS dan satu bidang List-Unsubscribe-Post yang berisi List-Unsubscribe =Satu-Klik. Sah tanda tangan DKIM harus mencakup kedua bidang tersebut. URI berhenti berlangganan non-HTTP/S lainnya, seperti mailto, juga dapat muncul di List-Unsubscribe . RFC 8058 bagian 3 dan 4.
Pasangan header ilustrasi minimal adalah:
List-Unsubscribe: <https://unsubscribe.example.test/u/opaque-token>
List-Unsubscribe-Post : List-Unsubscribe =Satu-Klik
Nama host dan token yang dicadangkan mengajarkan placeholder, bukan titik akhir operasional. Tambahkan bidang ini sebelum langkah penandatanganan terakhir yang relevan. Periksa pesan yang dipancarkan untuk memastikan daftar h= tanda tangan menyertakan pesan tersebut dan verifikasi kriptografi berhasil setelah semua transformasi.
Buat URI mengidentifikasi tindakan yang tepat
URI harus membawa informasi yang cukup untuk mengidentifikasi penerima dan daftar. Penerima tidak dapat memberikan kolom penerima tambahan atau menjawab kuesioner preferensi. Gunakan komponen yang buram dan sulit dipalsukan dan validasi di titik akhir. Hindari mengekspos alamat secara tidak perlu di URL, log, atau analitik.
Perlakukan token sebagai otoritas untuk melakukan berhenti berlangganan dengan cakupan yang sempit, bukan sebagai kredensial akun umum. Seseorang yang memiliki akses ke pesan tersebut mungkin dapat menggunakannya. Jangan biarkan hal ini mengubah kepemilikan akun, masuk sebagai pengguna, atau mengubah langganan yang tidak terkait. Pilih perilaku retensi dan kedaluwarsa dengan sengaja sehingga pesan lama tidak menjadi jalur penyisihan yang tidak berguna tanpa kebijakan yang dipertimbangkan.
Memproses POST yang ditentukan secara langsung
Penerima mengirimkan HTTPS POST dengan pasangan kunci/nilai yang diiklankan di tubuhnya. RFC 8058 mengizinkan application/x-www-form-urlencoded dan merekomendasikan multipart/form-data. Permintaan tidak boleh bergantung pada cookie, otorisasi HTTP, atau konteks browser sebelumnya. Pengirim tidak boleh mengembalikan pengalihan HTTPS. Penerima harus mendapatkan persetujuan pengguna sebelum melakukan tindakan.
Tautan isi masih dapat menawarkan halaman preferensi yang dapat dibaca manusia, namun tindakan POST harus selesai tanpa interaksi lebih lanjut. Sebagai pengamanan implementasi, jaga agar permintaan GET tidak merusak sehingga pengambilan tautan otomatis tidak menghapus pelanggan dengan sendirinya. Perlindungan tersebut merupakan rekomendasi desain operasional yang dimotivasi oleh permasalahan yang ditangani RFC.
Verifikasi status aplikasi, bukan hanya kode status
Misalkan titik akhir hipotetis mengembalikan kesuksesan untuk token buletin yang valid, namun ekspor kampanye berikutnya masih menyertakan pasangan penerima/daftar yang sama. Permintaan protokol mungkin telah mencapai layanan, namun penekanan operasional tidak dilakukan. Periksa keputusan yang tahan lama, pengakuan propagasi, dan masukan pemilihan audiens daripada memperlakukan kode status sebagai penyelesaian.
Untuk pengujian resmi, tentukan hasil yang diharapkan terlebih dahulu: GET dan token yang tidak valid tidak boleh menghapus langganan; POST yang valid seharusnya hanya memengaruhi pasangan yang dituju; mengulanginya akan mempertahankan keadaan akhir yang sama. Ini adalah ekspektasi desain, bukan pengujian lokal atau produksi yang dilakukan.
Untuk penerapan, verifikasi secara terpisah validitas sertifikat TLS , nama host, keterjangkauan publik, pengkodean formulir yang didukung, perilaku proksi, dan batas kecepatan. Periksa apakah responsnya tidak mengalihkan ke layanan login atau pelacakan. Pastikan pilihan kampanye berikutnya mematuhi penindasan, termasuk cache atau ekspor pihak ketiga.
Operasikan titik akhir sebagai layanan yang tahan lama
Amankan permintaan valid berulang, catat peristiwa audit minimal, dan pantau kegagalan tanpa mengekspos token. Peringatan tentang kesalahan pemrosesan dan penekanan simpanan. Respons yang mengklaim berhasil sebelum pembaruan yang tahan lama memerlukan desain pemrosesan yang andal dan waktu penyelesaian yang terbatas.
Tutup penerapannya dengan verifikasi pesan, pengujian titik akhir, dan pengecualian pengiriman berikutnya yang diamati untuk penerima yang dikontrol. Tidak satu pun dari hal ini yang membuktikan bahwa setiap antarmuka kotak surat akan menampilkan tombol berhenti berlangganan.
Pilih perbaikan dari pos pemeriksaan yang gagal
Persyaratan pengalihan atau login memerlukan perbaikan titik akhir. Pemetaan penerima/daftar yang salah memerlukan perbaikan cakupan otorisasi. Titik akhir yang benar dengan ekspor kampanye yang basi memerlukan perbaikan propagasi. Jangan tutup ketiganya karena salah satu POST kembali sukses.