Início / server / Perguntas / 1145110
Accepted
x-yuri
Asked: 2023-10-04 20:50:58 +0800 CST

HELO, MAILFROM e From devem usar o mesmo domínio?

  • 772

Eu configurei um servidor de e-mail algumas vezes antes e acredito que naquela época pensei que a resposta era “sim”.

Mas estou prestes a configurar outro e parece que me enganei. Digamos que o domínio apex ( example.com) e o (único) registro MX apontem para o mesmo servidor ( mail.example.com). Então posso fazer:

  • example.comaponte para o IP do servidor ( aa.aaa.aa.aaa) e aponte de volta (PTR) paraexample.com
  • um servidor de e-mail ( postfix, exim, ...) responde com example.com( HELO, MAILFROM)

Então os nomes dos registros SPF, DKIM e DMARC são: @, mail._domainkey(se o seletor for mail) e _dmarc. Ou, para resumir:

@  A  aa.aaa.aa.aaa
@  MX  10  mail
mail  A  aa.aaa.aa.aaa
aa.aaa.aa.aaa  PTR  @

@  TXT  (SPF)
mail._domainkey  TXT  (DKIM)
_dmarc  TXT  (DMARC)

Mas e se eu tiver 2 registros MX ( mail1e mail2)? Então não posso example.comapontar para 2 IPs diferentes e apontá-los de volta example.com, posso? Mas mesmo que eu consiga, posso ver que o Gmail não usa gmail.comfor HELO, MAILFROM. E parece mais sensato cada servidor responder com seu próprio nome, não é? Mas e aí, devo ter 2 registros SPF? Afinal:

a versão atual do SPF – chamada SPFv1 ou SPF Classic – protege o endereço do remetente do envelope

http://www.open-spf.org/Introduction/

@  A  (whatever)

@  MX  10  mail1
mail1  A  aa.aaa.aa.aaa
aa.aaa.aa.aaa  PTR  mail1

@  MX  20  mail2
mail2  A  bb.bbb.bb.bbb
bb.bbb.bb.bbb  PTR  mail2

mail1  TXT  (SPF)
mail2  TXT  (SPF)
mail._domainkey  TXT  (DKIM)
_dmarc  TXT  (DMARC)

Para ser franco, estou confuso depois de ler diversos artigos e respostas sobre como configurar um servidor de e-mail. Qual é a configuração correta ou melhor?

email

