Trate a primeira resposta como evidência
Um MTA-STS a política pode parecer disponível em um navegador enquanto um servidor de envio compatível rejeita sua recuperação. Os navegadores geralmente seguem redirecionamentos, carregam cookies e renderizam páginas de aplicativos. Em vez disso, a recuperação de política tem um contrato restrito: o host e o caminho HTTPS prescritos, um certificado válido, uma resposta 200 e uma política analisável. Diagnosticar a primeira camada com falha antes de alterar DNS ou enfraquecer a proteção do transporte.
Nenhum endpoint do cliente foi contatado para este guia. Os cenários são fictícios e o procedimento de captura é proposto. Um incidente real ainda precisa de um rastreamento de conexão com carimbo de data/hora identificando o alvo, o resultado da validação do certificado, a resposta HTTP e o corpo retornado. Retenha as falhas, bem como as tentativas bem-sucedidas, para que uma melhoria posterior não apague a causa.
Separe a falha de conexão da falha de HTTP
Por example.com , o destino de recuperação é https://mta-sts.example.com/.well-known/mta-sts.txt. A resolução de nomes e a conexão de rede precedem a autenticação TLS ; O processamento HTTP segue um handshake bem-sucedido. Endereço inacessível, erro de certificado, HTTP 404 e corpo inválido são observações diferentes. Uma ferramenta que relata todos eles como “falha na busca” precisa de sua saída detalhada antes que o operador possa atribuir o problema. Seções 3.2–3.3 RFC 8461
Identifique o nome do host usado para validação do certificado, não apenas o endereço final. Uma hospedagem CNAME não substitui a identidade do host de política necessária pelo nome do provedor. A cadeia apresentada deve levar a uma raiz confiável para o remetente e o certificado não deve estar expirado. Nunca desative as verificações de certificado para produzir um resultado de prontidão aprovado. Uma inspeção deliberadamente não validadora, se aprovada separadamente, seria uma prova diferente. Seções 3.3 e 8.2 RFC 8461
Interprete códigos de status sem atalhos do navegador
RFC 8461 aceita uma política buscada apenas com HTTP 200 e proíbe os seguintes redirecionamentos HTTP 3xx. Portanto, um 301 para um endereço de provedor, 302 para uma página de login ou 307 adicionado por uma estrutura da Web não é uma busca de política bem-sucedida. Um 304 também está fora da resposta 200 exigida e o envio de MTAs não deve usar cache HTTP comum para essa recuperação. O cache de política MTA-STS é um mecanismo separado. RFC 8461 seção 3.3
A semântica do status HTTP ajuda a atribuir o reparo: 404 indica que a origem não encontrou uma representação atual ou não está disposta a divulgá-la; 403 recusa cumprimento; 503 indica indisponibilidade temporária do serviço. Esses status identificam um resultado HTTP, não a configuração exata do servidor web responsável. Preserve os cabeçalhos de resposta e a revisão de implantação e, em seguida, peça à equipe de hospedagem responsável para comparar o roteamento, os controles de acesso e a disponibilidade upstream. Seção 15 RFC 9110
Verifique o corpo após uma resposta bem-sucedida
Uma resposta 200 é necessária, mas insuficiente. Inspecione se o corpo contém os campos MTA-STS e se o tipo de mídia é texto/simples, que os remetentes devem validar. Um shell de aplicativo, desafio anti-bot ou página de erro personalizada pode levar o status 200 enquanto falha na análise de política. Registre o tipo de conteúdo, comprimento de bytes e uma cópia inalterada da resposta; não cole apenas as linhas que parecem válidas. RFC 8461 seção 3.2
Os buscadores de políticas podem impor limites de tempo e tamanho. A especificação sugere um tempo limite de um minuto e um corpo máximo de 64 kilobytes, em vez de garantir que cada implementação use esses limites exatos. A inicialização lenta do aplicativo ou uma resposta inesperadamente grande podem, portanto, explicar resultados diferentes entre remetentes. Um recurso pequeno e servido de forma consistente reduz essas dependências, mas a arquitetura de serviço real continua sendo uma decisão do proprietário. RFC 8461 seção 3.3
Siga um incidente de redirecionamento fictício
Imagine uma migração de hospedagem fictícia em que o URL da política original retorna 301 com um Local apontando para um nome de host de propriedade do provedor. Um navegador de desktop o segue e exibe uma política de teste correta. Um remetente de suporte relata erro de busca de política sts. O redirecionamento e o relatório foram inventados para este exemplo; nem é uma observação do cliente.
O direto 301 já é suficiente para explicar por que a recuperação original falha no requisito HTTP MTA-STS , mesmo que o texto de destino esteja correto. Uma correção proposta serviria a política diretamente no URL original, potencialmente através de um proxy reverso configurado corretamente. Esse serviço original ainda deve ser autenticado como mta-sts.example.com . Não substitua o requisito por permissão para seguir redirecionamentos e não altere um ID de descoberta apenas para ocultar uma falha de hospedagem. Seções 3.3 e 8.2 RFC 8461
Explique por que os remetentes podem divergir
Um remetente que mantém uma política de aplicação em cache válida deve continuar a aplicá-la quando a atualização falhar. Um remetente sem uma política de cache válida e incapaz de buscá-la continua sem proteção MTA-STS . Uma interrupção na hospedagem, portanto, não significa que todos os remetentes interrompam imediatamente o correio, nem que todos os remetentes permaneçam protegidos. Diagnosticar o estado do cache e outras políticas aplicáveis separadamente da disponibilidade do site. RFC 8461 seção 3.3
Tentativas repetidas também podem ser limitadas. Após um GET malsucedido, os implementadores devem limitar tentativas adicionais a intervalos de cinco minutos ou mais por ID de versão. Conseqüentemente, um reparo pode preceder a próxima atualização visível bem-sucedida. Evite reivindicar recuperação instantânea após uma visita ao navegador; reter observações específicas do remetente e os horários de coleta relevantes. RFC 8461 seção 3.3
Encerre o incidente com as evidências certas
TLS-RPT separa erros de recuperação de política, conteúdo de política inválido e falhas de autenticação de política Web PKI. Use essas categorias para priorizar a investigação, mantendo os detalhes do repórter e reconhecendo que os rótulos por si só não identificam uma causa no servidor. Correlacione uma primeira resposta corrigida com relatórios subsequentes e o estado da política do remetente. Seção 4.3.2.2 RFC 8460
O pacote de conclusão deve mostrar o endpoint original autenticado, resposta direta 200, corpo analisável e escopo MX revisado. Evidências de hospedagem originais, rastreamentos de certificados de clientes e confirmação de recuperação de remetente permanecem ausentes aqui. As erratas atuais da RFC foram revisadas sem converter as propostas relatadas em correções normativas; a revisão independente e a autorização de publicação permanecem decisões separadas. Errata RFC 8461