Mengapa borang hubungan anda ialah liabiliti spam terbesar anda

Masalah ini lebih lama daripada yang anda sangka

Borang hubungan telah menjadi vektor spam sejak awal 2000-an, tetapi masalah ini semakin buruk apabila penyedia e-mel mengetatkan keperluan pengesahan mereka. Kebanyakan borang hubungan masih dibina dengan cara yang sama: pengguna mengisi borang, pelayan anda menghantar e-mel menggunakan alamat pengguna dalam pengepala From, dan anda menunggu balasan.

Ini ialah kerentanan spoofing e-mel yang klasik. Pengirim spam boleh menggunakan borang anda untuk menghantar e-mel yang kelihatan datang daripada mana-mana alamat yang mereka mahu, dirutekan melalui IP pelayan anda. Jika cukup banyak spam keluar dengan cara ini, domain anda akan ditandakan dan e-mel transaksi anda yang sah berhenti sampai ke inbox.

Pembaikannya mudah, tetapi kebanyakan tutorial masih melakukannya dengan salah.

Apa yang menjadikan borang hubungan begitu mudah dieksploitasi

Borang hubungan biasa menerima tiga medan: nama, e-mel, dan mesej. Pengendali sisi pelayan mengambil alamat e-mel itu dan meletakkannya terus ke dalam pengepala From bagi mesej SMTP keluar. Ini memudahkan balasan—anda hanya perlu menekan "reply" dalam inbox anda—tetapi ia juga hadiah kepada pengirim spam.

Begini yang berlaku apabila pengirim spam menemui borang anda:

1. Mereka menghantar borang dengan alamat e-mel mangsa dalam medan "from"
2. Pelayan anda dengan patuh menghantar e-mel dengan alamat mangsa itu dalam pengepala From
3. Pelayan mel mangsa melihat e-mel yang mendakwa datang daripada domain mereka, tetapi berasal daripada IP anda
4. Jika domain anda tidak mempunyai rekod SPF/DKIM/DMARC yang betul (atau walaupun ia mempunyainya), e-mel itu masih mungkin lepas kerana banyak pelayan bersikap longgar terhadap trafik borang hubungan
5. Mangsa menerima spam yang kelihatan datang daripada alamat mereka sendiri, atau domain anda ditandakan kerana spoofing

Ini bukan serangan teori. Ia berlaku sepanjang masa. Jika anda menjalankan borang hubungan dan tidak pernah menyemak log pelayan mel anda, anda mungkin sudah digunakan dengan cara ini.

Cara yang betul untuk menghantar e-mel borang hubungan

Pembaikannya ialah jangan sekali-kali meletakkan input pengguna dalam pengepala From. Sebaliknya:

• From: [email protected] (atau mana-mana alamat yang anda kawal)
• Reply-To: Alamat e-mel yang dihantar oleh pengguna
• Subject: Sertakan nama pengguna jika anda mahu, tetapi jangan sekali-kali e-mel mereka
• Body: Sertakan semua data borang, dilabel dengan jelas

Dengan cara ini, pelayan anda hanya menghantar e-mel daripada alamat yang anda miliki dan telah disahkan dengan betul. Apabila anda menekan "reply" dalam inbox anda, ia masih pergi kepada pengguna—itulah fungsi Reply-To. Tetapi pengirim spam tidak boleh menggunakan borang anda untuk menyamar sebagai alamat sewenang-wenangnya.

Kebanyakan pustaka e-mel menyokong ini secara terus. Dalam PHPMailer PHP:

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

Dalam smtplib Python dengan email.mime:

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

Dalam Node.js dengan Nodemailer:

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

Jika borang hubungan anda pada masa ini meletakkan input pengguna dalam pengepala From, ini ialah pembaikan satu baris. Lakukan hari ini.

Pengehadan kadar bukan pilihan

Walaupun dengan kebersihan pengepala yang betul, borang hubungan yang tidak dilindungi masih merupakan vektor spam. Pengirim spam akan menghantar borang anda ratusan kali dengan kandungan mesej yang berbeza, dan inbox anda akan dipenuhi sampah.

Anda memerlukan pengehadan kadar pada beberapa tahap:

• Setiap IP: Tidak lebih daripada 5 penghantaran sejam daripada IP yang sama
• Setiap e-mel: Tidak lebih daripada 3 penghantaran sehari daripada alamat e-mel yang sama
• Global: Tidak lebih daripada 50 penghantaran sejam merentas semua pengguna (laraskan berdasarkan trafik anda)

