MTA-STS o cache de políticas não é o cache comum do navegador. O max_age da política rege seu tempo de vida a partir da última busca bem-sucedida. A descoberta TXT possui seu próprio DNS TTL. Esses relógios podem diferir substancialmente e explicar por que dois remetentes aplicam versões de políticas diferentes ao mesmo tempo.
Registre a política que um remetente ainda pode manter
Referências: RFC 8461 §3.2, RFC 8461 §3.3.
Mantenha cada corpo de política publicado, ID de descoberta, tempo de publicação e max_age. Uma captura de tela do endpoint atual não pode informar o que um remetente buscou ontem. Durante um incidente, solicite a política aplicada e busque o tempo nos registros do remetente, quando disponível, em vez de presumir que o órgão mais recente é universal.
RFC 8461 diz que os remetentes devem armazenar em cache uma política até max_age e devem atualizar proativamente antes da expiração, sugerindo uma atualização diária. Estas recomendações não são uma garantia de atualizações sincronizadas. As implementações podem verificar se há atualizações em momentos diferentes, e um remetente pode continuar aplicando uma política válida em cache quando a descoberta ou a busca em tempo real falhar.
Separe os dois cálculos de vencimento
Referências: RFC 8461 §3.2, RFC 8461 §5.1.
Em um dispositivo aritmético rotulado, uma política buscada na época 1000000 com max_age 86400 tem um limite de expiração de 1086400. Um DNS TTL de 300 não altera esse cálculo. Se o operador publicar um novo corpo com max_age 3600, o corpo antigo já armazenado em cache não adquirirá o novo tempo de vida retroativamente.
O novo fixture offline limitado calcula esse limite. O registro histórico do laboratório de transporte retido documenta adicionalmente uma cópia profunda do cache antigo, uma busca de política de vida mais curta e uma afirmação de que o instantâneo antigo e sua expiração permanecem inalterados até a substituição explícita. A parte do cache é um modelo de estado/aritmético explícito, não um modelo real. MTA, cache DNS ou agendador de atualização; as trocas DNS /HTTPS de loopback retidas separadamente não ampliam essa reivindicação de cache. Para estender o teste, configure um remetente controlado com um cache de política inspecionável e preserve seus logs reais de busca, atualização e entrega.
Atualizar na ordem segura
Referências: RFC 8461 §8.1, RFC 8461 §8.2.
Publique o novo corpo HTTPS, verifique-o e altere o ID DNS . RFC 8461 recomenda manter as políticas antigas compatíveis com a entrega enquanto ambos os endpoints são atualizados e o TXT TTL é aprovado. Para alterações de roteamento planejadas, permita também remetentes que retenham a política antiga até que seu tempo de vida termine ou ocorra uma atualização bem-sucedida.
Mantenha o cache de política de protocolo distinto do cache de origem de uma CDN. Os remetentes não devem usar cache HTTP para recuperação de políticas. No entanto, RFC 8461 §8.2 permite o cache de proxy reverso do lado da origem; verifique sua atualização e comportamento de publicação em vez de tratar todo cache de proxy como proibido. Verifique o corpo real do ponto final público e certifique-se de que o fluxo de trabalho de publicação de alojamento expõe a revisão pretendida.
Diagnosticar uma mudança atrasada sem adivinhar
Referências: RFC 8461 §3.3.
Compare respostas DNS , bytes de resposta HTTPS, metadados de política armazenados em cache e logs de falhas do remetente. Uma nova identidade com um corpo antigo sugere pedido de publicação ou problemas de atualização de hospedagem. Um ID antigo em uma resposta recursiva pode refletir o estado do cache DNS . Uma política em cache antiga, mas válida, durante uma interrupção de busca pode ser um comportamento de protocolo esperado.
Não declare todo atraso como propagação. Identifique qual cache ou dependência mantém o estado antigo, repare esse componente e mantenha um caminho de recebimento compatível durante toda a transição. Nenhum experimento de cache de remetente ativo foi executado para este artigo.
Evidências históricas retidas e escopo restante
O seguinte descreve observações preservadas de 7 de novembro de 2026, não um experimento de rede reexecutado para esta revisão. As verificações off-line recentemente executadas são registradas separadamente.
O dispositivo de cache lógico capturado preserva A1 buscado em 1000000 com expiração 1086400. O laboratório publica B2, anuncia B2 por meio de uma resposta DNS UDP real e busca B2 por HTTPS com max_age 3600. Em seguida, ele afirma que um instantâneo A1 copiado em profundidade ainda é igual ao seu conteúdo original e retém a expiração 1086400. Um razão último servido separado calcula o máximo possível expiração de A1 como 1000300 + 86400 = 1086700, posterior a B2 em 1000600 + 3600 = 1004200 e C3 em 1000900 + 3600 = 1004500. Os valores de expiração são cálculos emitidos usando tempos lógicos explícitos; a comparação de preservação de cache é uma afirmação executada. Nem é uma emulação de um agendador de atualização do MTA. A escolha real do remetente de atualizar, tentar novamente ou reter o estado permanece um teste de implementação.