E-mel CFML tidak sampai: log SMTP, DKIM dan SPF

E-mel CFML tidak sampai: log SMTP, DKIM dan SPF

Apabila cfmail melaporkan "berjaya" tetapi e-mel tidak sampai, masalahnya hampir selalu terletak di luar kod CFML anda: pelayan SMTP menangguh atau mengembalikan mesej, rekod DNS seperti SPF dan DKIM tidak lengkap, atau penerima menapis mesej ke folder spam. Artikel ini membawa anda melalui urutan diagnosis yang betul, daripada panggilan cfmail dalam aplikasi sehinggalah ke peti masuk penerima, dengan bukti sebenar yang dijalankan pada Lucee 7.1.

Urutan diagnosis yang betul

Kesilapan paling kerap ialah melompat terus ke DNS apabila sebenarnya sambungan SMTP pun belum berjaya. Diagnosis mesti bergerak dari dalam ke luar, dari aplikasi ke penerima, kerana setiap peringkat bergantung pada peringkat sebelumnya. Jika cfmail tidak dipanggil langsung, tiada gunanya memeriksa SPF. Jika pelayan SMTP mengembalikan status deferred, mesej belum sampai ke alam DNS penerima. Urutan yang terbukti ialah enam langkah: aplikasi, sambungan SMTP, rekod SPF, tandatangan DKIM, reputasi penghantar, dan akhir sekali peti masuk penerima.

Peringkat 1: Aplikasi dan panggilan cfmail

Langkah pertama ialah memastikan cfmail benar-benar dipanggil dengan atribut yang betul. Tiga atribut wajib ialah from, to dan subject, manakala butiran sambungan boleh diletakkan terus pada tag supaya tidak bergantung pada tetapan pelayan:

<cfmail
    from="kedai@contoh.my"
    to="pelanggan@contoh.my"
    subject="Pengesahan Pesanan"
    server="smtp.contoh.my"
    port="587"
    username="kirim@contoh.my"
    password="kataLaluanSulit"
    useTls="true"
    spoolEnable="false"
    timeout="30">
Terima kasih, pesanan anda telah diterima.
</cfmail>

Dua atribut penyulitan menentukan mod sambungan: useSsl="true" bermaksud SSL tersirat dari bait pertama, lazimnya port 465, manakala useTls="true" bermula dengan SMTP biasa lalu menaik taraf melalui STARTTLS, lazimnya port 587. Pilih yang ditawarkan penyedia anda. Jangan simpan kata laluan SMTP terus dalam kod; baca daripada pemboleh ubah persekitaran seperti yang diterangkan dalam panduan rahsia dalam pemboleh ubah persekitaran.

spoolEnable dan direktori spool

Secara lalai Lucee meletakkan e-mel dalam spool dan menghantarnya melalui bebenang latar belakang untuk prestasi yang lebih baik. Ini bermakna panggilan cfmail kembali serta-merta tanpa menunggu pelayan SMTP menjawab, dan ralat sambungan tidak dibuang kepada kod anda, sebaliknya dicatat ke remoteclient.log. Untuk menghantar segera dan menangkap ralat, tetapkan spoolEnable="false", atau guna async="false" dalam bentuk skrip.

Mesej yang di-spool disimpan sebagai fail tugas .tsk di bawah folder konteks Lucee, lazimnya WEB-INF/lucee/remote-client/. Folder inilah tempat anda melihat mesej yang menunggu penghantaran atau yang gagal dihantar. Apabila spoolEnable="true", kegagalan sambungan hanya kelihatan kemudian dalam log spooler, bukan pada permintaan HTTP, jadi satu panggilan yang kelihatan berjaya sebenarnya boleh menjadi mesej yang tidak pernah keluar.

Tangkap ralat SMTP sebenar

Untuk membuktikan bagaimana ralat sambungan kelihatan, ujian ini dijalankan pada Lucee 7.1 dengan spoolEnable="false" dan pelayan SMTP yang tidak wujud. Ini adalah mesej ralat sebenar yang dibuang oleh enjin, tidak disunting:

