Perlakukan daftar tersebut sebagai langkah pengiriman kedua
Pesan Simplelists memiliki setidaknya dua tahapan yang relevan: anggota mengirimkan postingan, lalu daftar mendistribusikannya kembali. Otentikasi yang berhasil pada penyerahan asli mungkin tidak menggambarkan salinan yang dikirimkan kepada anggota. Panduan ini membahas domain khusus pada akun Beberapa Daftar yang terdokumentasi dan perilaku pesan yang didistribusikan ulang. Hal ini tidak mengasumsikan bahwa setiap jenis akun, pengaturan daftar, atau pengirim asli menggunakan identitas yang sama.
Mulailah dengan memilih hasil bisnis. Daftar pengumuman mungkin secara konsisten mewakili organisasi. Daftar diskusi mungkin perlu menampilkan anggota yang berbeda dan mengarahkan balasan dengan tepat. Catat perilaku yang diharapkan orang sebelum mengubah penulisan ulang pengirim. Jika tidak, perubahan yang berhasil secara teknis dapat membuat percakapan membingungkan atau mengungkap rincian daftar anonim yang ingin disembunyikan.
Tetapkan domain dan batas perutean masuk
Panduan domain milik kaum Simplelist menjelaskan penambahan domain melalui Pengaturan Umum, lalu Domain, dalam akun Daftar Banyak, mengaturnya sebagai domain utama dan memeriksa alamat daftar yang dihasilkan. Ini adalah artikel pengaturan penyedia tahun 2017, jadi konfirmasikan kontrol akun saat ini sebelum menggunakan navigasinya. Ini juga mengarahkan administrator ke akun tersebut SPF Dan DKIM informasi. Ambil nilai dari akun dan domain yang benar, bukan menyalin contoh publik.
Panduan yang sama memberi nama mx1.simplelists.com dan mx2.simplelists.com untuk MX masuk primer dan sekunder, dan memperingatkan bahwa perubahan dapat memakan waktu hingga 72 jam. Konfirmasikan instruksi akun saat ini dan status cache aktual daripada menganggap waktu yang telah berlalu sebagai penerimaan. Perlakukan itu sebagai keputusan perutean masuk. Jika organisasi sudah menerima email karyawan di domain akarnya, gantikan domain tersebut data MX dapat mempengaruhi lebih dari sekedar daftar. Putuskan apakah subdomain daftar khusus sesuai, identifikasi pemilik email yang ada, dan catat cakupan perutean yang disetujui sebelum dipublikasikan.
Pertahankan perutean masuk dan autentikasi keluar pada baris lembar kerja terpisah. Pengiriman postingan yang berhasil ke dalam daftar tidak membuktikan bahwa salinan yang dikirim dari postingan tersebut akan diautentikasi. Sebaliknya, masalah DKIM tidak dengan sendirinya membenarkan pemindahan surat masuk perusahaan.
Dapatkan dan tinjau catatan yang dikeluarkan akun
Tangkap pemilik rekaman lengkap, jenis, nilai publik, dan domain yang dituju untuk setiap entri yang diterbitkan. Bandingkan pemilik yang diusulkan dengan data DNS yang ada yang harus dihindari pemilih tabrakan atau akhiran domain duplikat. Tinjau perubahan di zona otoritatif, tidak hanya di akun registrar jika penyedia lain menghosting DNS .
Untuk SPF , pertahankan pengirim sah lainnya di domain yang sama. RFC 7208 mendefinisikan seberapa banyak Catatan SPF dan persyaratan yang bergantung pada DNS diproses. Tinjau kebijakan lengkap dan biaya pencarian bertingkat sebelum memberi otorisasi layanan tambahan. Jangan membuat kebijakan SPF yang bersaing karena layar pengaturan menampilkan contoh yang berdiri sendiri.
Untuk DKIM , bandingkan pemilih yang dikeluarkan dan catatan publik dengan tanda tangan yang dihasilkan pada pesan daftar terkontrol. RFC 6376 mendefinisikan bidang d= dan s=. Kunci yang diterbitkan hanya berguna ketika pesan sebenarnya membawa tanda tangan valid yang sesuai. Simpan setiap tanda tangan yang diamati, termasuk tanda tangan asli anggota, dalam paket bukti.
Putuskan bagaimana menangani identitas anggota eksternal
Penjelasan DMARC kaum sederhana membedakan pengiriman dari domain akun dengan mendistribusikan ulang email yang berasal dari domain lain. Ini menjelaskan penulisan ulang bersyarat untuk domain luar. Dia panduan fitur juga mendokumentasikan opsi untuk menulis ulang secara konsisten dan mengontrol untuk menampilkan detail pengirim asli.
Pilihan-pilihan tersebut layak mendapatkan keputusan manusiawi. Sebuah komite dapat memprioritaskan alamat daftar yang stabil; kelompok diskusi mungkin memprioritaskan pengenalan kontributor. Rekam Dari tampilan dan tujuan balasan yang dipilih, lalu periksa keduanya dalam salinan yang dikirimkan. Jika anonimitas penting, tinjau juga isi dan kutipan threadnya. Menyembunyikan satu header tidak dapat menghapus blok tanda tangan anggota atau alamat yang dikutip sebelumnya.
Jangan berasumsi bahwa daftar tersebut dapat ditandatangani sebagai domain anggota eksternal yang tidak terkait. Identifikasi domain Dari akhir yang terlihat dan jalur autentikasi yang mendukungnya. Pertahankan perilaku percakapan yang diharapkan sambil menyelidiki ketidakcocokan apa pun, daripada mengubah beberapa pengaturan sekaligus.
Sertakan modifikasi konten dalam rencana pengujian
Footer, penyisipan header, atau awalan subjek dapat memengaruhi tanda tangan asli, bergantung pada apa yang ditandatangani. orang yang sederhana panduan pemecahan masalah pengiriman membahas perubahan ini saat menyelidiki dugaan penolakan spoofing. Ia juga mengatakan pengirim amplop biasanya merupakan alamat daftar dan menunjuk ke tampilan pengiriman email untuk rincian server penerima.
Buat matriks kecil: pengirim organisasi, pengirim luar dengan kebijakan ketat, dan pengaturan modifikasi daftar aktual. Tambahkan intisari atau mode pengiriman berbeda lainnya hanya jika organisasi menggunakannya dan akun mendukungnya. Setiap baris harus mewakili alur kerja nyata, bukan daftar periksa fitur teoretis.
Gunakan postingan yang tidak berbahaya dan penerima yang dikontrol. Simpan waktu pengiriman dan pengidentifikasi pesan sehingga log daftar dapat dicocokkan dengan salinan yang diterima. Uji penerima eksternal serta gateway organisasi ketika keduanya relevan. Penerimaan internal mungkin bergantung pada pengecualian lokal yang tidak dimiliki oleh anggota eksternal.
Catat identitas akhir dan hasil
Untuk setiap salinan yang dikirimkan, catat Dari, Balas Ke, domain amplop, semua pasangan d= dan s= DKIM , serta SPF , DKIM , dan SPF penerima tepercaya DMARC hasil. Simpan hasil postingan asli secara terpisah. Kedua tahap tersebut menjawab pertanyaan yang berbeda dan tidak boleh saling menimpa dalam catatan ujian.
RFC 9989 mendefinisikan DMARC penyelarasan. Identifikasi mekanisme passing dan hubungan domain yang mendukungnya. Pass domain penyedia yang tidak terkait dengan domain Dari final tidak akan membentuk hubungan tersebut. Alamat Dari yang ditulis ulang dapat mengubah perbandingan yang relevan, itulah sebabnya memeriksa salinan akhir sangat penting.
Jika server penerima menolak pesan, pertahankan teks diagnostik persisnya. Jika menerima pesan tetapi penerima tidak dapat menemukannya, lanjutkan penyelidikan pengiriman tanpa mengasumsikan kegagalan DNS . Hindari pemberian izin secara luas sebagai pengganti awal untuk mengidentifikasi hasil autentikasi.
Gunakan lembar kerja redistribusi daftar
Lembar kerja rute Simplelist dan perilaku pengirim (buat catatan tinjauan terpisah dengan bidang yang dijelaskan di sini) mencatat domain daftar masuk, kategori poster asli, keputusan penulisan ulang, perubahan konten, dan identitas akhir. Ini memberi pemilik bisnis tempat untuk menyetujui perilaku balasan dan administrator email tempat untuk melampirkan hasil teknis.
Sebelum penandatanganan, bandingkan semua baris pengujian. Satu pengumuman organisasi yang sukses tidak memvalidasi postingan diskusi anggota luar. Biarkan rute yang tidak tertutup secara eksplisit tertunda dan nyatakan pengujian tambahan apa yang diperlukan. Simpan konfigurasi domain dan daftar versi pengaturan beserta hasilnya sehingga perubahan selanjutnya dapat dilacak.
Kasus diagnostik fiksi yang melibatkan footer diskusi
Kasus tertulis fiktif saja: SLS-01 menetapkan From member@outside.example asli dengan tanda tangan asli d=outside.example. Dalam salinan yang didistribusikan ulang, tanda tangan asli gagal setelah perubahan footer; final Dari tetap member@outside.example . Sampul daftar, tanda tangan tambahan apa pun, dan hasilnya tidak diketahui, sehingga tidak ada keputusan lengkap DMARC yang menyusul. Pemilik daftar harus memeriksa salinan akhir dan pengaturan penulisan ulang yang terdokumentasi, menyetujui perilaku balasan yang diinginkan, dan menguji rute yang tepat. Menambahkan SPF di domain organisasi tidak memperbaiki tanda tangan asli yang tidak terkait. Tidak ada daftar atau pesan nyata yang diperiksa.
Pulihkan pengaturan tanpa mengganggu email anggota
Catat pengaturan daftar sebelumnya dan status DNS sebelum perubahan terkontrol. Jika balasan atau presentasi pengirim salah, jeda peluncuran yang terpengaruh dan pulihkan perilaku yang disetujui sementara pemilik meninjaunya. Koordinasikan penghentian catatan apa pun dengan daftar yang tersisa dan pesan antri. Domain bersama mungkin mendukung beberapa daftar dengan jadwal pengoperasian berbeda.
Tes ulang setelah perubahan domain, penulisan ulang perubahan, footer baru, perubahan perutean, atau migrasi. Draf yang belum dipublikasikan ini masih memerlukan pemeriksaan akun live, nilai yang diterbitkan, observasi DNS , bukti pesan yang diterima, penerimaan cakupan asli, tinjauan visual, dan persetujuan UKM manusia.
Pisahkan pesan yang lewat dari kesiapan penegakan
RFC 9989 Bagian 7.4 memerlukan DKIM yang valid untuk penerbitan domain p=reject dan peringatan tentang interoperabilitas surat tidak langsung. Satu hasil SPF yang selaras tidak dengan sendirinya membenarkan penerapan kebijakan penolakan. Tinjau semua rute dan kepemilikan kebijakan yang sah secara terpisah dari pengaturan penyedia ini.