Un server di posta può inviare un messaggio legittimo con un percorso inverso SMTP vuoto, scritto come MAIL DA:<>. Le notifiche sullo stato della consegna utilizzano un percorso inverso nullo in RFC 5321 §4.5.5 per evitare di creare cicli di rimbalzo infiniti. Il percorso inverso vuoto non significa che non esiste SPF valutazione da considerare: RFC 7208 §2.4 definisce a MAIL DA identità utilizzando la parte locale direttore delle poste e il HELO dominio in questo caso.
Gli amministratori che testano solo la posta degli utenti ordinari possono quindi perdere un percorso di autenticazione separato utilizzato dal server stesso.
Distinguere HELO dal mittente visibile
HELO o EHLO introduce il client SMTP nel server ricevente. Il suo dominio è separato da quello visibile del messaggio Dall'intestazione e può differire da un dominio MAIL FROM non vuoto. Un host potrebbe presentarsi come relay.example.com durante la trasmissione della posta dell'utente con un mittente della busta all'indirizzo example.com.
RFC 7208 §2.3 consiglia di controllare HELO separatamente e consiglia di farlo prima quando vengono controllate entrambe le identità. IL MAIL DA regole dipendono dal fatto che il controllo HELO sia stato eseguito e abbia raggiunto un risultato politico definitivo. Non dare per scontato che ogni destinatario emetterà due risultati SPF indipendenti per ogni messaggio.
Per il controllo HELO descritto nella RFC, il valore fornito deve essere un nome di dominio multietichetta valido. Un valore o un indirizzo letterale non valido non può essere trattato come se fosse un normale nome host interrogabile. Correggi la configurazione del server di invio tramite i controlli supportati anziché inventare voci DNS per identità non corrette.
Pubblica per il nome host effettivamente utilizzato
Cattura una transazione SMTP controllata o un registro del ricevitore attendibile per stabilire il valore HELO . Quindi interroga SPF TXT su quel nome host esatto. La politica SPF a example.com non si applica automaticamente a relay.example.com.
Per un server con indirizzi di uscita stabili ed esplicitamente controllati, una policy ristretta può descrivere tali indirizzi. Per l'infrastruttura di invio ospitata, seguire la configurazione supportata e i limiti di proprietà del provider. Non pubblicare un record indovinato su un nome host che non controlli e non dare per scontato che un nome host sia Un record è necessariamente l'indirizzo di uscita SMTP .
Includere IPv6 nella recensione. UN MTA può presentare lo stesso HELO su diverse famiglie di indirizzi e una policy che copre solo la sua origine IPv4 può produrre risultati diversi su IPv6 .
Esercitare separatamente il traffico normale e quello a inviluppo vuoto
Piano di test illustrativo, utilizzando indirizzi di sola documentazione:
- Un server si connette da 192.0.2.10 e si presenta come
relay.example.com. - Il nome host pubblica
v=spf1 ip4:192.0.2.10 -all. - Per un messaggio con
MAIL DA:<>, deriva SPFpostmaster@relay.example.comcome identità MAIL FROM. Tale fonte è autorizzata dalla politica del nome host. - Ripeti utilizzando un IP di test diverso e non autorizzato. Con la stessa politica del nome host, l'origine senza corrispondenza raggiunge il fallimento.
Questi sono i risultati attesi dal valutatore, non i risultati di un sistema reale. Utilizza destinatari controllati e autorizzati per test di notifica reali. Non provocare rimbalzi verso indirizzi esterni arbitrari semplicemente per osservare il comportamento.
Registrare l'identità e il verdetto
Conserva l'IP di connessione della sessione, il valore HELO , il percorso inverso e il risultato generato dal ricevitore. Un generico "pass SPF " senza identità non è sufficiente per la risoluzione dei problemi. Un messaggio di un utente ordinario riuscito non dimostra che la posta con percorso inverso nullo esercitasse lo stesso dominio.
Quando un test fallisce, decidi se il problema riguarda il nome host annunciato, la pubblicazione DNS , l'inventario in uscita o un percorso imprevisto. La modifica della policy SPF del dominio del dipendente non riparerà una policy del nome host che non è mai stata interrogata.
Rendi la posta generata dal server parte del controllo delle modifiche
Aggiungi test di notifica agli aggiornamenti MTA, alle migrazioni di inoltro e all'abilitazione IPv6 . Conserva la configurazione dell'identità precedente e il percorso di ripristino approvato. Chiudi la modifica solo una volta valutata la posta ordinaria e i flussi generati dal server rilevanti per la tua organizzazione. Ciò impedisce che un test di posta elettronica integro nasconda notifiche operative non funzionanti.
Utilizzare le prove per prendere una decisione
Mantieni separate le righe di notifica MAIL FROM ordinarie e percorso null. Per un percorso nullo e HELO = relay.example.com , il mittente costruito è postmaster@relay.example.com ; l'IP di prova deve essere valutato rispetto alla politica di quel dominio. Un normale passaggio di messaggio utente per example.com non stabilisce tale risultato. Utilizzare destinatari autorizzati e notifiche controllate; non è stato eseguito alcun test di rimbalzo o modifica del server.