smtp.tidak.wujud.invalid Couldn't connect to host,
port: smtp.tidak.wujud.invalid, 587; timeout 15000:0
nested exception is: java.net.UnknownHostException: smtp.tidak.wujud.invalid

Pengecualian bersarang di baris terakhir ialah kunci diagnosis: java.net.UnknownHostException bermaksud nama hos tidak dapat diselesaikan oleh DNS, jadi masalahnya ialah nama pelayan yang salah taip atau tidak wujud. Apabila pelayan wujud tetapi tiada apa-apa mendengar pada port itu, ralat berubah kepada Connection refused (connect failed) sebaliknya. Kedua-duanya bermaksud perkara yang sama: mesej tidak pernah meninggalkan aplikasi. Jika anda melihat ralat ini, masalahnya ialah sambungan, dan tiada gunanya memeriksa SPF atau DKIM lagi.

Membaca log SMTP pelayan

Setelah sambungan berjaya, soalan seterusnya ialah apa yang pelayan SMTP lakukan dengan mesej itu. Jawapannya ada dalam log pelayan mel, bukan dalam kod CFML. Pada Postfix, log lazimnya di /var/log/mail.log, dan setiap mesej membawa satu status. Pada Exim, log berada di /var/log/exim4/mainlog dan status ditandai dengan simbol:

# Postfix: cari status penghantaran setiap mesej
grep -E "status=(sent|deferred|bounced)" /var/log/mail.log

# Exim: => dihantar, == ditangguh, ** dianjak balik
grep -E "=>|==|\*\*" /var/log/exim4/mainlog | tail -n 50

Tiga status itu membezakan tiga nasib yang berbeza. status=sent bermaksud pelayan penerima menerima mesej, walaupun itu belum menjamin ia sampai ke peti masuk. status=deferred bermaksud kegagalan sementara dan pelayan akan cuba semula, selalunya kerana penerima tidak dapat dihubungi atau menolak dengan kod 4xx. status=bounced bermaksud kegagalan kekal dengan kod 5xx, seperti alamat yang tidak wujud, dan mesej dikembalikan kepada penghantar. Untuk memahami cara membaca dan mengagregat log ini, rujuk panduan log dan pemantauan CFML.

Peringkat DNS: SPF, DKIM dan DMARC

Sebaik sahaja SMTP melaporkan sent, mesej tiba di pelayan penerima, dan di situlah tiga rekod DNS menentukan sama ada ia dipercayai. SPF menyenaraikan pelayan yang dibenarkan menghantar bagi pihak domain anda melalui rekod TXT yang bermula dengan v=spf1. DKIM menandatangani mesej, dan kunci awamnya diterbitkan pada subdomain selector._domainkey.domainsaya. DMARC, diterbitkan pada _dmarc.domainsaya, memberitahu penerima apa yang perlu dilakukan apabila SPF atau DKIM gagal.

Untuk memeriksa ketiga-tiganya, gunakan dig. Sesi berikut dijalankan pada domain lucee.my dan menunjukkan output sebenar, bukan contoh rekaan:

$ dig +short TXT lucee.my
"google-site-verification=61VAIzXOJUjON5tkT5gKGsqiWePK0VSmsd2QHblrepU"

$ dig +short MX lucee.my
( kosong, tiada rekod MX )

$ dig +short TXT _dmarc.lucee.my
( kosong, tiada rekod DMARC )

Domain ini jelas disediakan untuk web, bukan untuk menghantar e-mel: tiada rekod v=spf1, tiada rekod MX, dan tiada rekod DMARC. Jika aplikasi menghantar e-mel dengan alamat pengirim@lucee.my, penerima tidak akan menemui SPF mahupun DKIM untuk mengesahkannya, dan mesej itu berkemungkinan besar ditapis sebagai spam. Ini adalah contoh hidup tentang rupa domain yang belum dikonfigurasikan untuk e-mel, dan cara dig mendedahkannya dalam beberapa saat.

Kenapa e-mel masuk spam walaupun SMTP berjaya

