MTA-STS la memorizzazione nella cache delle policy non è la normale memorizzazione nella cache del browser. Il valore max_age della policy ne determina la durata a partire dall'ultimo recupero riuscito. Il discovery TXT ha il proprio DNS TTL. Tali orologi possono differire sostanzialmente e spiegare perché due mittenti applicano contemporaneamente versioni di policy diverse.
Registra la policy che un mittente potrebbe ancora mantenere
Riferimenti: RFC 8461 §3.2, RFC 8461 §3.3.
Conserva ciascun corpo della policy pubblicato, ID di rilevamento, ora di pubblicazione e max_age. Uno screenshot dell'endpoint corrente non può dirti cosa ha recuperato un mittente ieri. Durante un incidente, chiedi la policy applicata e recupera l'ora dai log del mittente, ove disponibile, invece di dare per scontato che il corpo più recente sia universale.
RFC 8461 afferma che i mittenti dovrebbero memorizzare nella cache una policy fino a max_age e dovrebbero aggiornarla in modo proattivo prima della scadenza, suggerendo un aggiornamento giornaliero. Queste raccomandazioni non sono una garanzia di aggiornamenti sincronizzati. Le implementazioni possono verificare la presenza di aggiornamenti in momenti diversi e un mittente può continuare ad applicare una policy memorizzata nella cache valida quando il rilevamento o il recupero in tempo reale non riescono.
Separa i due calcoli della scadenza
Riferimenti: RFC 8461 §3.2, RFC 8461 §5.1.
In un dispositivo aritmetico etichettato, una policy recuperata all'epoca 1000000 con max_age 86400 ha un limite di scadenza di 1086400. Un TTL DNS di 300 non modifica tale calcolo. Se l'operatore pubblica un nuovo corpo con max_age 3600, il vecchio corpo già memorizzato nella cache non acquisisce retroattivamente la nuova durata.
Il nuovo dispositivo offline delimitato calcola quel confine. Il registro storico del laboratorio di trasporto conservato documenta inoltre una copia approfondita della vecchia cache, un recupero della politica di breve durata e un'affermazione che la vecchia istantanea e la sua scadenza rimangono invariate fino alla sostituzione esplicita. La porzione di cache è un modello di stato/aritmetico esplicito, non reale MTA, cache DNS o pianificazione dell'aggiornamento; gli scambi DNS /HTTPS di loopback conservati separatamente non ampliano tale richiesta di cache. Per estendere il test, configura un mittente controllato con una policy cache ispezionabile e conserva i suoi registri effettivi di recupero, aggiornamento e consegna.
Aggiorna nell'ordine sicuro
Riferimenti: RFC 8461 §8.1, RFC 8461 §8.2.
Pubblica il nuovo corpo HTTPS, verificalo, quindi modifica l'ID DNS . RFC 8461 consiglia di mantenere le vecchie policy compatibili con la consegna mentre entrambi gli endpoint si aggiornano e il TXT TTL passa. Per le modifiche di routing pianificate, consentire anche ai mittenti che mantengono la vecchia policy fino al termine della sua durata o fino a quando non si verifica un aggiornamento riuscito.
Mantieni la memorizzazione nella cache delle policy del protocollo distinta dalla cache di origine di una CDN. I mittenti non devono utilizzare la memorizzazione nella cache HTTP per il recupero dei criteri. RFC 8461 §8.2 consente tuttavia la memorizzazione nella cache del proxy inverso sul lato origine; verificarne l'aggiornamento e il comportamento di pubblicazione anziché considerare ogni cache proxy come vietata. Verifica il corpo effettivo dall'endpoint pubblico e assicurati che il flusso di lavoro della pubblicazione di hosting esponga la revisione prevista.
Diagnosticare un cambiamento ritardato senza tirare a indovinare
Riferimenti: RFC 8461 §3.3.
Confronta le risposte DNS , i byte di risposta HTTPS, i metadati dei criteri memorizzati nella cache e i registri degli errori del mittente. Un nuovo ID con un vecchio corpo suggerisce l'ordine di pubblicazione o l'hosting di problemi di freschezza. Un vecchio ID in una risposta ricorsiva può riflettere lo stato della cache DNS . È possibile prevedere il comportamento del protocollo di una policy memorizzata nella cache vecchia ma valida durante un'interruzione del recupero.
Non dichiarare che ogni ritardo sia propagazione. Identifica quale cache o dipendenza mantiene il vecchio stato, ripara quel componente e mantieni un percorso di ricezione conforme durante tutta la transizione. Per questo articolo non è stato eseguito alcun esperimento sulla cache del mittente attivo.
Conservazione delle prove storiche e ambito rimanente
Quanto segue descrive le osservazioni conservate del 7 novembre 2026, non un esperimento di rete ripetuto per questa recensione. I controlli offline appena eseguiti vengono registrati separatamente.
Il dispositivo della cache logica catturato conserva A1 recuperato a 1000000 con scadenza 1086400. Il laboratorio pubblica B2, annuncia B2 tramite una risposta DNS UDP effettiva e recupera B2 su HTTPS con max_age 3600. Quindi afferma che uno snapshot A1 copiato in profondità equivale ancora al suo contenuto originale e conserva la scadenza 1086400. Un registro separato dell'ultimo servizio calcola la scadenza massima possibile A1 come 1000300 + 86400 = 1086700, successiva a B2 a 1000600 + 3600 = 1004200 e C3 a 1000900 + 3600 = 1004500. I valori di scadenza vengono emessi calcoli utilizzando tempi logici espliciti; il confronto di conservazione della cache è un'asserzione eseguita. Né è un'emulazione di un programmatore di aggiornamento MTA. La scelta effettiva del mittente di aggiornare, riprovare o conservare lo stato rimane un test di implementazione.