servidores de correio e hospedagem web distintos com vários domínios; prevenção de spam, registros PTR e SPF

Question

Contexto.

Tenho vários serviços da web de domínios hospedados em um droplet do Digital Ocean (Ubuntu e Nginx na pilha). Aparentemente, o DO configura automaticamente um registro PTR. No entanto, quando eu pergunto

host <IP_ADDRESS>
[...] not found: 3(NXDOMAIN)

O droplet está usando postfix, configurado como where inet_interfaces = all inet_protocols=ipv4, enquanto mydestinationinclui os domínios de serviços da web hospedados (com e sem prefixo www). Esses domínios emitem e-mails por meio de sendmailum host definido comoscheduler.sending.ws

O DNS e o serviço de correio são executados por meio de um segundo provedor (que NÃO é o registrador de registro do domínio de segundo nível). Notei em primeiro lugar que um registro A está apontando para o endereço IP correto, mas com um erro de digitação schedule.sending.wsque pode ser corrigido, embora eu não tenha certeza de que isso seja totalmente pertinente.

O registro MX aponta corretamente para o segundo provedor. mail.sending.ws Existem também dois registros TXT para @e adminapontando para v=spf1 a mx ptr include:someserver.net ~all.

Isso faz com que e-mails sejam gerados com o seguinte cabeçalho com umaleatóriodomínio definido no mydestinationarquivo postfix main.cf:

Received: from www.other.ws ([IP_ADDRESS]:46818)

Assim, duas referências emissoras diferentes, situação que pode facilmente levar à sinalização como spam.

por favor, desculpe minha total confusão e a quebra do protocolo de fazer várias perguntas
Minha suposição atual é que:
a) uma nova entrada TXT DNS precisa ser definida para o domínio emissor, como: v=spf1 a mx include:scheduler.sending.ws include:someserver.net ~all?
b) se a) estiver correto, naturalmente o registro A precisa ser corrigido
c) a incompatibilidade nos cabeçalhos ainda precisa ser resolvida. Mas isso certamente deve ser especificado pelo aplicativo (e, portanto, pelo domínio específico) que prepara o e-mail com um dos domínios definidos pelo postfix... o postfix vai funcionar?

falta algum dado para resolver adequadamente esse problema?

Answer 1

Para a situação geral, você realmente deve seguir alguns tutoriais para fazer uma configuração básica funcional, em vez de tentar configurações aleatórias com compreensão inadequada de como o email funciona. Afinal, administrar um sistema de e-mail é uma tarefa complicada e desafiadora hoje em dia. Para qualquer pessoa sem grande experiência e necessidades especiais de servidor de e-mail próprio, é recomendado usar um serviço externo que tenha todos os sistemas de prevenção de spam necessários e tratamento de reputação do remetente pronto para uso.

Para responder às suas perguntas separadas e fornecer orientação para aprender as tecnologias por trás. Nesta resposta, vamos usar www.example.com. A 192.0.2.1como servidor web e mail.example.com. A 192.0.2.2como servidor de e-mail para mensagens recebidas. Ambos precisam enviar correspondência, mas só mail.example.comrecebem, certo?

• a) Não. O SPFincludemecanismonão é para esse fim. include:scheduler.example.comsignifica que existem mais regras, ou seja, outro registro SPF em scheduler.example.com. TXT. Como provavelmente não existe tal registro, isso causaria um PermError, possivelmente resultando na rejeição da mensagem.

  O registro SPF deve permitir todos os servidores que enviarão mensagens para o nome de host correspondente. Se você usar example.com, você está com ele example.com. TXT, por www.example.com.diante www.example.com. TXT. É recomendado usar oip4eip6mecanismos sempre que possível, pois requer menos consultas DNS ao verificar o SPF. Isso resultaria em:

  example.com.      IN TXT  "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all"
  www.example.com.  IN TXT  "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all"
  

• b) Para entrega de correspondência recebida, scheduler.example.com. Aé irrelevante, a menos que tenha sido usado comotrocador de correiopor exemplo example.com. MX scheduler.example.com., mas provavelmente só existe mail.example.com.se você usá-lo como HELOnome de host, você deve ter o Aregistro para evitarIncompatibilidade de banner SMTP.

• c) O HELOnome do host corresponde ao parâmetro de configuração do Postfixsmtpd_banner. Por padrão, ele tem omyhostnamecomo uma variável, ou seja, é a mesma que você tem myhostname. O mydestinationnão tem nada a ver com isso, e nada escolhe um nome de host aleatório nessa configuração: é para entregar mensagens, não para enviá-las.

  O HELOnome do host deve ter um Aregistro correspondente e é recomendado que seja o mesmo PTRdo endereço IP. Não precisa corresponder aoremetente do envelopedomínio nem o From:endereço do cabeçalho. Em um servidor de e-mail com vários domínios, isso também seria impossível.

Para problemas de integridade do domínio de e-mail, é recomendável usar o domínio real para que possamos verificar o que está acontecendo. Esta questão é ampla e inespecífica: é impossível dar uma resposta precisa ou geral.