Perché la posta elettronica viene recapitata normalmente nonostante un "errore" SPF?

Sto cercando di capire perché la posta elettronica contraffatta viene consegnata ai principali provider di posta elettronica (gmail.com, outlook.com) anche se la posta elettronica è contrassegnata con un SPF hardfail. L'e-mail viene inoltre recapitata a Microsoft Exchange, che sta generando uno PermErrorper lo stesso record SPF.

Sto inviando e-mail utilizzando il dominio SOME_DOMAIN.com, che definisce un record SPF rotto. L'email viene trasmessa dal mio indirizzo IP che non è esplicitamente elencato nel record SPF di SOME_DOMAIN.com. Il record SPF per SOME_DOMAIN.com ha le seguenti tre proprietà, le prime due violano SPF RFC-4408:

1. Richiede più di 10 query DNS per risolvere l'intero record SPF, a causa di include:.
2. Errore di sintassi in uno dei record SPF, python-spf genera un errore di analisi.
3. Il record SPF contiene sia le regole ~alle -all, sia dicendo che l'insieme di tutti gli indirizzi dovrebbe softfailehardfail

L'e-mail inviata a un indirizzo outlook.com che impersona admin@SOME_DOMAIN.com conterrà il seguente errore nell'intestazione SMTP dell'email consegnata. Questa e-mail è stata recapitata normalmente nella posta in arrivo dell'utente :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail consegnerà anche l'e-mail nella posta in arrivo dell'utente, ma genererà un diverso errore SPF:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

Quindi cosa sta succedendo qui? Perché la posta elettronica viene recapitata nonostante un SPF hardfail? Avere un record SPF rotto significa che altri server SMTP ignorano del tutto l'SPF? O c'è qualcosa che mi manca qui ...

SPF è configurato in modo così errato da così tanti siti che la ricezione di MTA spesso conta hardfailsolo come advisory e si limita a tenerlo in considerazione nei punteggi di rilevamento dello spam. Alla fine spetta all'amministratore dell'MTA il modo in cui verranno trattati gli errori SPF.

Le condizioni di errore SPF non indicano nulla sulla politica desiderata. In quanto tali, non forniscono indicazioni sull'accettazione o meno del messaggio. È possibile che la politica prevista sia +all. In questo caso è normale accettare la posta. Sembra che Google sia indulgente con la mancata conformità di questo dominio allo standard.

Anche i rifiuti delle policy SPF ( -all) non sono affidabili durante la convalida degli indirizzi del mittente. Esistono diversi casi in cui il rifiuto di tale posta sarebbe inappropriato, tra cui:

• Posta inviata da mailer convenzionati (queste persone vengono pagate per violare la politica.);
• Posta inviata da moduli Web e altri sistemi automatizzati;
• Posta inoltrata da mailing list o altri meccanismi di inoltro; e
• Semplicemente errata configurazione dei record SPF (non comune, ma non abbastanza raro).

Corro un server abbastanza piccolo dove posso rimandare in caso di guasti gravi. Questo mi permette di inserire nella lista bianca errori legittimi. Se il mittente nota che la posta non viene recapitata, potrebbe correggere la sua configurazione. In alcuni casi cercherò di contattare il relativo postmaster, ma molti domini non hanno un postmasterindirizzo.

Gli utenti che desiderano applicare una politica più forte possono utilizzare DMARC, che non è ancora uno standard. È probabile che la posta venga comunque recapitata, ma può essere messa in quarantena o rifiutata come specificato nella politica. È possibile che la posta che non rispetta il criterio venga recapitata nella cartella spam anziché nella normale posta in arrivo.

Gli errori non riusciti di SPF sembrano essere affidabili per convalidare l'identità del server di invio. Ho fatto qualche ricerca qualche tempo fa e ho scoperto che anche i fallimenti soft sul nome HELO sono un motivo ragionevole per fallire o rinviare i messaggi in arrivo.

Molti server di posta non hanno un record SPF. Se il server di posta non ha un record SPF, controllo il dominio padre per un record SPF. Questo non è standard, ma efficace. Incoraggio gli amministratori di posta elettronica a garantire l'esistenza di un record SPF per l'IP del server elencato nel record PTR. Il tuo server dovrebbe identificarsi con il nome restituito anche dal suo record PTR. Verifica di disporre di un record A corrispondente per la verifica DNS inversa.