Un controllore del trasporto può scoprire un problema reale senza dimostrare la sicurezza di ogni messaggio inviato o ricevuto dalla tua organizzazione. La maggior parte dei controlli osserva un endpoint selezionato in un momento particolare utilizzando un risolutore e un metodo di convalida particolari. Un risultato difendibile quindi include la portata e la copertura mancante, non solo un badge.
Definire l'inventario del percorso di consegna
Riferimenti: RFC 8461 §3.4, RFC 8461 §5.1, RFC 7672 §2.2.
Elenca i domini dei destinatari, i nomi host MX , le priorità, gli indirizzi IPv4 e IPv6 , i gateway ospitati e i percorsi di failover. Nota se il test segue il routing MX ordinario o uno smart host configurato esplicitamente. Registrare l'implementazione del mittente e se supporta MTA-STS, DANE o una policy TLS obbligatoria locale. Diversi sistemi di invio possono prendere decisioni diverse per lo stesso dominio ricevente.
Quindi definire l'affermazione che ciascun assegno può supportare. Una richiesta HTTPS pubblica può stabilire la disponibilità delle policy da questo punto di vista. Una sonda TLS può osservare un certificato presentato su un indirizzo scelto. Una query DNS di convalida può fornire prove in merito DNSSEC stato in un modello di fiducia del risolutore specificato. Nessuno da solo dimostra che si tratti di un vero invio MTA utilizzato gli stessi dati e applicato la politica di consegna prevista.
Catturare lo stato piuttosto che solo i risultati
Riferimenti: RFC 8461 §3.3, RFC 8461 §4, RFC 7672 §3.
Per MTA-STS , conservare il record di rilevamento, i byte esatti della policy HTTPS, l'ora di recupero, la modalità, la durata e lo stato della cache del mittente. Per DANE , mantenere MX e TLSA risposte, stato di validazione e confronto di associazioni. Per ogni connessione SMTP , acquisisci l'host e l'IP selezionati, STARTTLS negoziazione, risultato della verifica tra pari e decisione di consegna. RFC 8461 sezioni 3–5, RFC 7672 sezioni 2–3.
Una sonda fallita dovrebbe registrare la sua fase di fallimento. Timeout DNS , timeout TCP, STARTTLS assente, errore di handshake e mancata corrispondenza del certificato non sono risultati intercambiabili. Inoltre, una stretta di mano riuscita non stabilisce che il mittente rifiuterà una futura connessione declassata. Includere casi negativi controllati quando autorizzati, soprattutto prima di consentire un rigoroso requisito di trasporto.
Superare un gap di copertura
In questo esempio di inventario sintetico, mx1.example.net ha percorsi IPv4 e IPv6 e mx2.example.net è un backup. Un'osservazione di esempio copre solo l'indirizzo IPv4 di mx1. L'inventario deve contrassegnare l' IPv6 e le rotte di backup come non testate anziché propagare il successo su tutte e tre. L'osservazione è esplicitamente sintetica e non ha alcuna pretesa di connessione reale.
Aggiungi una riga di accettazione lato mittente per un MTA di supporto utilizzando una policy di applicazione valida, un'altra con una cache vuota e un mittente compatibile con DANE con TLSA convalidato. Queste righe rimangono in sospeso finché non vengono acquisiti i log effettivi. Ciò rende utile il piano di accettazione senza presentare i risultati attesi come misurazioni. Consente inoltre a chi risponde agli incidenti di vedere se il percorso fallito è mai stato utilizzato.
Riconciliare report ed evidenze operative
Riferimenti: RFC 8460 §4.1, RFC 8460 §4.2.
TLS-RPT i report possono rivelare gli errori riscontrati dai mittenti partecipanti nel corso di un periodo di reporting, integrando le indagini puntuali. Il conteggio delle sessioni non corrisponde al conteggio dei messaggi univoci e la copertura non è universale. Un periodo di reporting tranquillo non dimostra che tutti i percorsi hanno avuto successo e ripetuti tentativi possono complicare le stime dell’impatto sul business. RFC 8460 sezione 4.4.
Conserva il risultato non elaborato, il timestamp, la versione dello strumento o il comando e la conclusione più ristretta che ne hai tratto. Ripetere il test dopo il rinnovo del certificato, la migrazione MX , le modifiche DNSSEC e gli aggiornamenti delle policy. Il pacchetto di revisione include sette trascrizioni di loopback conservate del 7 novembre 2026, con byte di certificato peer per le quattro sessioni che hanno raggiunto l'acquisizione del certificato. Coprono un client/server Python IPv4 locale su porte generate con input di policy e attendibilità esplicitamente configurati, non SMTP Internet, una catena di convalida DNSSEC , code MTA di produzione o conformità completa del profilo di certificato MTA-STS . Le sessioni storiche sono state esaminate ma non riprodotte qui. L'esempio Internet IPv4 , IPv6 e i percorsi di backup non sono stati testati; nessuno eredita un pass locale. Il modello di copertura offline appena eseguito verifica solo che un percorso sintetico osservato lasci non testati gli altri percorsi elencati. Acquisisci l'MTA previsto e le osservazioni di instradamento prima di richiedere la garanzia della distribuzione.