O postfix parece ignorar os registros MX do domínio

Question

No meu servidor dedicado, eu tenho o Postfix instalado para enviar e-mails através dos sites. Um dos meus clientes hospeda seus e-mails com terceiros para que os registros MX sejam configurados no domínio.

No entanto, ao enviar emails do Postfix do servidor, eles não recebem os emails. Eu acho que desde que o domínio está apontando para o próprio servidor, ele tenta enviar email para si mesmo, mas não há nada no servidor para manipular o email para esse domínio. (Existem contas de e-mail para outro domínio que estão funcionando bem.)

Como faço para que o Postfix use os registros MX do domínio para enviar e-mail? O servidor é o Ubuntu 8.10 com a pilha LAMP padrão. Eu 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 Sistema de Entrega de E-mails, 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 registro 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

    

Answer 1

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, eu 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: - eu deveria deletar essa linha? - DisgruntledGoat ontem"

seguiu-o com:

"@ Devdas: Eu tentei excluir essa linha e reiniciar o Postfix, isso não resolve o problema, eu preciso alterar" maildrop "para outra coisa? - DisgruntledGoat ontem"

A resposta para sua primeira pergunta é "sim". Essa linha em /etc/postfix/transport estava forçando o maildelivery local (via maildrop) para o email destinado a condorproperties.co.uk. A remoção é mais apropriada. O problema é simplesmente reiniciar o postfix é insuficiente para aplicar a mudança.

O problema é que o mapa, conforme configurado no arquivo de configuração, é um hash: / etc / postfix / transport. O arquivo, / etc / postfix / transport é a versão legível do arquivo e deve ter um /etc/postfix/transport.db - o arquivo hashmap compilado. Você usa o postmap de comando para compilar a versão legível para humanos na versão com hash. O postfix verifica os tempos de modificação e deve estar reclamando em voz alta em seus arquivos de log que o /etc/postfix/transport.db está desatualizado. Tudo o que você precisa fazer é executar o postmap / etc / postfix / transport para que a alteração feita antes (removendo a linha com o condorproperties.co.uk) entre em vigor. Na verdade, eu não acredito que você tenha que fazer um recarregamento do postfix para que a mudança entre em vigor assim que você emitir o comando postmap, mas isso não daria certo.

Para encurtar a história, execute o postmap / etc / postfix / transport e, em seguida, recarregue o postfix.

Felicidades.

Btw, a grande pista em seus arquivos de log era esta linha: 6 de janeiro 18:06:52 localhost postfix / pipe [30497]: 0329D3F69: para =, relé = maildrop, atraso = 0,15, atrasos = 0,1 / 0/0 / 0,04, dsn = 5,1,1, status = devolvido (usuário desconhecido Saída de comando: Usuário inválido especificado.)

aviso, na metade, onde diz relé = maildrop?

    

Answer 2

Você pode colar o postconf -n aqui?

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

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

Qualquer servidor de e-mail terá a configuração local para substituir o DNS. Então, se o seu MTA não está olhando para o DNS, você tem o domínio em sua configuração local.

    

Answer 3

postfix segue os padrões e executa a resolução das entradas MX de um nome de domínio, para descobrir qual servidor entrar em contato ao lado para transmitir o e-mail.

• 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 de o servidor de nomes de domínio.

• Além disso, os nomes de domínio no servidor de destino podem não ser declarados como local , fazendo com que o servidor rejeite os emails (consulte os logs, por exemplo, /var/log/mail.log ) considerando o servidor de envio estar tentando retransmitir (spam) por meio desse servidor de destino ( mydestination in /etc/postfix/main.cf ).

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

    

Answer 4

Verifique também se você não tem nenhum transporte personalizado ou mapas de transporte definidos de alguma forma para o domínio remoto para o qual pretende enviar e-mails.