Un dominio affidabile o un servizio di invio condiviso può diventare parte di un percorso di messaggi abusivo. La domanda utile non è se l’infrastruttura sia generalmente affidabile. Indica se questo particolare messaggio è stato autorizzato a utilizzare l'identità autenticata. L'autenticazione e l'autorizzazione aziendale rispondono a domande diverse.
Definire l'autorizzazione da riutilizzare
Una casella di posta compromessa può inviare tramite il suo percorso autenticato ordinario. Un'autorizzazione di rete troppo ampia può ammettere una fonte involontaria. Un relè può firmare un messaggio dopo averlo accettato in base a una regola di ammissione non sufficientemente specifica. Questi meccanismi hanno proprietari e rimedi diversi. Non ridurli a un'inspiegabile accusa di dirottamento della reputazione.
La ricerca originale di BreakSPF esamina il permissivo SPF configurazioni e infrastrutture condivise. Il suo modello di minaccia rende l’accesso alla rete di origine una condizione centrale. Si tratta di un limite di distribuzione, non di una prova che un utente malintenzionato possa crearne uno Firma DKIM. Documento BreakSPF, Sezione III. Trattate le misurazioni del documento come una ricerca storica, non come un inventario attuale dei servizi vulnerabili.
Costruisci un modello di minaccia preciso
Scrivi separatamente il dominio protetto, l'identificatore autenticato, l'insieme di fonti consentito, la capacità dell'aggressore e la decisione del destinatario. Nello scenario limitato qui, brand.test autorizza 192.0.2.0/24 per SPF . L'applicazione approvata utilizza 192.0.2.10 , mentre un ipotetico inquilino non previsto può provenire da 192.0.2.99 . Entrambi gli indirizzi si trovano nell'intervallo pubblicato. Se tale accesso da parte del locatario esista in un servizio reale richiede prove separate.
SPF controlla l'autorizzazione dell'origine per la sua identità valutata. Non identifica l'essere umano dietro un IP condiviso. Se l'identità SPF che passa è in linea anche con il dominio dell'autore, quel percorso può soddisfare DMARC senza DKIM. RFC 7208 E RFC 9989. Una valutazione riuscita può quindi rivelare che è stata concessa troppa autorità, piuttosto che un ricevitore che ignora la regola di superamento.
Confronta tre casi di autorizzazione scritta
Assumi visibile da alerts@brand.test , non vuoto MAIL DA bounce@brand.test , nessuna firma DKIM e una valutazione DMARC altrimenti idonea. Confronta ipotetico Registri SPF v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- Sorgente approvata 192.0.2.10 : inclusa da entrambi i prefissi di rete; SPF supera e si allinea con brand.test, quindi il messaggio illustrativo supera DMARC in entrambi i casi.
- Fonte non voluta 192.0.2.99 : inclusa dal /24 ma non dal /32; SPF passa solo sotto il record ampio. Senza firma DKIM , il risultato DMARC stabilito è superato sotto /24 e fallito sotto /32.
- Sorgente esterna 198.51.100.10 : inclusa da nessuno dei due prefissi; -all i rendimenti SPF falliscono in entrambi i casi. Senza firma DKIM , il risultato DMARC previsto è negativo in entrambi.
Questi sono scritti prefisso-appartenenza e allineamento deduzioni, non un parser SPF in esecuzione, osservazione DNS o riproduzione di BreakSPF. Il controllo del codice sorgente è presupposto, non dimostrato. Nessun messaggio esterno o servizio live è stato testato. La tecnica del protocollo incrociato dell'articolo non rientra in questo esempio didattico.
Un singolo meccanismo allineato di passaggio può soddisfare la condizione di passaggio DMARC di un messaggio. Ciò non rende adeguata la distribuzione solo SPF: la sezione 7.4 della RFC9989 richiede DKIM valido per la pubblicazione dei domini p=rejecte la sezione 8 affronta la piena partecipazione. Si tratta di compiti di distribuzione separati, non di un gate di passaggio aggiuntivo per messaggio.
Fissare il confine responsabile
Prima di restringere un record SPF reale, inventaria tutti i mittenti legittimi e segui la configurazione supportata dal provider. Una fonte dedicata è utile solo se è effettivamente esclusiva e mantenuta. Confermare che il servizio di invio vincola i clienti alle identità consentite; verificare la configurazione DKIM e rimuovere l'autorità obsoleta tramite il controllo delle modifiche.
Monitora gli errori specifici del percorso dopo la modifica, preserva un piano di ripristino e documenta i mittenti sconosciuti. Non sostituire un record ampio con un elenco IP indovinato da questo esempio. La lezione è riconciliare l'autorizzazione con l'effettiva proprietà del servizio, non copiare DNS dimostrativo nella produzione.