O Postfix parece ignorar os registros MX do domínio

O Postfix parece ignorar os registros MX do domínio

No meu servidor dedicado, tenho o Postfix instalado para envio de e-mail pelos sites. Um de meus clientes hospeda seu e-mail com terceiros, portanto, temos registros MX configurados no domínio.

No entanto, ao enviar qualquer e-mail Postfix do servidor, eles não recebem os e-mails. Acho que como o domínio está apontando para o próprio servidor, ele tenta enviar mensagens para si mesmo, mas não há nada no servidor para lidar com o email desse domínio. (Existem contas de e-mail para outros domínios que estão funcionando bem.)

Como faço para que o Postfix use os registros MX do domínio para enviar emails?O servidor é Ubuntu 8.10 com pilha LAMP padrão. Tenho o Webmin instalado e um painel de controle chamado "Matrix" fornecido pelo host.

EDITAR: se eu tentar enviar e-mail do meu próprio endereço, recebo um e-mail de erro do Mail Delivery System, com este erro:

<[email protected]>: user unknown. Command output: Invalid user specified.

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Diagnostic-Code: x-unix; Invalid user specified.

Aqui estão as entradas de log feitas:

Jan  6 18:06:52 localhost postfix/pickup[29006]: 0329D3F69: uid=33 from=<[email protected]>
Jan  6 18:06:52 localhost postfix/cleanup[30495]: 0329D3F69: message-id=<[email protected]>
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 0329D3F69: from=<[email protected]>, size=611, nrcpt=2 (queue active)
Jan  6 18:06:52 localhost postfix/pipe[30497]: 0329D3F69: to=<[email protected]>, relay=maildrop, delay=0.15, delays=0.1/0/0/0.04, dsn=5.1.1, status=bounced (user unknown. Command output: Invalid user specified. )
Jan  6 18:06:52 localhost postfix/smtp[30498]: 0329D3F69: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[209.85.227.27]:25, delay=0.61, delays=0.1/0.01/0.06/0.45, dsn=2.0.0, status=sent (250 2.0.0 OK 1294337212 o18si30528441wbo.103)
Jan  6 18:06:52 localhost postfix/cleanup[30495]: 868723F75: message-id=<[email protected]>
Jan  6 18:06:52 localhost postfix/bounce[30500]: 0329D3F69: sender non-delivery notification: 868723F75
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 868723F75: from=<>, size=2553, nrcpt=1 (queue active)
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 0329D3F69: removed
Jan  6 18:06:52 localhost postfix/pipe[30497]: 868723F75: to=<[email protected]>, relay=maildrop, delay=0.06, delays=0.01/0/0/0.05, dsn=2.0.0, status=sent (delivered via maildrop service)
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 868723F75: removed

Responder1

Então, estou entediado no trabalho e pensei em mencionar o seguinte. Eu nunca usei este site antes, então, me perdoe.

Para uma das respostas, você comentou depois para dizer:

"OK, tenho virtual_mailbox_domains = $transport_maps e transport_maps = hash:/etc/postfix/transport. Dentro desse arquivo há uma linha que diz condorproperties.co.uk maildrop: - devo deletar essa linha? – DisgruntledGoat ontem"

então seguiu com:

"@Devdas: Tentei deletar essa linha e reiniciar o Postfix, isso não resolve o problema, preciso mudar "maildrop" para outra coisa? - DisgruntledGoat ontem"

A resposta à sua primeira pergunta é “sim”. Essa linha em /etc/postfix/transport estava forçando a entrega de correio local (via maildrop) para emails destinados a condorproperties.co.uk. Removê-lo é o mais apropriado. O problema é simplesmente reiniciar o postfix é insuficiente para aplicar a alteração.

O problema é que o mapa configurado no arquivo de configuração é um hash:/etc/postfix/transport. O arquivo /etc/postfix/transport é a versão legível por humanos do arquivo e deve ter um arquivo /etc/postfix/transport.db correspondente - o hashmap compilado - também. Você usa o comando postmap para compilar a versão legível por humanos na versão com hash. O Postfix verifica os tempos de modificação e deve reclamar em voz alta em seus arquivos de log que /etc/postfix/transport.db está desatualizado. Tudo que você precisa fazer é executar postmap /etc/postfix/transport para que a alteração que você fez antes (removendo a linha com condorproperties.co.uk) tenha efeito. Na verdade, não acredito que você precise recarregar o postfix para que a mudança entre em vigor depois de emitir o comando postmap, mas não faria mal.

Para encurtar a história, execute postmap /etc/postfix/transport e depois postfix reload.

Saúde.

A propósito, a grande pista em seus arquivos de log foi esta linha: 6 de janeiro 18:06:52 localhost postfix/pipe[30497]: 0329D3F69: to=, relay=maildrop, delay=0.15, delays=0.1/0/0/0.04, dsn=5.1.1, status=bounced (usuário desconhecido. Saída do comando: usuário inválido especificado. )

observe, no meio do caminho, onde diz relay=maildrop?

Responder2

Você pode colar postconf -n aqui?

Aposto que você tem mydomain.co.uk listado explicitamente em um de mydestination, virtual_mailbox_domains ou relay_domains com um transporte de maildrop.

ring0 tem a ideia certa, mas analisou a questão de forma errada, pelo que entendi. O objetivo é fazer com que o e-mail de um dos domínios do servidor vá para outro lugar, mas ele permanecerá no Postfix.

Qualquer servidor de e-mail terá DNS de substituição de configuração local. Portanto, se o seu MTA não estiver olhando para o DNS, você terá o domínio na sua configuração local.

Responder3

postfixsegue os padrões e realiza a resolução de entradas MX de um nome de domínio, a fim de saber qual servidor contatar em seguida para transmitir o email.

  • Você pode ter um problema devido ao TTL de um nome de domínio (zona), por exemplo, você atualizou as entradas MX em seu registrador, mas o TTL desse domínio faz com que a entrada resolvida anteriormente permaneça no cache do servidor de nomes de domínio.

  • Além disso, os nomes de domínio no servidor de destino não podem ser declarados comolocal, fazendo com que o servidor rejeite os e-mails (veja os logs, por exemplo /var/log/mail.log), considerando que o servidor de envio está tentando retransmitir (spam) através desse servidor de destino ( mydestinationin /etc/postfix/main.cf).

Tente dig +nocmd mydomain.tld mx +noall +answerter informações facilmente legíveis, incluindo TTL, dos domínios com os quais você tem preocupação.

Responder4

Verifique também se você não possui transportes personalizados ou mapas de transporte definidos de alguma forma para o domínio remoto para o qual pretende enviar mensagens.

informação relacionada