UN SPF includere per un servizio di posta elettronica condiviso può autorizzare l'infrastruttura utilizzata da molti clienti. Spesso questo è il modo in cui il servizio è concepito, ma l'autorizzazione merita una spiegazione chiara. SPF controlla un host che si connette rispetto a una policy di dominio; una corrispondenza positiva ampia non è una credenziale crittografica specifica del tenant.
La questione pratica è se il tuo provider impedisce a un altro cliente di inviare con la tua identità SMTP e se la policy concede solo le autorizzazioni dell'infrastruttura di cui il tuo utilizzo ha effettivamente bisogno.
Mappare la relazione di fiducia
Per ciascun intervallo IP incluso o condiviso, registra il servizio, il proprietario dell'azienda, il dominio della busta supportato e la configurazione documentata del fornitore. Determina se la tua posta utilizza un dominio busta di proprietà del provider o un dominio personalizzato che controlli. Se il provider possiede il dominio effettivamente valutato, l'aggiunta di un'inclusione al dominio principale potrebbe non influire affatto sul risultato SPF di quel messaggio.
Leggi la documentazione attuale del provider per la verifica del dominio e i controlli del mittente. Laddove la documentazione non sia chiara, identificare la domanda per il supporto del proprietario del servizio o del fornitore. Non affermare che tutti gli inquilini siano isolati semplicemente perché supera un test dal tuo account.
Comprendere i limiti di una decisione basata sulla proprietà intellettuale
RFC 7208 §11.4 descrive i rischi di falsificazione tra utenti in cui un sistema condiviso consente agli utenti di rivendicare le identità di altri utenti. Un passaggio SPF può stabilire che l'host che si connette è autorizzato per il dominio valutato senza dimostrare quale account cliente ha avviato il messaggio. L'applicazione da parte del provider è quindi parte del limite di sicurezza.
Ciò non significa che ogni servizio condiviso non sia sicuro. Ciò significa che il modello di autorizzazione ha due livelli: DNS concede l'autorizzazione all'infrastruttura e il servizio deve limitare il modo in cui i clienti utilizzano le identità su tale infrastruttura. Le prove per un livello non dovrebbero essere presentate come prove per l’altro.
Scegli la configurazione supportata più stretta
Preferisci l'esatta configurazione di inclusione o dominio supportata dal provider per il prodotto e la regione di invio, dove tali distinzioni sono documentate. Evitare di aggiungere l'intera allocazione di rete di un fornitore quando è disponibile una policy mantenuta più ristretta. Non inventare inclusioni più ristrette né sostituire policy gestite dal fornitore con uno snapshot di IP a meno che non sia possibile mantenere tale progettazione in modo sicuro.
Un dedicato percorso di ritorno il sottodominio può separare la politica SPF di un servizio da altri messaggi di posta. Migliora la proprietà e la gestione del ciclo di vita, ma di per sé non dimostra l’isolamento tra i clienti che condividono lo stesso fornitore. Esamina altri controlli di autenticazione e account come parti separate della progettazione.
Confronta attentamente due configurazioni
Esempio illustrativo: v=spf1 ip4:192.0.2.0/24 -all autorizza ogni indirizzo IPv4 in quella rete di documentazione per l'identità valutata. Solo una politica di denominazione ip4:192.0.2.10 autorizza un indirizzo. La politica più ristretta riduce l'insieme delle fonti, ma è utile solo se il fornitore garantisce effettivamente quell'indirizzo per il tuo servizio. Una restrizione non supportata può interrompere la consegna legittima durante il failover.
Sotto RFC 7208 §5.2, un'inclusione valuta una policy di riferimento; la sua attuale espansione è un'osservazione, non un contratto a tempo indeterminato. Può cambiare quando il fornitore cambia la sua politica. Catturare la dipendenza e la proprietà invece di trattare gli indirizzi risolti di oggi come la verità finale.
Revisione senza testare altri inquilini
Utilizza i tuoi account autorizzati e i destinatari controllati per la convalida. Conferma le tue identità previste e registra quale infrastruttura produce il passaggio. Valutare le restrizioni del tenant attraverso documentazione, prove di configurazione approvate o un test di sicurezza esplicitamente autorizzato. Non tentare di impersonare il dominio di un altro cliente per dimostrare un problema teorico.
Monitorare nuove offerte, gamme di rete insolitamente ampie e servizi senza proprietario. Una revisione delle politiche dovrebbe anche controllare i limiti di valutazione ricorsiva, perché diversi fornitori condivisi possono creare un problema di risorse anche quando ciascuna inclusione è individualmente legittima.
Rendere esplicita la decisione di accettazione
Tenere un breve registro dell'autorizzazione infrastrutturale concessa, dei controlli di identità da parte del fornitore, delle lacune note nelle prove e del proprietario responsabile. Pianifica la revisione quando cambia il provider o la configurazione del servizio. Accettare un’infrastruttura condivisa può essere ragionevole, ma la decisione dovrebbe basarsi sul modello di fiducia completo piuttosto che sul solo badge verde SPF .
Registra la decisione successiva
Utilizzare due righe di prova: autorizzazione dell'infrastruttura (politica effettiva, dominio della busta e fonte osservata) e controllo del tenant (verifica/applicazione documentata, prova della configurazione e lacune irrisolte). Il tuo risultato SPF positivo riempie solo la prima riga. Se il provider non garantisce un indirizzo più ristretto, non considerare una restrizione non supportata come un miglioramento della sicurezza verificato. Non è stato eseguito alcun test tra tenant o modifica del fornitore.