Seleziona una catena di dipendenze anziché un valore TXT
MTA-STS dipende dal rilevamento, da una policy HTTPS autenticata e dagli host di posta riceventi descritti da tale policy. UN registrazione TXT che sembra corretto può coesistere con un file di criteri irraggiungibile o un certificato MX che non corrisponde. Un utile controllore quindi segnala ogni fase separatamente e spiega quali conclusioni successive non è stato possibile raggiungere dopo un precedente fallimento.
Questa guida propone tale comportamento diagnostico senza fornire uno strumento EmailAuth funzionante. Non si è verificata alcuna ricerca DNS , recupero HTTPS rispetto a un dominio del cliente, connessione SMTP o modifica delle policy. L'esatta porta di implementazione è aperta: implementare e testare la funzione promessa. Un articolo, un modello o una specifica da soli non costituiscono uno strumento di lavoro.
Derivare l'individuazione dal dominio delle politiche del destinatario previsto
Iniziare con il dominio delle politiche da valutare e registrare il motivo per cui rientra nell'ambito. Il proprietario del rilevamento è _mta-sts seguito da quel dominio. In RFC 8461 , il rilevamento filtra per la versione supportata, richiede un record TXT corrispondente utilizzabile e accetta un CNAME percorso al valore TXT . Più stringhe di caratteri all'interno di un record TXT vengono concatenate senza spazi inseriti; più record corrispondenti sono un problema diverso.
Il campo id identifica una revisione della politica ma non ha un ordinamento numerico o cronologico implicito. Un controllo dovrebbe preservare l'identificatore esatto anziché presumere che una stringa dall'aspetto più grande sia più recente. L'assenza di un record di rilevamento utilizzabile non rimuove automaticamente una policy che un mittente ha già memorizzato nella cache. RFC 8461 , sezione 3.1.
Autenticare l'host della policy e controllare la risposta esatta
L'URL prescritto utilizza https, l'etichetta host mta-sts e /.well-known/mta-sts.txt. Per recipient.example immaginario, diventa https://mta-sts.recipient.example/.well-known/mta-sts.txt. Questa è un'illustrazione costruita, non una risorsa recuperata. Il certificato policy-host deve essere valido per quell'host, non scaduto e concatenato a una root attendibile dal mittente.
RFC 8461 richiede una risposta HTTP 200, proibisce di seguire reindirizzamenti HTTP e proibisce la memorizzazione nella cache HTTP per il recupero delle policy. Si consiglia di verificare il tipo di supporto testo/normale. Un controllore che segue un reindirizzamento alla home page di un sito Web e quindi segnala l'esito positivo ha valutato il comportamento sbagliato. Distinguere la risoluzione DNS , la connessione, il certificato, lo stato e gli errori di analisi delle policy. Un errore di certificato è un risultato da spiegare, non l'autorizzazione a ignorare un avviso di sicurezza. RFC 8461 , sezioni 3.2–3.3.
Tempo di recupero vincolato e dimensione della risposta. Un'implementazione lato server deve anche controllare le destinazioni in uscita in modo che un nome inviato non possa causare richieste a servizi interni o endpoint di metadati. Applica restrizioni di rete e convalida la destinazione effettiva, comprese le modifiche dell'indirizzo, anziché fare affidamento solo su un nome host amichevole. Questi sono requisiti di progettazione proposti, non difese implementate. Guida alla prevenzione OWASP SSRF.
Modalità di analisi, durata e ambito MX insieme
La policy dichiara versione, modalità, max_age e modelli MX consentiti, con i requisiti MX che dipendono dalla modalità della policy. Ciascuna voce MX consentita occupa la propria riga. Il valore max_age di una policy ne regola la durata nelle cache delle policy del mittente, non nel TTL DNS o in un'intestazione di controllo della cache HTTP. Visualizza questi concetti separati anziché chiamare tutti e tre i tempi di propagazione.
Confronta ciascun candidato MX rilevante con i modelli consentiti. RFC 8461 limita un carattere jolly all'intera etichetta più a sinistra: *.example corrisponde a mail.example ma non a example o abexample . Un ampio confronto visivo di sottostringhe non è quindi adatto. Conserva l'host candidato e il modello esatto che ha trovato corrispondenza o ha fallito. Un MX di backup legittimo omesso da una policy di applicazione può diventare un problema di disponibilità. RFC 8461 , sezioni 3.2 e 4.1.
Non confondere il certificato del sito web con la convalida SMTP
Il certificato della policy HTTPS autentica il recupero della policy. L' MX ricevente necessita separatamente STARTTLS e un certificato adatto per il proprio nome host. Il recupero riuscito del sito Web non dimostra la configurazione del server SMTP . Qualsiasi test attivo autorizzato successivo dovrebbe mantenere l'host scelto, il contesto di connessione, l'identità del certificato e il risultato di attendibilità, con l'ambito effettivo dello strumento dichiarato.
Un controllo che legge solo DNS e HTTPS dovrebbe segnalare la fase SMTP come non testata, non integra. Né il controllo di un candidato dimostra che ogni MX si comporta allo stesso modo. L'implementazione del mittente e gli archivi di fiducia influiscono sulle osservazioni, quindi un singolo vantaggio diagnostico non è una garanzia per ogni corrispondente. RFC 8461 , sezione 4.
Pianificare un passaggio controllato dai test all'applicazione
In modalità test, un mittente implementato può consegnare nonostante gli errori di convalida della politica, mentre i report TLS compatibili possono esporre tali errori. In modalità di applicazione, un mittente che rispetta una policy valida non deve consegnare a un candidato che non supera i controlli richiesti. Nessuna delle due modalità trasforma MTA-STS in SPF, DKIM O DMARC convalida; il meccanismo riguarda il trasporto SMTP .
Una transizione proposta dovrebbe avere un proprietario, una differenza di policy approvata, una copertura MX primaria e di backup verificata, la disponibilità del certificato e un periodo di osservazione definito. Esaminare i report TLS pertinenti e il comportamento effettivo del mittente prima di decidere se l'applicazione è accettabile. L'assenza di rapporti non costituisce prova di disponibilità. RFC 8461 , sezione 5 E RFC 8460.
La pianificazione del ripristino deve tenere conto delle policy precedentemente memorizzate nella cache. L'eliminazione del rilevamento o la riduzione di un nuovo max_age non può abbreviare istantaneamente una policy precedente già memorizzata nella cache. Conservare gli organi politici e le durate precedenti e pianificare un aggiornamento autorizzato anziché promettere un rollback immediato. Questa guida non esegue alcuna azione di transizione o ripristino.
Lasciare aperti la traccia effettiva e il gate utensile
Il catalogo richiede: Una traccia di convalida da DNS a HTTPS a MX e un piano di test controllato per l'applicazione. I controlli proposti sopra non sono quella traccia e non sono un controllo testato. Non è stata ottenuta alcuna prova ambientale o un piano di transizione approvato. Gli standard e le linee guida sulla sicurezza sono stati rivisti l'8 novembre 2026; La revisione tecnica indipendente, i test di implementazione, la convalida visiva dal vivo e l'approvazione della pubblicazione da parte del proprietario rimangono in sospeso.