Sendmail: endereço do remetente rejeitado (domínio não encontrado)

Estou tendo problemas com o envio de email em nosso servidor da web. Alguns e-mails são enviados e entregues sem problemas (por exemplo, Gmail), enquanto outros são adiados com "Endereço do remetente rejeitado: domínio não encontrado"

Entendo que essa é uma medida de proteção contra spam, na qual é feita uma pesquisa no domínio de envio, mas nosso domínio possui registros MX:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
premiumconnect.co.za    mail exchanger = 10 za-smtp-2.mimecast.co.za.
premiumconnect.co.za    mail exchanger = 10 za-smtp-1.mimecast.co.za.

Authoritative answers can be found from:

(Como um aparte, por que não temos respostas autorizadas? Esse poderia ser o problema?)

Bem como um registro A:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   premiumconnect.co.za
Address: 196.28.97.202

Aqui estão os logs de um email específico que estava tentando ser enviado:

Feb  5 12:07:52 premiumconnect sm-mta[2411]: s15C7qYp002411: from=<bookings@premiumconnect.co.za>, size=3522, class=0, nrcpts=1, msgid=<52f22998c2680@premiumconnect.co.za>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Feb  5 12:07:52 premiumconnect sendmail[2410]: s15C7q0o002410: to=*****@tott.co.za, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=33324, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (s15C7qYp002411 Message accepted for delivery)
Feb  5 12:07:52 premiumconnect sm-mta[2413]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=123522, relay=antispam-vdc-01.gam.co.za. [41.0.5.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <bookings@debian70.vm>: Sender address rejected: Domain not found
Feb  5 12:07:53 premiumconnect sm-mta[2413]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=123522, relay=mx-filter-01.gam.co.za. [41.0.5.131], dsn=4.1.8, stat=Deferred: 450 4.1.8 <bookings@debian70.vm>: Sender address rejected: Domain not found
Feb  5 12:12:46 premiumconnect sm-mta[2479]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:04:54, xdelay=00:00:00, mailer=esmtp, pri=213522, relay=mx-filter-01.gam.co.za. [41.0.5.131], dsn=4.1.8, stat=Deferred: 450 4.1.8 <bookings@debian70.vm>: Sender address rejected: Domain not found
Feb  5 12:12:46 premiumconnect sm-mta[2479]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:04:54, xdelay=00:00:00, mailer=esmtp, pri=213522, relay=antispam-vdc-01.gam.co.za. [41.0.5.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <bookings@debian70.vm>: Sender address rejected: Domain not found

Tenho pouca experiência com o Sendmail (ou MTAs em geral), não tenho certeza de quais outras informações poderiam ser úteis.

— JonoCoetzee
fonte

Se você não está dando respostas com autoridade, você precisa ter certeza de que seu registro de domínio tem seus servidores NS listados ..

— NickW

Nossas forças de registradores de domínio a utilizar seus servidores de nome, não poderia mudar, se eu quisesse, infelizmente ...

— JonoCoetzee

Bem, se você for forçado a usar o deles, precisará garantir que os servidores NS estejam retornando os registros que VOCÊ deseja, e isso inclui um registro MX adequado. Verifique também se o seu ISP ou a sua empresa de hospedagem publica um registro RDNS adequado para o seu servidor de correio.

— 5114 NickW

Ok, os registros retornados acima estão corretos para o nosso domínio e o que é definido no NS autoritativo (no registrador), incluindo o registro MX que aponta para um servidor de correio externo. Além disso, o servidor de correio (definido no registro MX) é resolvido com uma pesquisa DNS reversa. No entanto, o domínio / servidor da web não tem certeza se isso afetaria as coisas?

— 21714 JonoCoetzee

Então, seus servidores da web estão retransmitindo através do seu servidor de correio? Essa seria a maneira mais simples de garantir que o e-mail que eles estão enviando vai passar por ..

— NickW

Respostas:

Este erro refere-se especificamente ao endereço 'de', não ao servidor de envio. Como tal, os registros MX não são relevantes e suas configurações do MTA provavelmente não são relevantes.

O problema é que você está enviando um email de "bookings@debian70.vm", que o destinatário determina corretamente não pode ser um endereço de email válido, pois o domínio debian70.vm não existe.

A solução dependerá de como exatamente você está gerando esses e-mails. Uma opção é especificar o endereço 'de' desejado em qualquer software que esteja gerando esses e-mails.

Por outro lado, parece que você não está especificando ativamente um endereço 'de', mas deixando o sistema gerar um. Nesse caso, a parte após o @ é definida com base no que o sistema pensa ser o seu nome de email. O Debian verifica '/ etc / mailname' para determinar isso e, se não encontrar nada, usa seu nome de domínio totalmente qualificado, que no seu caso é 'debian70.vm' - um nome válido apenas para a sua rede interna desde está no domínio de nível superior .vm.

Se você editar / etc / mailname (criando-o, se necessário) para dizer 'premiumconnect.co.za' (sem as aspas), provavelmente resolverá o seu problema.

Caso contrário, isso pode indicar que um MTA está gerando o endereço com base em alguma outra configuração, portanto, precisamos saber mais sobre sua configuração do MTA.

— Nye
fonte

Eu entendo isso, se você olhar para a primeira linha no log você verá que que a partir de endereço é definido: from=<bookings@premiumconnect.co.za>. Eu já tentei configurar o / etc / mailname. O que faria com que isso não funcionasse?

— JonoCoetzee

Testei novamente com o Gmail e os e-mails ainda estão chegando como bookings@debian70.vm? Reiniciei o serviço sendmail, mas nenhuma alteração.

— 21414 JonoCoetzee

Eu tenho Authentication-Warning: premiumconnect.co.za: www-data set sender to bookings@premiumconnect.co.za using -fno mail.log, isso pode estar relacionado?

— JonoCoetzee

Como é que ele resolve o domínio debian70.vm? Parece-me que você está usando bookings@debian70.vm como o endereço do remetente. A verificação de spam é feita no debian70.vm, que não pode ser resolvido.

— apedrejado
fonte

@slm Não. Essa é realmente a resposta imho. Para mim, ele está tentando enviar e-mail como bookings@debian70.vm, cujo domínio não pode ser resolvido pelo servidor remoto. Desculpe se não estiver claro, modificarei minha resposta.

— chapado

Stoned é certo, que é a questão principal .. um secundário pode ser por isso que o seu servidor de retransmissão está aceitando endereços assim :)

— NickW

@stoned - a edição melhora, removi o comentário, obrigado.

— Slm

@ NickW, na verdade, parece-me que ele está usando a máquina local (127.0.0.1) para enviar o e-mail, então funciona. Acho que ele não retransmitiu e-mails para qualquer lugar, ou então provavelmente receberia um e-mail de falha em vez de um log de erros. Se isso for verdade, ele terá problemas com verificadores de spam como o SpamAssassin, mas geralmente não receberá nenhum feedback por isso - a mensagem será descartada pelo servidor de e-mail do destinatário.

— chapado

Eu concordo, que é a razão por trás do meu último comentário sob sua pergunta :)

— NickW

Eu encontrei o problema, uma vez que fui apontado na direção certa pelas outras respostas. O sendmail.mc (gerado automaticamente) tinha uma linha MASQUERADE_AS(`debian70.vm')dnl, mudei para MASQUERADE_AS(`premiumconnect.co.za')dnle os emails estão sendo definidos corretamente agora. Obrigado pela compreensão.

— JonoCoetzee
fonte