Postfix e subdomínios

Postfix e subdomínios

Configurei o Postfix em uma máquina Ubuntu 20.04. No entanto, não tenho certeza de onde devo usar o subdomínio e onde está o domínio. Vamos chamá-los de mail.example.come example.comrespectivamente.

O sistema é um cliente nulo, enviando emails mas não recebendo (implementado via inet_interfaces = loopback-onlyin /etc/postfix/main.cf). Pretendo enviar mensagens [email protected]exclusivamente.

  • O registro MX é @ IN MX 0 mail.example.com.
  • Registros para ambos @e mailapontam para o servidor Postfix.
  • Os certificados TLS mencionados /etc/postfix/main.cfreferem-se a mail.example.com: smtpd_tls_cert_file=/etc/letsencrypt/live/mail.example.com/fullchain.peme smtpd_tls_key_file=/etc/letsencrypt/live/mail.example.com/privkey.pem.
  • Com smtp_generic_maps = hash:/etc/postfix/genericeu reescrevo user@hostnamepara [email protected]in /etc/postfix/main.cf.
  • Eu adicionei masquerade_domains = example.compara /etc/postfix/main.cfsubstituir o mail.example.comin [email protected]por example.com. De alguma forma, isso não funciona. Os e-mails ainda chegam do remetente [email protected].

As perguntas são respectivamente:

  • Devo usar @ou mailno registro MX?
  • Os certificados TLS precisam se referir a mail.example.comou a example.com?
  • Deve /etc/postfix/genericprimeiro converter user@hostnameem [email protected]ou diretamente em [email protected]?

Responder1

A maneira mais correta de fazer isso hoje em dia é criar uma conta no serviço de e-mail adequado e totalmente configurado para servir example.com. (Claro, este pode ser o seu próprio servidor, isso não importa.) Então, no seu host nulo, você configura apenas o servidor de e-mail como um host inteligente, com autenticação SASL.

Embora seja perfeitamente possível configurar o Postfix assim (existem muitos manuais por aí, incluindo o próprio Postfix), acho que o Postfix é um exagero para tal uso. Considere usar nullmailer, que é adequado exatamente para sistemas que não fazem nada com e-mail, exceto originar algumas notificações do sistema.

Se isso não for possível, configure o DNS assim:

  • example.comO registro MX aponta para seu serviço de correio adequado. Não tem nada a ver com subdomínios.
  • nullhost.example.com. MX 10 ., ou seja, apontar para lugar nenhum. Esta é uma indicação explícita de que você não pretende receber nenhuma correspondência de [email protected]. Isso não será necessário se você proteger o serviço smtpd do host nulo de conexões externas (firewall tcp/25, somente escuta localhost:25, etc.); entretanto, explícito é sempre melhor que implícito.
  • esse host nulo enviará e-mails definidos example.comcomo domínio do remetente, portanto, seu e-mail deve obedecer às configurações DMARC para esse domínio. Caso contrário, os destinatários que se comportarem corretamente irão descartar sua correspondência.

Este último ponto, DMARC, poderia complicar consideravelmente as coisas. Se estiver definido com segurança, o que significa que o registro se parece com _dmarc.example.com. TXT "v=DMARC1; p=reject; pct=100; ...", você precisará configurar a assinatura SPF e DKIM no host nulo. SPF é fácil, basta adicionar "a:nullhost.example.com" ao registro SPF TXT. DKIM é desafiador, você precisará criar um par de chaves DKIM adicional, escolher um seletor ( nullhostprovavelmente servirá), instalar seu par público no DNS como nullhost._domainkey.example.com. TXT "... key data ...". Em seguida, configure o singning com a chave privada correspondente diretamente no host nulo (e use o seletor escolhido). Eu empregaria o opendkim para isso. Mencionei que usar host inteligente é o método preferido?


E, suas perguntas.

  • Você não é o servidor (você disse que este sistema não deveria receber nenhum email). Portanto, você não precisa de nenhum certificado de servidor TLS. Você pode configurar coisas usando o certificado de cliente TLS, portanto, quando você se conectar ao seu host inteligente ou a outros servidores via TLS, você poderá apresentá-lo. Mas porque você iria querer fazer aquilo?
  • O registro "apex" @ MX, também conhecido como example.com. MX, deve ser direcionado para example.com'seutudo bemxchanger (o sistema que recebe mensagens para [email protected]). Não tem nada a ver com correio para qualquer subdomínio. Cada subdomínio é um domínio de correio por si só.
  • Como você configura a reescrita de endereço depende de você. A única coisa que o mundo exterior vê é o resultado final. Então, por que se preocupar em fazer isso em duas etapas?

informação relacionada