[ SPF ]

SPF softfail contro hardfail: tenere conto dell'inoltro e della gestione del destinatario

Scegli il qualificatore SPF finale esaminando i percorsi di invio reali, l'inoltro e il comportamento del destinatario, anziché dare per scontato che controlli la consegna.

A cura del team di ricerca EmailAuth

[ Punti chiave ]

  • Un ~all raggiunto dà softfail ; un raggiunto -all dà un fallimento.
  • I destinatari decidono la gestione piuttosto che ereditare un comando di consegna.
  • Testare l'inoltro separatamente dai mittenti diretti mancanti.
In questa pagina

Cambiare ~all A -all rafforza l'affermazione che un dominio fa riguardo a un IP di invio senza eguali. Non trasforma il proprietario del dominio nel filtro di posta del destinatario. Una decisione utile inizia con due domande: quali connessioni legittime rimangono senza corrispondenza e cosa succede a quei messaggi che contano nei sistemi riceventi?

Leggi il risultato prima di giudicare la consegna

SPF controlla se l'host che si connette può utilizzare l'identità SMTP valutata. Un meccanismo positivo corrispondente produce passaggio. Se la valutazione raggiunge ~all, produce softfail , una dichiarazione qualificata secondo cui l'host probabilmente non è autorizzato. Raggiungere -all produce fail, una dichiarazione definitiva che non è autorizzato. "Hardfail" è una scorciatoia comune; il risultato del protocollo viene denominato fallire.

RFC 7208 §8.4 E RFC 7208 §8.5 separare tale affermazione dalla gestione. La disposizione dei guasti è una politica locale del ricevente. Per softfail , la RFC sconsiglia il rifiuto basato esclusivamente su tale risultato, consentendo al contempo un esame più attento. Nessuno dei due qualificatori promette una casella di posta, un posizionamento nella cartella spam o un rifiuto SMTP universale. Un ricevitore può rifiutare per ragioni non correlate anche quando SPF passa.

I meccanismi vengono valutati in ordine di seguito RFC 7208 §4.6.2. La modifica dell'ultimo qualificatore non fa nulla per un messaggio che già corrisponde a un meccanismo positivo precedente. Un termine eccessivamente ampio ip4 la gamma o l'inclusione del servizio rimane eccessivamente ampia dopo l'aggiunta -all.

Separare i mittenti mancanti dalla consegna indiretta

Costruisci un elenco dei servizi di invio SMTP effettivi, dei relativi domini di busta e delle osservazioni rappresentative del destinatario. La casella di posta di un dipendente, un'applicazione di fatturazione e una piattaforma di marketing possono utilizzare domini busta diversi anche quando il loro indirizzo del mittente visibile sembra identico. Diagnostica il dominio mostrato nel risultato SPF del destinatario attendibile, non il dominio che appare semplicemente sullo schermo.

L'inoltro modifica l'IP di connessione. Se l'identità della busta originale viene mantenuta, il destinatario finale può vedere un messaggio legittimo proveniente da un host non autorizzato dal dominio originale. L'aggiunta di ogni mittente alla policy SPF del mittente originale non è una riparazione scalabile e potrebbe autorizzare un'infrastruttura fuori dal tuo controllo. Esaminare la struttura dell'inoltro e le altre prove di autenticazione del messaggio. Non classificare ogni errore inoltrato come servizio in uscita dimenticato. RFC 7208 §10.3 discute questa difficoltà architettonica.

Lavora attraverso un esempio controllato

Esempio illustrativo, utilizzando indirizzi di sola documentazione: v=spf1 ip4:192.0.2.10 ~all autorizza una connessione diretta da 192.0.2.10 . Una connessione da 198.51.100.20 raggiunge softfail . Sostituzione ~all con -all modifica il secondo risultato in Fallito ma lascia il primo come superato.

Supponiamo ora che 198.51.100.20 inoltri la posta originariamente inviata da 192.0.2.10 e conservi l'identità della busta. Il risultato SPF presso il destinatario finale segue la connessione di inoltro, non il primo hop. Si tratta di uno scenario di test previsto, non di una prova che il servizio originale abbia smesso di inviare correttamente.

Prendere una decisione politica reversibile

Prima di modificare il qualificatore, preservare l'esistente registrazione TXT e TTL, verificare la proprietà del mittente e concordare quali prove potrebbero attivare un ripristino. Testare separatamente i percorsi diretti critici e i percorsi indiretti noti. Registra l'IP di origine, il dominio valutato, il risultato SPF e l'esito della consegna finale per ciascun test. Includi una fonte di test senza eguali sotto il tuo controllo in modo che l'effetto reale della modifica sia visibile.

Dopo la pubblicazione, controlla DNS autorevole e le risposte ricorsive pertinenti, consentendo i dati memorizzati nella cache. Esamina gli errori anziché limitarsi a ripristinare ogni volta che un messaggio viene filtrato. Una fonte autorizzata mancante necessita di una correzione d'inventario; un problema di inoltro richiede una decisione basata sul percorso; un rifiuto di reputazione non correlato non verrà risolto modificando la qualificazione finale.

Chiudi con un record difendibile

Mantieni il motivo della qualificazione scelta accanto all'inventario corrente del mittente. Rivedilo quando cambiano i servizi o i percorsi di consegna. Un meccanismo finale restrittivo è utile solo quando le autorizzazioni precedenti descrivono i reali confini di invio del dominio. La decisione è completa quando il proprietario può spiegare sia la copertura del direct mailing che i compromessi del mailing indiretto.

