Postfix y subdominios

Question

Configuré Postfix en una máquina Ubuntu 20.04. Sin embargo, no estoy seguro de dónde tengo que usar el subdominio y dónde el dominio. Llamémoslos mail.example.comy example.comrespectivamente.

El sistema es un cliente nulo, envía correos electrónicos pero no recibe ninguno (implementado a través de inet_interfaces = loopback-onlyin /etc/postfix/main.cf). Tengo la intención de enviar mensajes desde [email protected]exclusivamente.

• El registro MX es @ IN MX 0 mail.example.com.
• A registra para ambos @y mailapunta al servidor Postfix.
• Los certificados TLS mencionados en /etc/postfix/main.cfse refieren a mail.example.com: smtpd_tls_cert_file=/etc/letsencrypt/live/mail.example.com/fullchain.pemy smtpd_tls_key_file=/etc/letsencrypt/live/mail.example.com/privkey.pem.
• Con smtp_generic_maps = hash:/etc/postfix/genericreescribo user@hostnameen .[email protected]​/etc/postfix/main.cf
• Agregué masquerade_domains = example.compara /etc/postfix/main.cfreemplazar mail.example.comin [email protected]con example.com. De alguna manera, eso no funciona. Los correos electrónicos todavía llegan del remitente [email protected].

En consecuencia, las preguntas son:

• ¿Tengo que usar @o mailen el registro MX?
• ¿Los certificados TLS tienen que hacer referencia a mail.example.como a example.com?
• ¿Debería /etc/postfix/genericconvertirse primero user@hostnameen [email protected]o directamente en [email protected]?

Answer 1

La forma más correcta de hacer esto hoy en día es crear una cuenta en el servicio de correo adecuado que esté completamente configurado para servir example.com. (Por supuesto, este podría ser su propio servidor, esto no importa). Luego, en su host nulo, solo configura el servidor de correo como un host inteligente, con autenticación SASL.

Si bien es perfectamente posible configurar Postfix de esta manera (hay muchos manuales disponibles, incluido el propio de Postfix), creo que Postfix es excesivo para tal uso. Considere usar nullmailer, que es adecuado exactamente para sistemas que no hacen nada con el correo excepto generar algunas notificaciones del sistema.

Si eso no es posible, configure DNS de esta manera:

• example.comEl registro MX apunta a su servicio de correo adecuado. No tiene nada que ver con los subdominios.
• nullhost.example.com. MX 10 ., es decir, apuntar a ninguna parte. Esta es una indicación explícita de que no tiene intención de recibir ningún correo para [email protected]. Esto no es necesario si protege el servicio smtpd del host nulo de conexiones externas (firewall tcp/25, solo escucha localhost:25, etc.); sin embargo, lo explícito siempre es mejor que lo implícito.
• este host nulo enviará correo que se establece example.comcomo dominio del remitente, por lo que su correo debe obedecer la configuración DMARC para ese dominio. De lo contrario, los destinatarios que se comporten correctamente abandonarán su correo.

Este último punto, DMARC, podría complicar considerablemente las cosas. Si está configurado de forma segura, lo que significa que el registro se parece a _dmarc.example.com. TXT "v=DMARC1; p=reject; pct=100; ...", deberá configurar la firma SPF y DKIM en el host nulo. SPF es fácil, simplemente agregue "a:nullhost.example.com" al registro SPF TXT. DKIM es un desafío, necesitará crear un par de claves DKIM adicionales, elegir un selector ( nullhostprobablemente sea suficiente), instalar su par público en DNS como nullhost._domainkey.example.com. TXT "... key data ...". Luego configure el canto con la clave privada correspondiente directamente en el host nulo (y use el selector elegido), yo emplearía opendkim para eso. ¿Mencioné que usar un host inteligente es el método preferido?

---

Y tus preguntas.

• Tú no eres el servidor (dijiste que este sistema no debería recibir ningún correo). Por lo tanto, no necesita ningún certificado de servidor TLS. Puede configurar cosas usando el certificado de Cliente TLS, de modo que cuando se conecte a su host inteligente o a otros servidores a través de TLS podrá presentarlo. ¿Pero por qué querrías hacer eso?
• El registro "apex" @ MX, también conocido como example.com. MX, debe dirigirse a la página de example.com.metrotodo eXcambiador (el sistema que recibe el correo de [email protected]). No tiene nada que ver con el correo de ningún subdominio. Cada subdominio es un dominio de correo por sí solo.
• La forma de configurar la reescritura de direcciones depende de usted. Lo único que ve el mundo exterior es el resultado final. Entonces, ¿por qué molestarse en hacerlo en dos pasos?