Port SMTP mana yang sebaiknya saya gunakan?

Empat port selalu muncul saat aplikasi perlu mengirim email: 25, 465, 587, dan 2525. Dua di antaranya adalah standar submission, 587 dan 465, dan saran yang paling sering diulang tentang 465 sudah tidak berlaku sejak 2018. Port 25 sama sekali bukan untuk submission, dan 2525 adalah konvensi tanpa standar di belakangnya.

Jawaban singkat: gunakan 587 dengan STARTTLS. Gunakan 465 jika klien Anda lebih cocok membuka koneksi TLS secara langsung. Gunakan 2525 jika ada sesuatu di jaringan Anda yang memblokir 587. Jangan gunakan 25 untuk mengirim email dari aplikasi.

Apa fungsi masing-masing port?

Port-port ini berbeda pada dua hal: apakah ditujukan untuk submission atau relay, dan kapan enkripsi koneksi dimulai.

• 25 adalah port relay. Ini cara satu mail server menyerahkan pesan ke server lain. Port ini sudah ada sebelum submission terautentikasi dan tidak membawa ekspektasi keduanya.
• 587 adalah port submission, ditetapkan untuk tujuan tersebut oleh RFC 6409. Koneksi dibuka dalam plaintext dan di-upgrade ke TLS dengan perintah STARTTLS sebelum kredensial dikirim.
• 465 adalah port submission TLS implisit. Handshake TLS terjadi lebih dulu dan seluruh dialog SMTP berjalan di dalamnya, sehingga tidak ada yang pernah dikirim tanpa enkripsi. Library biasanya melabeli ini "SSL/TLS" atau "SMTPS".
• 2525 sama sekali tidak memiliki standar yang menetapkannya untuk SMTP. Penyedia menawarkannya sebagai alternatif 587 untuk jaringan yang memblokir port standar.

Perbedaan antara 465 dan 587 terletak pada kapan TLS dimulai, bukan seberapa kuat enkripsinya. Di 465, koneksi sudah terenkripsi sejak byte pertama. Di 587, enkripsi dimulai satu round trip kemudian, dan server yang dikonfigurasi dengan benar menolak AUTH sampai enkripsi aktif.

Apakah port 465 usang?

Tidak, dan ini adalah saran SMTP usang yang paling sering ditemui.

Sejarahnya memang membingungkan. Port 465 awalnya ditetapkan untuk SMTP over TLS, lalu dicabut demi pendekatan STARTTLS di 587, yang menjadi asal saran "465 is deprecated" tersebut. Saran itu memang benar untuk suatu periode. Kemudian RFC 8314, diterbitkan pada Januari 2018, merekomendasikan TLS implisit untuk submission email dan menetapkan kembali 465 sebagai port-nya, dengan nama layanan submissions.

Jadi halaman yang menyatakan 465 sudah usang menggambarkan keadaan sebelum 2018. Baik 465 maupun 587 sama-sama berlaku. Pilih yang paling didukung klien Anda, dan utamakan 465 jika Anda tidak ingin bergantung pada upgrade plaintext-ke-TLS sama sekali.

Mengapa port 25 diblokir, dan bagaimana cara memeriksanya?

Port 25 keluar diblokir oleh banyak ISP konsumer serta penyedia cloud dan hosting, karena port relay tanpa autentikasi di mesin yang dikompromikan adalah cara spam massal dikirim. Apakah pemblokiran bisa dicabut tergantung siapa yang memasangnya. ISP konsumer umumnya tidak akan mencabutnya untuk jalur residensial, sedangkan penyedia cloud bervariasi: sebagian menerima permintaan pencabutan, dan setidaknya satu tidak memberikan pengecualian sama sekali. Periksa kebijakan yang dipublikasikan penyedia Anda sendiri daripada berasumsi.

Anda bisa mengonfirmasi pemblokiran dengan membuka koneksi ke mail server yang dikenal di port 25 dan melihat apakah Anda mendapat salam 220 atau timeout. Sesi manual adalah cara paling jelas untuk melihatnya, dan memeriksa koneksi SMTP dengan sesi telnet memandu prosesnya.

Jika port 25 diblokir, itu bukan masalah yang perlu dipecahkan. Aplikasi seharusnya tetap mengirim melalui 587 atau 465.

Apa perbedaan antara submission dan relaying?

Submission adalah klien email atau aplikasi yang menyerahkan pesan baru ke server yang telah diautentikasi. Relaying adalah server yang meneruskan pesan yang sudah ada menuju tujuannya.

Perbedaan ini menentukan port dan aturan mana yang berlaku. Submission memerlukan autentikasi, memungkinkan server memperbaiki dan menandatangani pesan sebelum dikirim, dan terjadi di 587 atau 465. Relaying terjadi di 25, antar-server, dan menjadi bahan penilaian sistem spam dan reputasi penerima.

Aplikasi yang mengirim email sendiri selalu melakukan submission. Jika Anda sedang mengonfigurasi sesuatu dan memilih port 25, konfigurasi tersebut mengarah ke bagian sistem yang salah.

Port mana yang diterima Bird?

Tiga, dan port 25 sengaja tidak termasuk:

Di 587 dan 2525, AUTH ditolak sampai STARTTLS selesai, sehingga kredensial tidak pernah dikirim tanpa enkripsi di ketiga port tersebut. Port 25 tidak ditawarkan untuk submission.

Host bergantung pada region kunci Anda, yaitu prefiks di kunci itu sendiri: kunci bk_eu1_... mengirim melalui eu1.smtp.bird.com, kunci bk_us1_... melalui us1.smtp.bird.com. Autentikasi menggunakan kunci API biasa Anda, bukan kredensial SMTP terpisah: username-nya adalah string literal bird dan password-nya adalah kunci tersebut.

Email yang dikirim melalui SMTP diperlakukan sama persis seperti email yang dikirim melalui email API, dengan verifikasi domain, penandatanganan DKIM, penanganan supresi, pelacakan, dan event yang sama. Kirim email melalui SMTP memuat referensi koneksi lengkap, dua sesi beranotasi, satu di 465 dan satu untuk 587 dan 2525, serta default per-kunci yang membentuk pengiriman.

Bagaimana cara mengetahui port yang digunakan klien saya?

Tempat melihatnya bergantung pada perangkat lunak, dan polanya konsisten:

• Framework aplikasi menyimpannya di konfigurasi email, biasanya di samping host, sebagai pengaturan port atau MAIL_PORT.
• Sistem manajemen konten menampilkannya di halaman pengaturan plugin SMTP bersama dropdown enkripsi. Dropdown itulah pengaturan yang sering salah dikonfigurasi: "SSL/TLS" berarti 465 dan "STARTTLS" berarti 587 atau 2525, dan ketidakcocokan keduanya menghasilkan koneksi yang menggantung atau ditolak, bukan pesan error yang berguna.
• Perangkat seperti printer dan scanner menyimpannya di layar notifikasi atau scan-to-email.

Jika email gagal terkirim dan Anda mencurigai port-nya, uji koneksi secara langsung sebelum mengubah kode aplikasi. Sesi manual memberi tahu Anda apakah port dapat dijangkau, apakah TLS berhasil dinegosiasikan, dan apakah autentikasi diterima, yang memisahkan masalah pemblokiran jaringan dari masalah kredensial.