Utilizzare le prove per prendere una decisione

Nel record sintetico, 192.0.2.10 rimane superato dopo il cambio di qualificazione; 198.51.100.20 passa da softfail a fail solo quando viene raggiunto il meccanismo finale. Registrare separatamente la gestione del ricevitore. Se il secondo IP è uno spedizioniere che conserva la busta originale, indaga sul percorso indiretto prima di trattarlo come un mittente autorizzato scomparso. Non è stata eseguita alcuna consegna in tempo reale o modifica del qualificatore.

[ Porta via ]

Un ~all raggiunto dà softfail ; un raggiunto -all dà un fallimento. I destinatari decidono la gestione piuttosto che ereditare un comando di consegna. Testare l'inoltro separatamente dai mittenti diretti mancanti.

[Per ruolo]

Cosa significa questo per te

Scegli il tuo ruolo per i prossimi passi pratici.

Amministratore IT/Posta

Risultati dei test e consegna separatamente.

Un'osservazione fallita e un rifiuto SMTP sono fatti diversi. Conservarli entrambi quando si confrontano le politiche.

Prossimi passi

  1. Testare percorsi diretti e indiretti.
  2. Cattura l'identità esatta della busta.

CISO/SecOps

Esaminare il limite dell'autorizzazione.

Una forte qualificazione finale non può compensare ampi meccanismi positivi o un'eccezione di inoltro non gestita.

Prossimi passi

  1. La sfida senza proprietario include.
  2. Documentare il rischio residuo della posta indiretta.

Fondatore / Non tecnico

Proteggi i percorsi critici per l'azienda.

Chiedi quali comunicazioni dei clienti si basano sull'inoltro o su mittenti esterni prima di approvare una dichiarazione finale più forte.

Prossimi passi

  1. Nomina i proprietari delle fatture e dei messaggi di accesso.
  2. Approvare una condizione di ripristino documentata.

[ Domande frequenti ]

Domande frequenti

Hardfail è un nome di risultato SPF ?

Il risultato del protocollo è fallito. Hardfail è un nome informale comune per il risultato prodotto quando un meccanismo di corrispondenza ha il qualificatore meno.

RFC 7208 §4.6.2 RFC 7208 §8.4

-all forza i ricevitori a rifiutare?

No. RFC 7208 lascia la gestione degli errori alla politica del destinatario. L'editore denuncia la mancanza di autorizzazione; il ricevente decide la disposizione.

RFC 7208 §8.4

~all garantisce la consegna?

No. I ricevitori possono utilizzare altri segnali di filtraggio. La RFC sconsiglia di rifiutare esclusivamente a causa di softfail .

RFC 7208 §8.5

La modifica del qualificatore risolverà un'ampia inclusione?

No. Una fonte che corrisponde a un'inclusione positiva passa comunque prima che venga raggiunto il meccanismo finale.

RFC 7208 §4.6.2 RFC 7208 §5.2

Perché la posta inoltrata non supera SPF ?

Il ricevitore finale controlla l'IP di connessione dello spedizioniere. Se l'identità della busta originale viene mantenuta, quell'IP potrebbe non essere autorizzato per essa.

RFC 7208 §10.3

Devo autorizzare ogni spedizioniere?

No. Prima indaga sul percorso. L'aggiunta di spedizionieri di terze parti può ampliare l'autorizzazione oltre i sistemi che controlli.

Cosa deve contenere il registro del test?

Cattura l'identità valutata, l'IP di connessione, il timestamp, la policy pubblicata, il risultato SPF del destinatario e l'esito della consegna.

Quando dovrebbe essere rivisto il qualificatore?

Esaminarlo dopo modifiche al mittente o al routing e quando il traffico legittimo senza corrispondenza rivela che l'inventario o le ipotesi di gestione sono incompleti.

[ Fonti ]

Fonti

  1. RFC 7208

    Sezioni §2.4 · §4.6.2 · §5.1 · §5.2 · §8.4 · §8.5 · §10.3

  2. RFC 8601

    Sezioni §1.2 · §7.1

[ Glossario ]

Glossario

SPF
Valutazione dell'autorizzazione per un IP di connessione e la relativa identità SMTP .

RFC 7208 §2.4

SPF fallisce
Una dichiarazione definitiva che il cliente non è autorizzato a utilizzare il dominio con l'identità specificata.

RFC 7208 §8.4

SPF softfail
Una dichiarazione più debole secondo cui l'editore ritiene che l'host non sia autorizzato; i riceventi non dovrebbero rifiutare esclusivamente in base a quel risultato.

RFC 7208 §8.5

Provenienza aziendale

Perché le principali istituzioni finanziarie e i governi hanno ritirato le dashboard di sicurezza della posta elettronica.

Le tradizionali piattaforme di autenticazione e-mail ti vendono una dashboard e chiedono ai tuoi ingegneri di fare il lavoro. Negli ambienti ad alto rischio, la supervisione manuale comporta un’applicazione ritardata, deviazioni della configurazione e domini ombra non monitorati.

EmailAuth è la piattaforma di provenienza della posta elettronica degli agenti. I nostri agenti applicano p=reject, mantieni allineati i mittenti di terze parti e sposta i tuoi domini al massimo RFC 9989 conformità, il nuovo standard DMARC , con verificabilità human-in-the-loop.

Governi Grandi imprese Istituti finanziari di primo livello

SaaS · Locazione dedicata · Air-gapped on-premise · Crittografia BYOK

Base di conoscenza