Nossa empresa tinha 4 domínios cujos e-mails e DNS eram hospedados por usintegration.com e, em seguida, transferimos a hospedagem de e-mail e DNS de 3 dos 4 domínios para uma nova empresa. Agora, os 3 domínios que foram movidosnão é possível enviar ou receber e-mails de e para o domínio que ainda resta no servidor antigo. Todas as outras funções de email funcionam bem para todos os 4 domínios. Não há devoluções, mensagens de erro ou e-mails presos na fila, e nenhuma evidência de que esses e-mails perdidos tenham chegado aos novos servidores.
A nova empresa de hospedagem (logixcom.com) confirma que está tudo bem e me garante que provavelmente é um arquivo de zona antigo que ainda permanece no servidor de nomes da Integração dos EUA e, portanto, os e-mails enviados da Integração dos EUA são roteados para o que ela acredita que ainda é o servidor de nomes oficial (é próprio). Como os registros MX do arquivo de zona antigo ainda contêm o recurso antigo, as solicitações nunca deixam o servidor de nomes antigo para ficar on-line para fazer uma nova pesquisa pelo (novo) servidor de nomes oficial real. O problema agravado é que a Integração dos EUA não é capaz de identificar o problema, muito menos de resolvê-lo.
O problema é realmente que esse arquivo de zona antigo só precisa ser excluído do servidor de nomes da US Integration? Em caso afirmativo, qual é a melhor maneira de descrever isso para eles? Se não, qual você acha que poderia ser o problema? Qualquer ajuda é muito apreciada. Não estou em TI, então tudo isso é novo para mim. Eu sei que parece estranho para mim (o cliente) ter que fazer esse trabalho braçal, mas só quero resolver isso.
Aqui está o que eu fiz:
Executei a escavação para verificar se os registros MX da US Integration ainda apontam para o antigo servidor de nomes oficial, em vez de ficar on-line para fazer uma nova pesquisa:
~$ dig @bart.usintegration.com courycollection.com mx ; <<>> DiG 9.6.0-APPLE-P2 <<>> @bart.usintegration.com courycollection.com mx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61227 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;courycollection.com. IN MX ;; ANSWER SECTION: courycollection.com. 3600 IN MX 10 mail.usintegration.com. ;; ADDITIONAL SECTION: mail.usintegration.com. 3600 IN A 65.198.191.5 ;; Query time: 29 msec ;; SERVER: 65.198.191.5#53(65.198.191.5) ;; WHEN: Sun Dec 26 16:59:22 2010 ;; MSG SIZE rcvd: 88Executei uma pesquisa para tentar ver onde os servidores Logix olham quando e-mails são enviados dos 3 domínios que foram movidos e foram recusados:
~$ dig @faith.logixcom.net.net colcordhotel.com mx ; <<>> DiG 9.6.0-APPLE-P2 <<>> @faith.logixcom.net colcordhotel.com mx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31599 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;colcordhotel.com. IN MX ;; Query time: 31 msec ;; SERVER: 216.201.128.10#53(216.201.128.10) ;; WHEN: Sun Dec 26 17:00:14 2010 ;; MSG SIZE rcvd: 34
ATUALIZAÇÃO 28/12/10:A US Integration disse que excluiu os arquivos de zona, e a escavação subsequente mostra que seus resolvedores agora estão apontando para o servidor de nomes Logix correto, mas os problemas persistem. O engraçado é que o proprietário da US Integration (que tem um e-mail @usintegration.com) pode enviar e-mails comigo (que tem um e-mail @courycollection.com), mas nossa propriedade irmã (colcordhotel.com que é hospedada pela US Integration ) ainda não pode enviar para nós.
Responder1
Os domínios antigos foram totalmente removidos do antigo servidor de e-mail? Em muitos servidores de correio, se um domínio for definido como um nome servido por esse servidor, ele nem sequer procurará no DNS para ver onde o correio deve ser entregue (uma vez que já hospeda esse domínio, não há necessidade de procurá-lo). Os e-mails de old-domain.com para other-domains.com seriam entregues localmente se ainda estivessem configurados no servidor de e-mail, independentemente do que o DNS diga para fazer com ele.
Quanto ao correio recebido, também pode estar relacionado. Se o servidor receptor vir mensagens chegando da Internet em domínios que deveriam ser locais (ou seja, SMTP de entrada sem qualquer tipo de autenticação ou de um intervalo de IP conhecido), ele poderá tratá-las como suspeitas e filtrá-las como spam.
Esse tipo de coisa também é mais fácil de diagnosticar quando domínios reais são usados. Os domínios de exemplo são ótimos para problemas teóricos ou genéricos, mas os específicos funcionam muito melhor para problemas específicos.