Apabila borang hubungan menyatakan «Terima kasih» tetapi tiada e-mel tiba

Bayangkan sebuah klinik fisioterapi kecil. Laman webnya mempunyai borang hubungan, dan borang itu berfungsi — atau sekurang-kurangnya kelihatan demikian. Pelawat mengisinya, mengklik «Hantar» dan melihat «Terima kasih, kami akan menghubungi anda tidak lama lagi» yang mesra. Apa yang tidak dilihat oleh sesiapa: mesej telah berhenti sampai ke peti masuk klinik itu sejak beberapa waktu lalu. Tiada ralat, tiada e-mel lantunan dalam peti masuk sesiapa, tiada lampu merah di mana-mana. Borang gagal secara senyap.

Mengapa tiada siapa menyedarinya

Halaman «Terima kasih» pada borang biasanya hanya bermaksud satu perkara: laman web telah menyerahkan mesej itu. Sama ada pelayan e-mel menerimanya, memfailkannya sebagai spam atau menolaknya dalam perjalanan berlaku kemudian, di luar pandangan borang. Fungsi mail() PHP, contohnya, melaporkan kejayaan sebaik sahaja sistem setempat menerima mesej untuk penghantaran — bukan apabila ia sampai kepada sesiapa. Maka pelawat menerima pengesahan dan meneruskan urusannya. Sementara itu, pemilik melihat peti masuk kosong dan menganggap bulan itu cuma sunyi. Kurang pertanyaan jarang membimbangkan dengan sendirinya: cuti, cuaca, ekonomi — sentiasa ada penjelasan yang kedengaran lebih munasabah daripada «borang rosak».

Punca lazim

• Kata laluan SMTP atau penyedia e-mel berubah. Borang terus cuba log masuk dengan kelayakan lama dan pelayan e-mel menolak — secara senyap, setakat yang diketahui pelawat.
• PHP mail() tanpa pengesahan. Pelayan web menghantar e-mel secara terus tanpa log masuk ke pelayan e-mel yang sepatutnya. Banyak pelayan penerima menganggap e-mel begini mencurigakan: ia masuk ke folder spam atau terus ditolak.
• SPF, DKIM dan DMARC tidak sejajar. Banyak borang meletakkan alamat pelawat dalam medan From. Mesej itu kemudian mendakwa datang, misalnya, daripada alamat gmail.com tetapi dihantar oleh pelayan web anda — tepat perkara yang DMARC direka untuk hentikan.
• Kemas kini pemalam atau perubahan tema merosakkan borang atau CAPTCHA-nya. Templat yang berubah menggugurkan medan, skrip tidak lagi dimuatkan atau gajet CAPTCHA muncul tanpa skripnya — dan setiap penghantaran gagal pengesahan.
• Peti mel penerima penuh. Pelayan e-mel menolak mesej baharu dan e-mel lantunan pergi ke alamat yang tidak dibaca oleh sesiapa.
• Sepanduk kuki menyekat skrip borang. Jika alat persetujuan mengelaskan CAPTCHA atau skrip borang sebagai «pemasaran», pelawat yang menolak kuki mungkin mendapat borang yang tidak boleh dihantar, atau penghantarannya ditolak kerana token tiada.
• Sijil TLS atau domain telah luput. Pelawat melihat amaran pelayar lalu meninggalkan laman, atau pelayan e-mel tidak lagi dapat dicapai dengan selamat. Jika domain peti mel penerima luput, e-mel kepadanya hanya terhenti.
• Lapisan cache menyampaikan halaman lapuk. Cache halaman penuh boleh memberikan borang dengan token keselamatan luput (nonce atau token CSRF). Pelayan menolak penghantaran dan, bergantung pada konfigurasi, pelawat tidak melihat ralat yang jelas.

Perangkap alamat From

Punca ketiga wajar diteliti kerana banyak persediaan borang memasukkannya secara lalai. DMARC menyemak sama ada domain dalam alamat From yang kelihatan sepadan dengan domain yang disahkan oleh SPF atau DKIM. Jika borang menghantar mesej «daripada» alamat pelawat, pelayan anda tidak dibenarkan menghantar bagi domain itu, maka semakan gagal. Bergantung pada dasar DMARC domain pelawat dan penyedia e-mel anda, mesej masuk ke folder spam atau ditolak. Pembaikannya mudah: hantar daripada alamat pada domain anda sendiri dan letakkan alamat pelawat dalam Reply-To. Mengklik «Balas» masih menghubungi pelawat itu.

Apa yang perlu dilakukan

1. 1Hantar mesej ujian melalui borang anda sendiri secara berkala — sekurang-kurangnya setiap bulan, dan sentiasa selepas kemas kini, perubahan tema atau perubahan tetapan e-mel. Tandakan dengan jelas sebagai ujian supaya tiada siapa membalasnya.
2. 2Ketahui rentak biasa anda. Jika borang biasanya membawa beberapa mesej seminggu, dua minggu tanpa mesej ialah sebab untuk menyemak, bukannya bulan yang sunyi.
3. 3Hantar melalui SMTP dengan pengesahan — melalui penyedia e-mel anda atau perkhidmatan penghantaran khusus — dan bukannya bergantung pada PHP mail().
4. 4Gunakan domain anda sendiri dalam From dan alamat pelawat dalam Reply-To. Kemudian konfigurasikan SPF, DKIM dan DMARC untuk domain itu supaya mesej lulus semakan.
5. 5Simpan salinan setiap penghantaran dalam pangkalan data. Banyak pemalam borang menawarkan ini, kadangkala sebagai tambahan. Jika e-mel gagal, pertanyaan masih ada.
6. 6Semak borang selepas setiap kemas kini pemalam — termasuk CAPTCHA, dan juga dengan kuki ditolak.

Semakan sebegini mudah dilupakan, sebab itulah ia berbaloi diautomasikan. Dengan akaun dan domain yang disahkan, formexposed boleh menghantar penghantaran ujian yang ditandakan dengan jelas dan menyemak sama ada ia benar-benar tiba (semakan penghantaran e-mel, hanya dengan pengaktifan nyata). Ia turut mengesan kesunyian — borang yang biasanya menerima mesej tiba-tiba tidak mendapat apa-apa — serta menyemak SPF, DKIM dan DMARC e-mel pemberitahuan, sijil TLS dan tarikh luput domain. Anda hanya diberi amaran apabila sesuatu berubah.

Jika anda hanya mahu pandangan awal: semakan percuma di formexposed.com tidak memerlukan akaun dan tidak menghantar apa-apa. Antara lain, ia menunjukkan sama ada CAPTCHA wujud tetapi rosak — gajet tanpa skripnya, kunci ujian awam, ralat dalam pelayar — salah satu cara borang berhenti berfungsi secara senyap. Sama ada mesej benar-benar tiba hanya dapat disahkan dengan mesej ujian sebenar, maka hantarlah satu hari ini.