Apakah ada catatan DNS standar untuk menunjukkan server IMAP untuk domain?


19

Setelah beberapa pencarian, saya menemukan benar-benar kosong jika ada spesifikasi standar (atau non-standar) atau praktik terbaik untuk menentukan server IMAP untuk nama domain. Yaitu jika saya memiliki akun seperti "jimi@example.com", dan saya ingin membaca email saya melalui IMAP, apakah ada catatan DNS yang akan menunjukkan kepada klien email saya server mail mana yang harus dihubungi? Saya belum pernah melihat yang seperti ini, dan hampir semua instruksi penyetelan email yang pernah saya lihat menyertakan nama host yang tepat untuk IMAP, misalnya "mail.example.com" atau "imap.example.com". Saya kira asumsinya adalah bahwa karyawan atau pengguna example.com lainnya dapat mengetahui server apa yang akan digunakan dari administrator mereka. Namun jika example.com memiliki ribuan akun, ini akan menjadi beban.

Adakah yang mendengar hal seperti ini?


4
Beberapa aplikasi mendukung penemuan otomatis dns dan mungkin ada beberapa rfc atau spesifikasi untuk penemuan otomatis imap. Saya tidak berharap banyak yang mengikutinya, untuk alasan yang Anda sebutkan. Org akan mempublikasikan dokumen atau menggunakan manajemen konfigurasi untuk mengonfigurasi titik akhir. smtp perlu tahu nama untuk perutean email. IMAP diarahkan manusia. :-)
Aaron

Jawaban:


34

Dari perspektif DNS Anda memiliki catatan DNS SRV yang memungkinkan penggunaan DNS untuk layanan penerbitan dan penemuan layanan. Penggunaan utama mereka adalah untuk memungkinkan layanan berjalan dengan mudah pada port non-standar dan untuk mengurangi beban konfigurasi saat mengatur klien.

Sebuah catatan SRV memiliki bentuk sebagai berikut:

_Service._Protocol.Name. TTL Class SRV Priority Weight Port Target

dan satu untuk IMAP didefinisikan dalam RFC 6186 dan akan terlihat seperti:

_imap._tcp.example.com. 3600 IN SRV 0 10 143 my-imap-host.example.com.

atau

_imaps._tcp.example.com. 3600 IN SRV 0 10 995 my-imaps-host.example.com.

Sebagian besar klien email tidak mencari server IMAP secara khusus terlebih dahulu, tetapi gunakan penemuan otomatis untuk mendapatkan pengaturan klien email dari alamat email yang dimasukkan pengguna.
Jika pengguna memasukkan username@example.com, tergantung pada klien yang biasanya melibatkan keduanya

  • sebuah _autodiscover._tcp.example.com.catatan SRV seperti yang digunakan oleh MS Exchange dan Outlook
  • tuan rumah yang sebenarnya disebut autoconfig.example.com.
  • atau lebih

Tulisan yang cukup bagus ditemukan di sini: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration


1
Terima kasih - ya itulah yang saya cari. Sangat menarik bahwa cara "standar" untuk melakukannya (catatan SRV) tampaknya tidak populer sama sekali. Saya kira ada sedikit tekanan untuk menerapkannya karena Anda secara teknis bisa lolos tanpanya selama pengguna atau klien email Anda tahu apa yang harus dilakukan untuk membuatnya berfungsi.
bgp

3
"Masalah" dengan email adalah bahwa pengaturan klien sedikit lebih rumit dari sekedar host / protokol, beberapa ISP menggunakan alamat email lengkap sebagai nama login, yang lain hanya bagian pengguna atau nama login mungkin bahkan tidak menyerupai alamat email . Ada sejumlah algoritma hashing kata sandi yang berbeda, layanan pada port SSL khusus, atau STARTTLS pada port yang sama dengan protokol teks bening tradisional, POP sebelum otentikasi SMTP vs SMTP, dll.
HBruijn

4
Beberapa dari hal-hal tersebut ditentukan dalam RFC 6186 - bukan berarti itu membantu jika Anda tidak tahu apakah server mengikuti standar, tentu saja.
legoscia

1

Tidak mengetahui standar apa pun, tetapi dalam istilah DNS, Anda biasanya hanya mendaftarkan "nama terkenal" imap.example.com dan mungkin juga imaps.example.com

Catatan SRV adalah untuk hal-hal yang jauh lebih belakangan / lebih rumit. Misalnya. menemukan server Direktori Aktif untuk domain, atau digunakan sebagai bagian dari Penemuan Layanan DNS.

Sejarah dipenuhi dengan berbagai iklan layanan / mekanisme penemuan.


Sebenarnya, catatan SRV dimaksudkan untuk dapat digunakan dan digunakan oleh aplikasi / protokol tidak standar atau internal (kompleksitas atau kesederhanaan bukan merupakan faktor). Saya yakin ini cukup berhasil untuk itu. Raison d'etre aslinya terkait dengan perangkat tertanam yang mahal.
Arnt
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.