Não estou recebendo e-mails de alguns remetentes devido à configuração do DNS

Percebi um comportamento peculiar do meu domínio do Google Apps. A maioria dos e-mails é enviada como seria de esperar, mas, ao longo de um período, concluí que os e-mails de determinados remetentes não são enviados. Depois de identificar um desses remetentes, cujos e-mails não chegariam, pedi a ele que tentasse me enviar um e-mail e encaminhar a resposta de "falha na entrega" ao meu gmail comum.

A resposta de falha na entrega continha o seguinte trecho:

----- Transcrição da sessão a seguir -----
<myusername@GHS.L.GOOGLE.COM>... Adiada: a conexão atingiu o tempo limite com ghs.l.google.com.

Isso me ajudou a identificar o problema, fazendo uma pesquisa rápida que me levou a esta página no Fórum de Ajuda do Google Apps. Na verdade, verifiquei o registro DNS do meu domínio e @fui definido como ghs.google.com. (CNAME), que não deveria ser. Alterar isso para @ 74.125.93.121 (A)* resolveu o problema.

Entendo que, nos casos em que o email não chegasse, meu nome de domínio foi substituído por seu nome canônico por meio de uma pesquisa CNAME; portanto, o email foi enviado para e myusername@ghs.l.google.comnão para myusername@mydomain.com. Mas por que funcionou para a grande maioria dos remetentes? Os remetentes cujos emails não chegaram, usaram algum tipo diferente de protocolo de email, algumas configurações estranhas de DNS ou o que poderia ser?

Pelo que pude ver pesquisando o problema no google, esse parece ser um problema amplamente difundido (muitas pessoas reclamando de e-mails do battle.net não sendo publicados, seria um exemplo popular), apenas que as pessoas não parecem estar ciente de que o problema está em suas próprias configurações de DNS, e não no lado dos remetentes.

Então, como isso pode ser explicado?

^{* Eu usei esse IP por causa do que li aqui , mas acho que qualquer IP faria o truque. alguém pode confirmar isso? Observe que a simples remoção do @registro não resolveu o problema, ele precisou ser alterado.}

No RFC 2821 "Protocolo Simples de Transferência de Correio", seção 5 "Resolução de Endereço e Tratamento de Correio":

A pesquisa tenta primeiro localizar um registro MX associado ao nome. Se um registro CNAME for encontrado, o nome resultante será processado como se fosse o nome inicial.

Em geral, é assim que os CNAMEs funcionam. Eles são frequentemente mal utilizados, mal compreendidos e mal implementados. :-)

Se o seu domínio for example.com, você provavelmente já possui registros MX apontando para os hosts habituais do Google Apps.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Parece que você também teve uma entrada como esta:

example.com. CNAME ghs.l.google.com.

A RFC 1034 "Conceitos e Instalações de Domínio" declara na seção 3.6.2 "Aliases e nomes canônicos" que recomenda esta configuração:

Se um RR CNAME estiver presente em um nó, nenhum outro dado deverá estar presente; isso garante que os dados para um nome canônico e seus aliases não possam ser diferentes.

No caso do erro que você colou, o servidor de email e / ou o servidor DNS no final do envio tentaram procurar registros MX para o seu domínio, example.com, e encontraram um CNAME apontando para ghs.l.google. com. Em seguida, tentou procurar o (s) registro (s) MX de ghs.l.google.com. No momento, como esse domínio não possui nenhum registro MX, o servidor de e-mail teria caído no registro A para ghs.l.google.com. Como o endereço IP não estava escutando na porta SMTP, o resultado foi o erro "A conexão expirou com ghs.l.google.com".

Ao remover o registro CNAME, você corrigiu seus problemas de email. Você pode encontrar problemas se o endereço IP definido em seu lugar for alterado no final do Google.

Você pode definir o cname para www.example.com:

www.example.com. CNAME ghs.l.google.com.

E execute um pequeno servidor da Web em qualquer IP que você aponte para example.com, o que simplesmente redireciona HTTP para http://www.example.com/

É algo surpreendente que funcionou tão bem quanto funcionou. A lei de Postel recebe algum crédito lá, acredito. :-)

De volta à RFC 1034 2.6.2:

Os RRs de CNAME causam ações especiais no software DNS. Quando um servidor de nomes falha em encontrar um RR desejado no conjunto de recursos associado ao nome do domínio, ele verifica se o conjunto de recursos consiste em um registro CNAME com uma classe correspondente. Nesse caso, o servidor de nomes inclui o registro CNAME na resposta e reinicia a consulta no nome de domínio especificado no campo de dados do registro CNAME. A única exceção a essa regra é que as consultas que correspondem ao tipo CNAME não são reiniciadas.

Portanto, nesse caso, pode-se argumentar que o servidor DNS deve / não deve seguir o CNAME em uma pesquisa MX, a menos que não tenham sido encontrados registros MX.

Ao enviar e-mail, o Sendmail e o qmail (e provavelmente outros) tentarão reescrever qualquer CNAME usado no lado direito de um endereço de e-mail no nome canônico.

De fato, alguns sites confiaram nesse comportamento. djb detalha por que ele acha que as pessoas deveriam parar de confiar nele no documento "CNAME records in mail" .

O @símbolo em um registro BIND é apenas uma maneira abreviada de escrever o domínio. Se você estiver criando um registro para example.com, então @é apenas um alias para example.com. Dizer que o @registro tinha que ser um IP é uma declaração que está faltando informações críticas - você não nos disse que tipo de registro era.

Pelo relatório de entrega, parece que você talvez tenha feito algo com o DNS para fazer com que o servidor de correio remoto reescreva seu domínio em ghs.l.google.com - muito estranho (PS, um registro A deve ser um IP, um registro CNAME não deve ser um IP ou outro registro CNAME).

Por que o servidor de mensagens dessa pessoa está reescrevendo seu endereço é estranho - não deveria, a menos que essa pessoa tenha feito algo para explicitamente dizer para reescrevê-lo. Também não deve se importar qual é o IP do seu domínio, a menos que não seja possível encontrar nenhum registro MX, pois os registros MX são como os servidores de correio descobrem para onde o correio vai.

Parece-me que, dadas as poucas informações fornecidas, você não seguiu as instruções do google sobre como configurar corretamente seu DNS para email. Você provavelmente ainda tem alguns erros no seu arquivo de zona - faça com que sejam verificados por um administrador de zona competente.