status=sent hanya bermaksud pelayan penerima menerima mesej pada peringkat SMTP. Ia tidak bermaksud mesej sampai ke peti masuk. Selepas penerimaan, pelayan penerima menjalankan penapis spamnya sendiri: ia menyemak penjajaran SPF dan DKIM, reputasi alamat IP penghantar, senarai hitam, dan heuristik kandungan. Mesej tanpa SPF dan DKIM yang sah dianggap tidak disahkan, dan penyedia besar seperti Gmail dan Outlook cenderung meletakkannya dalam folder spam tanpa mengembalikan sebarang ralat.

Inilah sebabnya mesej boleh "berjaya dihantar" mengikut log anda tetapi tidak pernah dilihat oleh penerima. Keterhantaran ialah soal reputasi domain dan IP, bukan soal sama ada sambungan SMTP berjaya. Satu-satunya cara untuk memperbaikinya ialah menetapkan SPF, menandatangani dengan DKIM, dan menerbitkan polisi DMARC pada domain penghantar, kemudian memantau laporan DMARC untuk melihat bagaimana penerima memperlakukan mesej anda.

Jadual peringkat kegagalan

Jadual berikut meringkaskan enam peringkat kegagalan dan cara mengesahkan setiap satu:

Gunakan jadual ini sebagai senarai semak dari atas ke bawah. Berhenti pada peringkat pertama yang gagal dan betulkan sebelum meneruskan, kerana peringkat seterusnya tidak akan pernah dilalui jika peringkat sebelumnya rosak.

Jangan hantar ujian ke domain contoh

Semasa menguji, godaan biasa ialah menghantar e-mel ujian ke alamat rawak seperti ujian@example.com untuk melihat sama ada ia sampai. Ini kesilapan yang merosakkan reputasi. Alamat pada example.com dan domain contoh lain tidak menerima e-mel, jadi pelayan penerima mengembalikan bounce keras dengan kod 5xx, contohnya 550 5.1.1 User unknown. Bounce keras ialah isyarat kepada penyedia besar bahawa anda menghantar ke alamat yang tidak wujud, satu ciri penghantar spam, dan ia menurunkan reputasi domain anda.

Sebaliknya, hantar ujian ke alamat pada domain yang anda miliki, atau gunakan perkhidmatan peti mel ujian yang direka untuk tujuan ini. Untuk mempelajari cara menghantar dan mengkonfigurasi cfmail dengan betul dari awal, rujuk panduan cfmail dan konfigurasi SMTP, dan untuk memahami tetapan this.mailservers dalam konfigurasi aplikasi, baca panduan memahami Application.cfc.

Soalan Lazim

Bagaimana saya tahu sama ada cfmail gagal atau berjaya?

Tetapkan spoolEnable="false" supaya ralat dibuang terus kepada kod anda, dan bungkus panggilan dalam try/catch. Dengan spool lalai, ralat hanya kelihatan dalam remoteclient.log.

Apakah maksud status deferred dalam log Postfix?

status=deferred bermaksud kegagalan sementara dengan kod 4xx, dan pelayan akan mencuba semula secara automatik. Ia berbeza daripada status=bounced yang merupakan kegagalan kekal dengan kod 5xx.

Di mana saya menyemak rekod SPF dan DKIM?

Guna dig +short TXT domain untuk SPF, dig +short MX domain untuk pelayan penerima, dan dig +short TXT selector._domainkey.domain untuk kunci awam DKIM. DMARC disemak pada _dmarc.domain.

Kenapa e-mel saya sampai ke folder spam walaupun log menunjukkan sent?

Kerana sent hanya bermaksud pelayan penerima menerima mesej pada peringkat SMTP. Penapisan spam berlaku selepas itu, dan mesej tanpa SPF, DKIM dan DMARC yang sah dianggap tidak disahkan lalu ditapis.

Adakah selamat menghantar e-mel ujian ke example.com?

Tidak. Domain contoh tidak menerima e-mel dan mengembalikan bounce keras yang merosakkan reputasi penghantar anda. Guna alamat pada domain sendiri atau peti mel ujian khusus.

Sumber

• cfmail, Lucee Documentation
• Sending Emails, Lucee Documentation
• cfmail attributes, CF Docs
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM)
• RFC 7489: DMARC
• Postfix Documentation