1 respostas

  1. Best Answer

    O nome do host HELO pode ser diferente do remetente

    O nome do host deve ter um & HELOcorrespondente , mas eles não precisam corresponder ao domínio usado nos cabeçalhos dos campos originadores RFC 5321 e RFC 5322 – nem mesmo compartilhar um domínio organizacional .APTR MAIL FROM From

    Por exemplo, mail1.example.com& mail2.example.compoderia muito bem enviar e-mail para example.com, example.net& example.org. Caso contrário, cada domínio precisaria de um endereço IP próprio com um PTRregistro correspondente. Pense na quantidade de domínios que os grandes provedores de serviços de e-mail estão gerenciando e eles certamente usam uma infraestrutura comum para todos eles.

    Os registros MX são para mensagens recebidas

    Os MXregistros não dizem respeito ao envio de correspondência, mas ao seu recebimento. No âmbito da sua pergunta não existe qualquer tipo de relação entre eles. O correio recebido pode ser tratado por um conjunto diferente de servidores. Por exemplo, boletins informativos de um domínio podem ser enviados usando SendGrid ou MailChimp enquanto o correio recebido é tratado pelo M365 ou Gmail.

    Origem das incompatibilidades HELO/DNS

    Usar HELO/ A/ PTRincompatibilidades como indicação de spam é comum, conforme descrito por, por exemplo, MXToolBox:

    • Verificação de banner SMTP :

      Alguns servidores de recebimento de e-mail podem usar um banner incompatível ou mascarado como indicação de uma possível fonte de spam em um sistema de pontuação, mas a maioria não rejeitará o e-mail recebido apenas com base nisso.

    • Incompatibilidade de DNS reverso SMTP :

      Alguns servidores de recebimento de e-mail podem usar isso como uma indicação de uma possível fonte de spam em um sistema de pontuação. A maioria não rejeitará a correspondência recebida apenas com base nisso. Recomendamos que você entre em contato com seu ISP e solicite a configuração de um registro reverso (PTR) que corresponda ao nome de host do seu servidor de e-mail.

    Esta prática provavelmente vem de uma interpretação da RFC 5321, 2.3.5 :

    O nome de domínio fornecido no EHLOcomando DEVE ser um nome de host primário (um nome de domínio que resolve um endereço RR) ou, se o host não tiver nome, um endereço literal, conforme descrito na Seção 4.1.3 e discutido mais detalhadamente no EHLOdiscussão da Seção 4.1.4 .

    No entanto, não é um requisito difícil, como define ainda o 4.1.4 , que:

    O cliente SMTP DEVE, se possível, garantir que o parâmetro de domínio para o EHLOcomando seja um nome de host primário conforme especificado para este comando na Seção 2.3.5 . Se isso não for possível (por exemplo, quando o endereço do cliente é atribuído dinamicamente e o cliente não tem um nome óbvio), um endereço literal DEVE ser substituído pelo nome de domínio.

    Um servidor SMTP PODE verificar se o argumento do nome de domínio no EHLO comando realmente corresponde ao endereço IP do cliente. No entanto, se a verificação falhar, o servidor NÃO DEVE recusar aceitar uma mensagem nessa base.

    Aqui, o protocolo SMTP parece seguir o princípio da robustez , ou seja, “seja conservador no que faz, seja liberal no que aceita dos outros”.

    FPS

    É obrigatório que as implementações do Sender Policy Framework (SPF) protejam a MAIL FROMidentidade ( RFC 7208, 2.4 ) e, opcionalmente, também podem proteger a HELOidentidade ( RFC 7208, 2.3 ):

    É RECOMENDADO que os verificadores SPF não apenas verifiquem a MAIL FROM identidade, mas também verifiquem separadamente a HELOidentidade, aplicando a check_host()função ( Seção 4 ) à HELOidentidade como o <sender>. A verificação HELOpromove a consistência dos resultados e pode reduzir o uso de recursos DNS. Se uma determinação conclusiva sobre a mensagem puder ser feita com base em uma verificação de HELO, então o uso de recursos DNS para processar mensagens normalmente mais complexas MAIL FROMpoderá ser evitado.

    Como isso é feito de forma independente, o SPF também não exige que sejam correspondentes.

    O SPF protege o nome do host de ser usado como remetente do envelope sem permissão e não é herdado pelos subdomínios. Portanto, você deve proteger todos os Aregistros que possui com um TXTregistro SPF correspondente – não apenas aqueles que você está usando para enviar e-mails.

    DMARC

    A Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio (DMARC) requer uma correspondência entre RFC5322.From e o Alinhamento de Identificador conforme definido em RFC 7439, 3.1 . Esses identificadores podem ser autenticados por DKIM (3.1.1 ) ou autenticados por SPF ( 3.1.2 ) e, dependendo do modo, podem exigir uma correspondência exata ou um domínio organizacional compartilhado ( 3.2 ). Ao contrário do SPF, o DMARC é herdado; uma política DMARC no ápice do domínio Fromtambém protege todos os subdomínios de serem usados ​​no cabeçalho.

    O alinhamento SPF requer correspondência MAIL FROM, mas o alinhamento DKIM não; é suficiente ter uma assinatura DKIM válida e autorizada com um identificador de domínio de assinatura correspondente (SDID) ( d=campo). Resumindo, nenhum deles requer um nome de host HELO/ correspondente EHLO.

    • 2

relate perguntas