Un codice di stato avanzato è un indizio strutturato, non un rapporto completo sull'incidente. La sezione "5.7.1" può restringere l'indagine alla sicurezza o alla policy, ma non può identificare da sola il proprietario della policy, il percorso interessato o correggere la modifica della configurazione. Conserva la diagnostica completa accanto al codice durante la risoluzione dei problemi.
Leggi tutti e tre i componenti
RFC 3463 definisce codici di stato avanzati con componenti di classe, oggetto e dettaglio. La classe distingue il successo, il fallimento transitorio persistente e il fallimento permanente. Le categorie di argomenti distinguono aree quali indirizzamento, stato della casella di posta, routing e sicurezza o policy. Il dettaglio restringe la condizione all'interno di quell'argomento. La normale risposta SMTP a tre cifre rimane parte della prova. RFC 3463.
Non considerare il numero finale come un identificatore di errore globale. Il significato dipende dal codice avanzato completo e dalla registrazione applicabile o dalla documentazione del fornitore. Un sistema ricevente può anche restituire prosa utile senza un codice avanzato. Se le classi di base e quelle avanzate appaiono incoerenti, preserva i byte esatti e analizza il comportamento del provider anziché riscrivere silenziosamente il registro.
Separare le risposte SMTP dai rapporti di consegna
Durante una conversazione si verifica una risposta SMTP . Una notifica sullo stato della consegna può riportare i risultati in un secondo momento e può descrivere più destinatari. RFC 3464 definisce campi tra cui destinatario finale, azione, stato, MTA remoto e codice diagnostico. Leggere i blocchi per destinatario in modo indipendente; un fallimento non dimostra che tutti i destinatari abbiano fallito. RFC 3464 sezione 2.
Azione e Stato rispondono a domande diverse. Azione: fallita indica la segnalazione MTA ha interrotto i tentativi per quel destinatario. Stato: 4.2.2 può ancora descrivere la causa temporanea della casella di posta piena una volta esauriti i tentativi; non riuscito più uno stato 4.xx è valido in un DSN, non una risposta SMTP incoerente. Ad esempio, un articolo scaduto con questi campi non verrà ripristinato automaticamente semplicemente perché viene ripristinata la capacità. Controlla l'effettiva coda prima di autorizzare qualsiasi sostituzione. Vedere RFC 3464 sezione 2.3.3.
Un oggetto di rimbalzo leggibile dall'uomo è utile per il triage ma può omettere i campi decisivi. Ottenere il report leggibile dalla macchina o il registro di invio quando possibile. Mantenere il server di report separato dal server remoto e distinguere il timestamp di un report da quello del comando SMTP non riuscito.
Leggere un ipotetico blocco destinatario
Supponiamo che un log di invio registri RCPT TO per missing@example.test seguito da 550 5.1.1. Un blocco destinatario DSN illustrativo potrebbe contenere destinatario finale: rfc822; missing@example.test , Azione: non riuscita, Stato: 5.1.1, MTA remoto: dns; mx.example .test e codice diagnostico: smtp; 550 5.1.1 Nessun utente di questo tipo. Si tratta di valori di campo inventati, non di una transazione eseguita o di un report MIME completo.
L'azione non riuscita è definitiva per questo destinatario, mentre la diagnostica punta all'indirizzamento. Non stabilisce perché l'indirizzo non è disponibile o cosa è successo agli altri destinatari. Ottieni queste risposte dai propri blocchi e registri attendibili. Destinatario finale, Azione e Stato sono campi obbligatori per destinatario; L'MTA remoto e il codice diagnostico sono condizionali o facoltativi. La loro assenza non consente di inventare un host di rifiuto o un testo di errore.
Per dettagli registrati sconosciuti, consultare la corrente Registro di stato migliorato IANA e le specifiche citate, quindi la spiegazione attuale del fornitore. RFC 3463 fornisce la struttura, non un elenco esaustivo di ogni codice successivo.
Trasforma il codice in un'ipotesi verificabile
Per un codice di indirizzamento, confermare l'indirizzo previsto e il comportamento del sistema ricevente. Per un codice di routing, controllare l'hop successivo non riuscito e la configurazione del percorso. Per un codice di sicurezza o policy, identificare il requisito denominato e il relativo proprietario. Evitare di iniziare con una modifica DNS preferita e quindi interpretare ogni risposta come supporto per essa.
Registra un'ipotesi, le prove che prevede e il più piccolo test autorizzato. Un messaggio corretto dovrebbe essere confrontato con l'originale sul relativo percorso e classe di destinatario. Conservare un risultato contraddittorio come prova utile anziché forzarlo nella spiegazione originale. I pacchetti di escalation dovrebbero includere timestamp, risposta esatta, ambito interessato e modifiche già testate, con contenuto del messaggio e dati personali ridotti al minimo. Una ricerca del codice è l'inizio della diagnosi, non il suo completamento.
Costruisci un pacchetto di escalation utile
- Identità: conserva gli identificatori del messaggio e della coda, il destinatario della busta in errore e l'ambito interessato.
- Sequenza temporale: registrare l'invio, il tentativo fallito e segnalare l'arrivo separatamente.
- Diagnosi: include la risposta SMTP esatta, la fase di comando e i campi DSN per destinatario.
- Titolarità: distinguere il sistema di segnalazione dal sistema di rifiuto, con evidenza per ciascuno.
- Passaggio successivo: indicare una causa verificabile, il controllo più piccolo autorizzato ed eventuali prove contraddittorie. Ridurre al minimo i dati personali.