¿Por qué muchos servidores de correo utilizan subdominios como mail.example.com?

¿Por qué muchos servidores de correo utilizan subdominios como mail.example.com?

Estoy configurando dovecat y postfix por primera vez y me pregunto por qué tantas empresas utilizan subdominios para IMAP y SMTP como smtp.mail.example.com e imap.mail.example.com.

¿Cuáles son los beneficios o también estaría bien usar solo example.com?

Lo pregunto porque aparentemente tengo que usar un certificado SSL confiable porque algunos grandes proveedores de servicios de correo electrónico se niegan a entregar correos electrónicos con los certificados estándar autoasignados. Simplemente sería más económico utilizar un certificado SSL sin comodines.

Entonces, ¿para qué sirve utilizar subdominios?

Respuesta1

La razón principal para usar un dominio como mail.example.como smtp.example.compara permitir moverlo sin afectar otros servicios que se ejecutan en el dominio principal. Sólo las computadoras deben buscar el servidor SMTP, y ese usará el registro MX para. example.com Es posible que sus usuarios necesiten proporcionar los dominios al configurar su cliente, pero muchos (¿la mayoría?) adivinarán correctamente según su [email protected]dirección de correo electrónico.

Con muy pocas excepciones, sólo los robots de spam utilizan un example.comdominio de segundo nivel (), casi siempre falsificado. Los pocos servidores legítimos que utilizan dominios como este example.comsuelen estar dañados en varios otros aspectos también. El uso de un dominio de segundo nivel puede contribuir a la puntuación de spam del correo que envía.

Los administradores profesionales utilizan subdominios dedicados para los servicios de correo. En la mayoría de los casos, será un subdominio que no refleja el nombre del servidor en el que se ejecuta el servicio.

No he tenido ningún problema para enviar o recibir correo SMTP en mi servidor con un certificado autofirmado. El sitio que se conecta ya sabe que tiene el sitio correcto según su registro MX. Recientemente, un par de servidores fallaron en el comando startTLS, pero se volvieron a conectar sin TLS. Creo que estaban usando SSLv3 y fueron rechazados por ese motivo, en lugar de por CA. Una revisión de los fallos más recientes muestra que los spambots se desconectan incorrectamente generando errores. Una parte importante de mi tráfico de correo electrónico ahora está cifrado con TLS y no hay problemas con el certificado de mi CA autofirmada.

El uso de certificados confiables es una forma de autenticar servidores cooperativos dentro de un dominio. Sin embargo, le recomendamos restringir los dominios firmados o utilizar una CA privada (autofirmada). Hay otros casos, como una VPN, en los que también puedes utilizar una CA privada.

Donde puede tener problemas es con Dovecot, pero serán sus usuarios quienes se conectarán. Este no es un servicio para uso del público en general. Si generó una CA para firmar su certificado, puede poner el certificado de CA a disposición de sus usuarios para importarlo a su cliente de correo electrónico. Esto resolverá el problema.

Puede obtener un certificado firmado de forma gratuita ahora. Si no, elVamos a cifrarLa Autoridad de Certificación debería estar disponible este otoño. (Ya está disponible).

Respuesta2

Solo para corregir a @Ram.

El registro MX NO DEBE apuntar a "example.com" según las especificaciones RFC. Eso está completamente mal. En su lugar, debe apuntar un registro MX a su registro "mail.example.com" y apuntar su registro "mail.example.com" a la IP de su servidor.

Respuesta3

Todo se reduce a dónde apuntan sus registros MX. Si sus registros MX apuntan a ejemplo.com en lugar de mail.example.com y ejemplo.com se resuelve en una dirección IP, puede ejecutar su SMTP en ese servidor.

Funciona para configuraciones personales o de oficinas pequeñas, pero las organizaciones más grandes tienen servidores especializados para cada una de las funciones.

Respuesta4

Se supone que un servidor tiene un "nombre de dominio completo" (consultehttps://en.wikipedia.org/wiki/Fully_qualified_domain_name). En su ejemplo, llamarlo simplemente "ejemplo.com" estaría parcialmente calificado porque es un nombre de dominio sin un nombre de servidor.

En la práctica, muchos filtros de spam tratan con mucha sospecha a cualquier servidor que no tenga un FQDN adecuado. Incluso un nombre del tipo 123.123.123.123.example.com probablemente lo incluiría en la lista negra porque obviamente se genera automáticamente y, por lo tanto, probablemente se utilice una máquina temporal (virtual) para evitar los filtros de bloqueo de spam.

Entonces tienes que llamarlo algo.ejemplo.com y la razón por la que la gente usa "correo" para "algo" es simplemente porque es memorable y fácil de adivinar. Si crea una cuenta de correo electrónico en un cliente de correo electrónico, a veces lo adivinará, ahorrándole al usuario la molestia de intentar averiguar el nombre del servidor.

información relacionada