UN SPF un incidente che appare limitato a una rete ricevente è un problema di confronto. Per prima cosa stabilisci se quella rete ha valutato lo stesso IP di invio, dominio busta e politica DNS dei tuoi controlli riusciti. Una modifica ampia dell'autorizzazione può nascondere la differenza e allo stesso tempo aumentare chi può inviare utilizzando il tuo dominio.
Costruisci un confronto corrispondente
Seleziona una transazione non riuscita e una transazione riuscita dalla stessa applicazione e ora approssimativa. Registra l'ora UTC, collegando l'indirizzo IPv4 o IPv6 , SMTP MAIL DA, HELO nome, rete del destinatario, risposta SMTP esatta e risultato dell'autenticazione attendibile se il messaggio è stato accettato. Un messaggio rifiutato durante SMTP potrebbe non avere mai un'intestazione consegnata da controllare. Conserva invece il registro delle transazioni del mittente. Trattare gli identificatori e i contenuti dei messaggi come prove operative limitate.
SPF normalmente valuta il dominio MAIL FROM; per un percorso inverso nullo, la sua identità MAIL FROM viene costruita utilizzando postmaster e il dominio HELO . L'indirizzo Da visibile non è l'istruzione di ricerca. Un servizio di inoltro può anche modificare l'IP di connessione visto dal destinatario finale. RFC 7208 , sezioni 2.3–2.4 e 10.3.
Separare le classi di fallimento
Un errore esplicito indica un percorso valutato che non ha autorizzato il client. Per errore richiede l'ispezione della sintassi della politica, multipla Registri SPF, dipendenze ricorsive e limiti di valutazione. Temperamento richiede l'indagine su problemi di ricerca o elaborazione temporanei. Nessuno significa che non è stato trovato alcun dominio valutato utilizzabile o nessun record SPF applicabile, piuttosto che un divieto esplicito. Neutrale significa che la policy non fa alcuna affermazione di autorizzazione definita; softfail esprime un'affermazione negativa più debole di fail. Nemmeno un pass SPF . Cattura il risultato prima di interpretare un ticket generico di “problema di autenticazione”.
Confronta le risposte DNS autorevoli con le risposte ricorsive e i relativi timestamp. Interroga il nome esatto del proprietario e ogni dipendenza raggiunta per quell'IP. Le coperture del limite di dieci termini di SPF valutate includono, a, mx, ptr ed esistono meccanismi e il modificatore di reindirizzamento, inclusa la valutazione nidificata, anziché ogni pacchetto DNS o frammento TXT . L’IP4, l’IP6 e tutti i meccanismi non consumano il budget a termine; limiti separati possono comunque applicarsi ad altri lavori DNS . Una scansione statica dello strumento e il percorso effettivo del ricevitore possono quindi non essere d'accordo. RFC 7208 , sezioni 4.5–4.6.4 e 8.
Lavora attraverso un esempio controllato
Scenario illustrativo: il mittente raggiunge la rete A tramite un indirizzo IPv4 autorizzato ma raggiunge la rete B tramite un indirizzo IPv6 non elencato. Il nome dell'applicazione e l'indirizzo del mittente sembrano identici. L'intervento utile è verificare la proprietà e l'uso previsto del percorso IPv6 , quindi autorizzarlo in modo restrittivo se appropriato o smettere di usarlo. L'aggiunta della rete del destinatario a SPF risolverebbe il problema del lato sbagliato della connessione.
Una seconda possibilità è l'inoltro: la rete B riceve da un intermediario anziché dal tuo host in uscita originale. Non aggiungere spedizionieri arbitrari alla tua polizza. Controlla il percorso di inoltro, sopravvivendo allineato DKIM e la politica del curatore. Un risultato SPF che passa può ancora essere disallineato DMARC. RFC 9989 , sezione 4.4.
Chiudere con prove riproducibili
Apporta una modifica controllata con un proprietario, salva il valore precedente e la condizione di rollback. Ripetere i test corrispondenti lungo il percorso interessato, includendo entrambe le famiglie di indirizzi ove utilizzate. Conferma SPF , autenticazione allineata e gestione SMTP separatamente. Se gli stessi input e la stessa politica producono ancora risultati diversi, preparare un pacchetto di prove oscurate per l'operatore ricevente. Registra la differenza di implementazione irrisolta invece di etichettare l'intera rete come danneggiata.
Utilizzare un foglio di lavoro con prove abbinate
- Coppia non riuscita/controllo: registra gli orari UTC, l'applicazione e la rete del destinatario per entrambi.
- Connessione: confronta l'effettiva sorgente IPv4 o IPv6 e qualsiasi hop di inoltro.
- Identità: confronta MAIL FROM, HELO e il dominio effettivamente controllato dal destinatario.
- Politica: conservare le risposte TXT datate e il percorso delle dipendenze valutato.
- Risultato: preserva esattamente fail, softfail , neutral, none, temperror o permerror , più la risposta SMTP .
- Azione: riparare solo una differenza verificata; ripetere lo stesso percorso e conservare le differenze irrisolte per l'escalation.