Eu corro um pequeno servidor web que hospeda um punhado de domínios que eu uso para fins pessoais e de teste. Também quero configurá-lo como um servidor de e-mail e estou tentando entender a pesquisa de rDNS que verifica o cabeçalho SMTP HELO.
O problema é que não tenho controle sobre os registros PTR do endereço IP do meu servidor e não há chance de o ISP delegar isso a mim. Digamos que meu endereço IP seja 123.45.67.89. Em seguida, o registro PTR para meu IP resolve para um nome de host como 123-045-067-089.customers.my-isp.net
.
TL;DR -- Estou tentando entender qual domínio rDNS está sendo procurado no cabeçalho SMTP HELO? É o nome de domínio do remetente do e-mail (por exemplo [email protected]
) ou o nome do host do servidor de troca de e-mail, mesmo que o servidor tenha um nome de domínio completamente diferente do remetente?
Se eu usasse o nome de host do ISP do meu endereço IP (por exemplo, 123-045-067-089.customers.my-isp.net
) como o cabeçalho HELO** para e-mails enviados de mydomain.com
, isso validaria os e-mails [email protected]
enviados pelo meu servidor de e-mail no endereço IP 123.45.67.89 ou o registro PTR de 123.45 .67.89 precisa resolver para mydomain.com
?
**Eu também poderia obter um certificado TLS para 123-045-067-089.customers.my-isp.net
, e ter o registro MX e o registro TXT-spf para mydomain.com
apontar para123-045-067-089.customers.my-isp.net
Versão longa:
Aqui está minha compreensão muito novata de como funciona a verificação SMTP HELO em relação ao rDNS. Digamos que meu domínio era mydomain.com
, e eu queria enviar um e-mail de [email protected]
para [email protected]
. Eu primeiro conectaria meu cliente de desktop ao meu servidor de e-mail. O servidor de correio (no endereço IP 123.45.67.89) se conectaria ao servidor de correio em gmail.com
. Nesse cenário, digamos que o cabeçalho HELO seja listado mydomain.com
como seu nome de domínio. Portanto, o servidor do Gmail faria uma pesquisa de rDNS no endereço IP do meu servidor, apenas para descobrir que 123.45.67.89 resolve para hostname 123-045-067-089.customers.my-isp.net
. Como isso não corresponde ao domínio fornecido no cabeçalho HELO, o servidor do Gmail assume que é spam e o rejeita.
Até agora tudo bem? Ou não?
Agora, vamos supor que, em vez de colocar mydomain.com
como cabeçalho SMTP HELO, meu servidor de e-mail coloque 123-045-067-089.customers.my-isp.net
e, além disso, tenha um certificado TLS para esse domínio assinado por uma CA estabelecida. Além disso, os registros MX e TXT-spf para mydomain.com
apontar 123-045-067-089.customers.my-isp.net
como o servidor de correio estabelecido.
(Nota: Não está claro para mim se o SMTP HELO também dita o domínio do e-mail do remetente???)
Neste segundo cenário, o e-mail enviado seria [email protected]
validado [email protected]
pelo servidor gmail e reconhecido como um e-mail legítimo? Ou ainda falharia porque 123-045-067-089.customers.my-isp.net
fornecido no HELO não corresponde ao remetente do e-mail mydomain.com
. (novamente ... não está claro para mim se isso é possível com o protocolo SMTP ... sou muito novo em servidores de e-mail)
É claro (isso nem é preciso dizer...) EU TENHO controle total sobre todos os registros de zona de encaminhamento de DNS para os domínios que possuo. Além disso, tenho um endereço IP estável de longo prazo e todos os meus domínios (e subdomínios) estão configurados para retornar ao meu endereço IP estabelecido.
Um servidor pode enviar e-mail para vários domínios diferentes, mesmo em uma conexão, que tenha apenas um HELO/EHLO. A partir disso, é muito fácil ver que o HELO/EHLO não pode se relacionar com nenhum e-mail específico, em vez disso, ele se relaciona com o servidor de e-mail, normalmente é algo que resolve o ip em que o servidor de e-mail está.
Tecnicamente, qualquer servidor de e-mail que receba um HELO/EHLO pode validar as informações da maneira que o servidor desejar e usar essas informações para validar qualquer outra coisa no e-mail. Mas normalmente você é bom se o valor após HELO/EHLO resolver para o ip em que seu servidor está, ou seja, rDNS para o ip normalmente não importa.