DNS e PTR para SMTP: IPs e subdomínios compartilhados

Question

Esta questão é semelhante a outras sobre PTR e DNS para SMTP, mas um aspecto específico não foi respondido: e se uma máquina faz SMTP e HTTP no mesmo endereço IP. Por exemplo:

SMTP em mail.example.com, também HELO. (1.2.3.4) HTTP em www.example.com (1.2.3.4) acesso geral como ssh em example.com (1.2.3.4)

Quais são os requisitos para o registro PTR no endereço 1.2.3.4 ser aceito pelos filtros de spam? O hostname 'main' para 1.2.3.4 é example.com, mas se as pesquisas reversas de DNS exigirem uma correspondência exata, eu tenho que configurá-lo para mail.example.com. Isso é estupido. Quero dizer, as pesquisas reversas de 66.102.13.106 não resultam em mail.google.com.

Ou, será suficiente se uma pesquisa inversa encontrar example.com e mail.example.com como registro MX? Em outras palavras, devo definir o PTR para example.com?

Alguém poderia argumentar que eu deveria fazer o acesso SMTP e o HELO example.com, mas isso causa inflexibilidade, porque então eu nunca posso mover o SMTP para outra máquina simplesmente mudando o registro A.

Edit: parece claro o que quero dizer, então deixe-me esclarecer:

O servidor em questão hospeda DNS, SMTP, WWW e muito mais. Ele faz tudo do seu próprio DNS. Example.com aponta para essa máquina, digamos 1.2.3.4. Como o correio não é o principal, não quero que o 1.2.3.4 inverta a resolução para mail.example.com

O servidor executa o postfix e o seu HELO é mail.example.com, que também aponta para 1.2.3.4. Para que o PTR corresponda, o 1.2.3.4 deve reverter a resolução para mail.example.com, mas como eu disse, quero que ele seja resolvido para example.com, porque o correio não é a tarefa principal do servidor.

Isso significa que eu preciso alterar o nome do e-mail para exemplo.com, e tê-lo em mail.example.com fará com que alguns filtros de spam o rejeitem, mesmo que o e-mail seja um registro mx de example.com?

    

Answer 1

Os Serviços HTTP não precisam ter um registro PTR correspondente. O SMTP faz e deve sempre corresponder a uma resposta de resolução direta.

Seu registro A de um domínio não precisa corresponder a um registro MX, por exemplo:

@     IN A   1.2.3.4
      IN MX  10 mail
mail  IN A   1.2.3.5

é perfeitamente válido.

Por aplicativos de design, tente localizar o registro MX , mas, se ele não estiver definido, eles retornam ao registro A . Esta é a parte em que a flexibilidade como você chama vem para jogar. É um erro não definir seu registro MX se você for um SMTP válido.

Os filtros de spam na maior parte sempre deixam seu e-mail (ou atribuem um valor / tag de alto valor) se seu PTR não corresponder ao seu nome de host para o servidor smtp de saída. Você deve configurá-lo para mail.example.com se o seu MX se referir a mail.example.com.

Normalmente, o seu helo também deve se referir ao seu PTR / MX , pois este é outro teste para o seu servidor marcar um valor baixo em filtros de spam e não ser marcado como spam.

EDITADO:

Após a sua edição, não importa qual é o seu objetivo principal. O que importa é o que você precisa para não ter uma alta pontuação de spam no seu MX.

Dito isto, o seu MX não precisa apontar para mail.example.com, você poderia dizer:

@ IN A 1.2.3.4     EM MX example.com.

Esta é a sintaxe de vinculação e observe que example.com tem um ponto no final. Você poderia tentar isso se estiver desesperado e precisar registrar seu PTR como example.com e ser coerente com o HELO.

    

Answer 2

• Você pode ter quantos RRs como você quero apontar para 1.2.3.4.
• Você deve ter um ponto PTR de volta a um nome.
• Portanto, tudo que você precisa é fazer Certifique-se de que o PTR aponta para o nome você quer e que este nome aponta de volta para 1.2.3.4.

Isso significa que você pode ter:

example.com. EM A 1.2.3.4

example.com. EM MX 10 mail.example.com.

server.example.com. EM A 1.2.3.4

www.example.com. EM A 1.2.3.4

mail.example.com. EM A 1.2.3.4

e:

4.3.2.1.in-addr.arpa. IN PTR server.example.com.

Por que esse é o requisito? Porque quando o seu servidor SMTP se conecta a um servidor SMTP remoto para entregar e-mail o servidor SMTP conhece apenas o endereço do seu servidor e não o nome. Com o endereço em mãos (1.2.3.4), ele consulta o DNS e obtém a resposta PTR (server.example.com). O servidor remoto agora perguntará ao DNS novamente "qual é o endereço do server.example.com" e espera que a resposta seja 1.2.3.4.

O que você envia na seqüência HELO não deve assustá-lo. Você pode ler sobre o propósito do SMTP HELO e encontrar sobre as exceções onde é permitido bloquear com base no que é dado na string HELO.

    

Answer 3

Geralmente, você dissocia HTT de SMTP / Rede.

• Domínios para HTTP são adicionados conforme necessário. Tudo o que eles fazem é apontar para o servidor ou CNAME o nome do servidor e ter o cabeçalho do host correspondente configurado para o IIS.
• O servidor tem seu próprio nome de host, principalmente em um domínio hoster (server1.thehoster.com). Como na primeira resposta, www.customerdomain.com pode ser um CNAME para server1.thehoster.com
• Para SMTP, é importante que os ponteiros para frente e para trás sejam idênticos. Portanto, na Conexão SMTP, o servidor se identificará como server1.thehoster.com (APENAS UM NOME POSSÍVEL) e o registro PTR será resolvido para server1.thehoster.com. Os domínios usados para acesso à web não entram aqui.

Answer 4

Você não é obrigado a fornecer um registro MX para seu domínio. Se não houver um registro MX presente, um MTA deve usar o registro A do seu domínio para entregar mensagens.

Isso, no entanto, fará com que um número significativo de filtros de spam sinalize os e-mails originados em seu domínio como possível spam.

Portanto, mesmo que o e-mail não seja sua "tarefa principal", você provavelmente ainda deseja manter os filtros de spam felizes. Para conseguir isso, sua zona precisa se parecer com isso:

@                      IN A     1.2.3.4
                       IN MX 10 mail
mail                   IN A     1.2.3.4
1.2.3.4.in-addr.arpa.  IN PTR   mail