¿Existe un registro DNS estándar para indicar el servidor IMAP para un dominio?

19

Después de un poco de búsqueda, he llegado con las manos vacías si hay alguna especificación estándar (o no estándar para ese caso) o la mejor práctica para especificar el servidor IMAP para un nombre de dominio. Es decir, si tengo una cuenta como "[email protected]" y deseo leer mi correo a través de IMAP, ¿hay algún registro de DNS que le indique a mi cliente de correo con qué servidor de correo debería estar contactando? Nunca he visto algo así, y prácticamente todas las instrucciones de configuración de correo electrónico que he visto incluyen un nombre de host exacto para IMAP, por ejemplo, "mail.example.com" o "imap.example.com". Supongo que la suposición es que los empleados u otros usuarios de example.com pueden averiguar qué servidor usar de su administrador. Sin embargo, si example.com tuviera miles de cuentas, esto se volvería una carga.

¿Alguien ha oído hablar de algo como esto?

domain-name-system email imap bgp
fuente
44
Algunas aplicaciones soportan dns de autodescubrimiento y probablemente exista algún rfc o especificación para el autodescubrimiento de imap. No esperaría que muchos lo hayan seguido, por las mismas razones que usted mencionó. Una organización publicará documentos o usará la administración de configuración para configurar puntos finales. smtp necesita saber los nombres para el enrutamiento de correo. IMAP es enrutado por humanos. :-)
Aaron

Respuestas:

34

Desde una perspectiva DNS, tiene registros SRV DNS que permiten el uso de DNS para publicar servicios y descubrir servicios. Su uso principal es permitir que los servicios se ejecuten fácilmente en puertos no estándar y reducir la carga de configuración al configurar clientes.

Un registro SRV tiene la siguiente forma:

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

y uno para IMAP se define en RFC 6186 y se vería así:

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

o 

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

Sin embargo, la mayoría de los clientes de correo electrónico no buscan específicamente un servidor IMAP primero, pero utilizan el descubrimiento automático para derivar la configuración del cliente de correo electrónico de la dirección de correo electrónico que ingresa un usuario.
Si un usuario ingresa [email protected], dependiendo del cliente, estos generalmente involucran

  • un _autodiscover._tcp.example.com.registro SRV como el usado por MS Exchange y Outlook
  • un host real llamado autoconfig.example.com.
  • o más

Aquí se encuentra una muy buena redacción: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration

HBruijn
fuente
1
Gracias, sí, ese es exactamente el tipo de cosas que estaba buscando. Es interesante que la forma "estándar" de hacerlo (registro SRV) parece no ser popular en absoluto. Supongo que hay poca presión para implementarlo, ya que técnicamente puede escapar sin él siempre y cuando sus usuarios o cliente de correo sepan qué hacer para que funcione.
BGP
3
El "problema" con el correo electrónico es que la configuración del cliente es un poco más elaborada que solo un host / protocolo, algunos ISP usan la dirección de correo electrónico completa como nombre de inicio de sesión, otros solo la parte del usuario o el nombre de inicio de sesión pueden no parecerse a la dirección de correo electrónico . Hay varios algoritmos de hash de contraseña diferentes, servicios en puertos SSL dedicados o STARTTLS en el mismo puerto que el protocolo de texto claro tradicional, POP antes de SMTP vs autenticación SMTP, etc.
HBruijn
44
Algunas de esas cosas se especifican en RFC 6186 , lo que no necesariamente ayuda si no sabe si el servidor sigue el estándar, por supuesto.
legoscia
1

No conozco ningún estándar per se, pero en términos de DNS, generalmente solo registraría el "nombre conocido" imap.example.com y quizás también imaps.example.com

Los registros SRV son para cosas mucho más tardías / más complejas. P.ej. encontrar servidores de Active Directory para un dominio, o usarlos como parte de DNS Service Discovery.

La historia está llena de varios mecanismos de publicidad / descubrimiento de servicios.

Cameron Kerr
fuente
En realidad, los registros SRV estaban destinados a ser utilizables y utilizados por aplicaciones / protocolos no estándar o internos (la complejidad o la simplicidad no era un factor). Creo que ha sido bastante exitoso para eso. Su razón de ser original estaba relacionada con un costoso dispositivo integrado.
Arnt