Resumo

  • O id de um TXT MTA-STS avisa que o remetente deve buscar novamente a política. Ele não contém nem assina a política, não comprova que todos a buscaram e não revoga simultaneamente os caches anteriores. Para cada remetente compatível, vale um corpo específico obtido por HTTPS autenticado, com hora de obtenção conhecida e max_age ainda vigente.
  • Uma decisão reproduzível reúne descoberta do domínio, validação PKIX do host de política, bytes exatos, linhagem do cache, percurso dos MX, STARTTLS, certificado, estado da fila, novas tentativas e desfecho. enforce é uma regra de transporte para um MTA remetente, não prova de entrega, sigilo ponta a ponta, identidade da caixa postal ou autorização comercial.

Dois remetentes podem divergir sem que um esteja errado

A cena inicial é um teste construído, não o relato de uma ocorrência. O destinatário considera nova a política porque atualizou o TXT e o servidor web. O remetente A observa o novo id, autentica mta-sts.<domínio>, baixa o arquivo e inicia outro intervalo de cache. A lista que aplica já inclui o MX de contingência.

A atualização do remetente B falha. A RFC 8461 não manda descartar uma política anterior ainda válida quando a descoberta ao vivo está indisponível. Havendo cache não expirado, ele deve ser aplicado. Como o MX recém-resolvido não aparece ali, B rejeita esse candidato e adia a entrega.

O DNS e a página atuais do destinatário não bastam para auditar nenhuma das duas decisões. O objeto necessário é o estado que cada remetente possuía no instante da tentativa. A pergunta decisiva não é “qual é a política agora?”, mas “quais bytes autenticados este remetente tinha autoridade para aplicar nesta tentativa?”.

O ID anuncia mudança; não é a regra

O TXT em _mta-sts.<domínio-da-política> carrega v=STSv1 e um id. A mudança desse identificador provoca nova busca, mas ele não é o hash do arquivo HTTPS, não inclui a relação de MX e não funciona como revogação global. Observação do DNS e conclusão da busca acontecem em momentos distintos para cada remetente.

Sem cache válido, um TXT correto seguido de falha na obtenção HTTPS faz o remetente agir como se MTA-STS não estivesse implantado. Com cache válido, a mesma falha mantém a regra anterior em vigor. Portanto, “vi o ID novo” e “apliquei a política nova” são eventos diferentes, e a telemetria precisa preservá-los separadamente.

Antes de transformar uma falha sob enforce em definitiva, o remetente precisa verificar se há um ID atualizado. Fora disso, a falha permanece transitória e entra no ciclo de novas tentativas. Esse passo reduz o risco de devolver uma mensagem com base numa regra que o destinatário já substituiu.

HTTPS autentica um corpo determinado

O arquivo fica no host de política mta-sts.<domínio-da-política>, no caminho fixo /.well-known/mta-sts.txt. A identidade TLS é a desse host: a cadeia precisa chegar a uma raiz aceita pelo remetente, estar dentro da validade e conter um DNS-ID correspondente. A política traz version, mode, entradas mx e max_age; no modo none, a lista de MX pode faltar.

Para uma auditoria, “HTTPS funcionou” é insuficiente. É preciso reter URL, instante, status, tipo de conteúdo, bytes finais, cadeia do certificado, resultado do nome e hash do corpo analisado. Um arquivo alterado sob o mesmo id, ou um id alterado sem mudança de corpo, é uma divergência operacional que deve ser visível.

max_age cria vários presentes legítimos

O prazo começa na hora em que cada remetente conclui a obtenção, não na hora em que o destinatário publicou. Assim, os caches da mesma política expiram em momentos diferentes. Interferência numa atualização não invalida automaticamente uma cópia ainda vigente; por isso, a recomendação de renovar antes da expiração diminui a janela de exposição.

Uma remoção limpa também respeita essa sobreposição. O operador publica uma política autenticada em modo none com max_age curto, muda o ID e espera expirar a maior janela antiga antes de retirar TXT e endpoint HTTPS. Apagar primeiro os mecanismos de reparo pode deixar remetentes presos a um enforce antigo justamente quando já não existe caminho para substituí-lo.