Pengehadan kadar sepatutnya berada dalam kod aplikasi anda, bukan hanya dalam konfigurasi pelayan web anda. Pengehadan kadar Nginx dan Apache boleh membantu, tetapi ia beroperasi pada tahap permintaan dan tidak mengetahui tentang alamat e-mel atau corak penyalahgunaan khusus borang.

Jika anda menggunakan framework, mungkin sudah ada middleware pengehadan kadar yang boleh anda masukkan. Jika anda membina dari awal, pembilang Redis ringkas dengan kunci yang tamat tempoh sudah memadai:

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

Ini bukan kalis sepenuhnya—pengirim spam boleh memutar IP—tetapi ia meningkatkan kos penyalahgunaan dengan ketara.

CAPTCHA ialah pertukaran, bukan penyelesaian

reCAPTCHA v3 Google tidak kelihatan dan memberi skor kepada pengguna berdasarkan tingkah laku, yang kedengaran ideal. Dalam praktik, ia menyekat pengguna yang sah lebih kerap daripada yang anda jangka, terutamanya pengguna pada VPN, Tor, atau rangkaian korporat berkongsi.

reCAPTCHA v2 (kotak semak "I'm not a robot") lebih boleh dipercayai tetapi menambah geseran. Medan honeypot—input borang tersembunyi yang manusia tidak akan isi tetapi bot akan isi—menangkap bot yang kurang canggih tanpa kesan kepada pengguna, tetapi ia mudah dipintas oleh mana-mana pengirim spam yang serius.

Pendekatan terbaik ialah berlapis:

1. Pengepala e-mel yang betul (tidak boleh dirunding)
2. Pengehadan kadar (tidak boleh dirunding)
3. Medan honeypot (kemenangan mudah, tiada kelemahan)
4. CAPTCHA hanya jika anda masih menerima spam yang ketara selepas perkara di atas

Jika anda menambah CAPTCHA, gunakan reCAPTCHA v3 dengan ambang rendah (0.5 atau lebih rendah) dan fallback kepada v2 untuk pengguna yang mendapat skor rendah. Ini mengekalkan geseran yang rendah untuk kebanyakan pengguna sambil masih menyekat bot.

Bila menggunakan perkhidmatan borang pihak ketiga

Jika anda menjalankan laman kecil dan tidak mahu menyelenggara infrastruktur borang, perkhidmatan pihak ketiga seperti Formspree, Tally, atau Netlify Forms mengendalikan semua ini untuk anda. Mereka mengehadkan kadar, mengesahkan, dan menghantar e-mel daripada domain mereka sendiri, jadi reputasi anda kekal bersih.

Pertukarannya ialah anda menghantar data pengguna kepada pihak ketiga, yang mungkin bercanggah dengan dasar privasi atau kewajipan GDPR anda. Memproses data di sisi klien ialah trend yang semakin berkembang untuk pasukan yang peka privasi, tetapi borang hubungan secara asasnya memerlukan pemprosesan sisi pelayan—anda tidak boleh menghantar e-mel daripada pelayar tanpa mendedahkan kelayakan.

Jika anda mengendalikan pertanyaan sensitif (undang-undang, perubatan, kewangan), anda mungkin perlu menjalankan infrastruktur borang anda sendiri. Untuk perkara lain, perkhidmatan pihak ketiga ialah pilihan yang munasabah.

Masalah DMARC

Walaupun anda membetulkan pengepala borang hubungan anda, anda tidak selamat jika domain anda tidak mempunyai dasar DMARC. DMARC memberitahu pelayan mel penerima apa yang perlu dilakukan dengan e-mel yang gagal semakan SPF atau DKIM. Tanpanya, pengirim spam masih boleh menghantar e-mel yang kelihatan datang daripada domain anda, walaupun mereka tidak menggunakan pelayan anda.

Penyediaan DMARC berada di luar skop artikel ini, tetapi jika anda serius tentang reputasi e-mel, ia tidak boleh dirunding. Mulakan dengan dasar pemantauan sahaja (p=none) dan beralih secara beransur-ansur kepada p=quarantine atau p=reject apabila anda mengesahkan bahawa e-mel sah anda disahkan dengan betul.

Bagaimana pula dengan Persetujuan cookie dan penjejakan borang?

