È noto dal disegno originale di SPF che poteva fornire solo alcune informazioni aggiuntive per determinare se o qualcosa fosse spam. In effetti ci sono molte circostanze comuni che possono portare a un falso errore.
L'inoltro interrompe l'SPF e causa falsi fallimenti
Ad esempio, supponiamo di avere un indirizzo email che non uso, ad esempio, [email protected] , e l'ho impostato per inoltrare tutta la posta al mio indirizzo reale, [email protected] . Ora se Wilma mi invia e-mail dal suo sistema, foo.example e questo è tutto valido in termini di SPF, sarà comunque ancora entrato in domain.example server di posta dal server di posta di example.tld . Il server di posta di example.tld non sarà autorizzato in SPF per posta da foo.example anche se non vi sono falsificazioni o spam.
Ora ci sono un paio di cose che le persone possono fare per cercare di chiarire casi come questo. Ad esempio domain.example può autorizzare example.tld . In alternativa è possibile impostare diversi meccanismi di inoltro. Ma nessuno di questi è ideale, affidabile o disponibile per tutte le configurazioni.
Non bloccare quando sai che i falsi fallimenti sono possibili
Considerato quanto sopra (e alcuni altri modi per ottenere sistematicamente il falso SPF non riuscito), è importante pesare le informazioni che un errore SPF ti dà invece di respingere automaticamente tutti i fallimenti SPF. Fortunatamente, anche più a lungo di SPF è stato intorno, i meccanismi anti-spam hanno utilizzato filtri bayesiani. Questo è più che dare un punteggio a ciascun fattore, è un modo di combinare tutti i piccoli fatti che il sistema sa di ciò che è e non è lo spam e il bilanciamento che tutto in un giudizio che si sposterà verso falsi negativi (lasciando alcuni spam attraverso) anziché falsi positivi (rifiutando cose che non dovrebbero essere rifiutate).
SPF è terribile, ma era necessario
Ho partecipato ad alcune delle prime discussioni che portano a SPF. Tutti coloro che sono coinvolti sanno che è profondamente imperfetto. Ma eravamo alla disperata ricerca di qualcosa che potesse aiutare a controllare il flusso di spam nei server di posta che stavamo correndo. (Certo, i singoli utenti odiano lo spam nelle loro caselle di posta, ma le persone che gestiscono i sistemi di posta devono pagare l'hardware e la larghezza di banda reali per gestire tutta la posta in arrivo anche se la maggior parte viene filtrata prima che raggiunga la casella di posta.) p>
DKIM sostituisce in gran parte SPF. Sono fuori dal settore della gestione delle e-mail per un po ', quindi non sono completamente sicuro di quale sia lo stato attuale del motivo per cui persiste SPF ora che DKIM è più ampiamente disponibile. Posso vedere casi in cui è possibile SPF e DKIM no. Ad esempio, con SPF è possibile autorizzare un dominio o una rete come mittente senza dover fornire a tale dominio di invio la propria chiave privata DKIM. SPF e DKIM pongono diversi requisiti sui domini di invio legittimi per coordinare la loro attività.
Tuttavia, sono sorpreso di vedere che SPF è ancora in circolazione. All'epoca in cui fu presentato, pensai che si trattava di una temporanea misura disperata che sarebbe stata sostituita da meccanismi un po 'più coerenti. Ma sembra che abbia ancora un ruolo da svolgere.