O alvo validado é um MX numa conexão

Em enforce, o host candidato deve casar com uma entrada mx. Um curinga só cobre o rótulo completo mais à esquerda: não cobre o domínio raiz nem vários níveis. O remetente percorre a prioridade normal dos MX, tratando candidatos inválidos como temporariamente inalcançáveis. Um MX de contingência omitido pode permanecer invisível até o dia em que o primário falhar.

No host escolhido, STARTTLS deve estar disponível e o certificado PKIX, dentro da validade, precisa encadear até uma raiz aceita e corresponder ao nome do MX. O SNI da busca HTTPS contém o host da política; o SNI da sessão SMTP contém o MX selecionado. Misturar esses nomes numa investigação fabrica uma explicação que o protocolo não autoriza.

Passar por essas verificações demonstra apenas que um MTA conseguiu formar um caminho TLS aceito até um MX permitido naquela tentativa. Não demonstra que a mensagem chegou à caixa, permaneceu cifrada depois do próximo salto, foi lida pelo usuário certo, era segura ou autorizava pagamento, mudança de rota ou outra ação empresarial.

A fila dá consequência à política

Uma política só produz efeito observável quando encontra o estado da fila SMTP. Registre o identificador da fila, o MX tentado, a classificação transitória ou permanente, o cronograma de repetição, a verificação de ID antes da falha definitiva e o resultado final. Sem essa linha do tempo, um relatório mostra sintomas, não causalidade.

Canários úteis exercitam: novo ID com busca bem-sucedida; cache antigo ainda válido quando a atualização falha; cache expirado sem substituto; failover para MX de contingência; e retirada em modo none. O teste deve comparar o hash realmente aplicado, não apenas consultar a configuração atual do destinatário.

TLSRPT é testemunho agregado

A política _smtp._tls da RFC 8460 solicita relatórios que podem incluir políticas detectadas, contagens agregadas e amostras de falha. Isso ajuda o destinatário a distinguir erro benigno de interferência e a comparar regiões ou implementações de remetentes. Microsoft e Google documentam superfícies atuais de MTA-STS e relatórios em seus produtos, o que comprova interfaces declaradas desses produtos, não comportamento universal.

O relatório pertence ao produtor e ao intervalo nele descrito. A ausência de falhas pode significar tráfego protegido, cobertura incompleta ou nenhum tráfego relevante. Uma contagem agregada não é recibo de uma mensagem individual e não prova entrega, leitura ou sigilo. Preserve produtor, período, cobertura e detalhes amostrados antes de transformar o relato em decisão.

DANE e REQUIRETLS delimitam autoridades vizinhas

MTA-STS autentica a política por HTTPS e PKIX e não exige DNSSEC; por isso, sua descoberta inicial pode ser suprimida. DANE ancora outro limite de rebaixamento no DNSSEC. Uma validação DANE que falha não pode ser enfraquecida por um resultado MTA-STS mais conveniente.

REQUIRETLS, da RFC 8689, expressa intenção do originador por mensagem através de retransmissores compatíveis. MTA-STS expressa preferência do domínio destinatário para remetentes que o implementam. Nenhum dos dois deve herdar as afirmações do outro. Separar política de domínio, intenção por mensagem e prova da conexão impede que uma validação estreita seja promovida a autorização ampla.

Uma decisão que possa ser repetida

O registro mínimo correlaciona domínio da política; consulta TXT, resolvedor, TTL, estado DNSSEC e id; bytes e certificado da busca HTTPS; versão analisada, modo, MX, max_age, hash e expiração; hash e validade do cache anterior; RRset e prioridade dos MX; host, endereço, SNI, STARTTLS e resultado PKIX; fila, repetição e desfecho; resultado DANE aplicável; e testemunho TLSRPT.

Com isso, um terceiro pode reconstruir a autoridade realmente disponível em determinado instante. Sem isso, a investigação retrocede para o estado atual do DNS e confunde publicação recente com regra aplicada no passado.

Fontes