Jika borang hubungan anda menggunakan analitik atau piksel pemasaran untuk menjejak penghantaran, anda mungkin tertakluk kepada peraturan GDPR dan ePrivacy. Kebanyakan borang hubungan tidak memerlukan penjejakan—anda sudah tahu seseorang menghantar borang kerana anda menerima e-mel—tetapi jika anda menggunakan sesuatu seperti Facebook Pixel atau acara Google Analytics, anda memerlukan persetujuan jelas sebelum skrip tersebut dimuatkan.

Pendekatan paling mudah ialah tidak menjejak penghantaran borang hubungan sama sekali. Jika anda mesti menjejakinya, muatkan skrip penjejakan hanya selepas pengguna memberi persetujuan, dan pastikan banner persetujuan anda patuh.

Perkara utama

• Jangan sekali-kali meletakkan alamat e-mel yang dihantar pengguna dalam pengepala From. Gunakan Reply-To sebaliknya.
• Pengehadan kadar adalah wajib. Laksanakannya pada tahap aplikasi, bukan hanya pelayan web.
• Medan honeypot ialah kemenangan percuma. CAPTCHA sepatutnya menjadi pilihan terakhir.
• Perkhidmatan borang pihak ketiga ialah pilihan yang munasabah untuk laman kecil, tetapi ia memperkenalkan pertukaran privasi.
• Jika anda menghantar sebarang e-mel daripada domain anda, anda memerlukan dasar DMARC.

Soalan Lazim

Q: Bolehkah saya hanya melumpuhkan borang hubungan dan menggunakan pautan mailto sebaliknya?

A: Boleh, tetapi pautan mailto mendedahkan alamat e-mel anda kepada scraper, dan anda kehilangan keupayaan untuk mengumpul data berstruktur. Jika spam terlalu banyak, pautan mailto lebih baik daripada borang hubungan yang rosak, tetapi membetulkan borang lebih baik daripada kedua-duanya.

Q: Bagaimana jika saya perlu menghantar e-mel daripada alamat pengguna atas sebab yang sah?

A: Hampir pasti anda tidak perlu. Jika anda fikir anda perlu, anda mungkin cuba menyelesaikan masalah aliran kerja (seperti penghalaan balasan) yang sudah diselesaikan oleh Reply-To. Jika anda benar-benar perlu menghantar e-mel daripada alamat sewenang-wenangnya, anda memerlukan perkhidmatan e-mel khusus dengan pengesahan yang betul, bukan borang hubungan.

Q: Bagaimana saya tahu jika borang hubungan saya sudah disalahgunakan?

A: Semak log pelayan mel anda untuk sambungan SMTP keluar. Jika anda melihat volum e-mel keluar yang tinggi ke alamat yang anda tidak kenali, atau jika domain anda telah ditandakan oleh pangkalan data spam seperti Spamhaus, anda mungkin sedang digunakan sebagai relay. Alat seperti MXToolbox boleh menyemak reputasi domain anda.

Q: Adakah selamat menggunakan perkhidmatan CAPTCHA percuma?

A: reCAPTCHA Google adalah percuma dan digunakan secara meluas, tetapi ia menghantar data pengguna kepada Google, yang mungkin bercanggah dengan dasar privasi anda. hCaptcha ialah alternatif berfokus privasi yang tidak melatih model AI pada pengguna anda. Cloudflare Turnstile ialah pilihan lain yang kurang mengganggu berbanding CAPTCHA tradisional.

Q: Apakah perbezaan antara SPF, DKIM, dan DMARC?

A: SPF menyenaraikan pelayan mel yang dibenarkan menghantar e-mel daripada domain anda. DKIM menandatangani e-mel keluar secara kriptografi supaya penerima boleh mengesahkan ia tidak diubah suai. DMARC menggabungkan kedua-duanya dan memberitahu penerima apa yang perlu dilakukan jika e-mel gagal semakan SPF atau DKIM. Anda memerlukan ketiga-tiganya untuk pengesahan e-mel yang betul.

Sumber

• OWASP: Email Header Injection — Penjelasan terperinci tentang bagaimana borang hubungan boleh dieksploitasi untuk spoofing e-mel.
• RFC 5322: Internet Message Format — Standard teknikal yang mentakrifkan pengepala e-mel, termasuk From dan Reply-To.
• DMARC.org: Overview — Sumber rasmi untuk memahami dan melaksanakan dasar DMARC.
• Spamhaus: Domain Blocklists — Semak sama ada domain anda telah ditandakan kerana spam dan fahami cara blocklist berfungsi.