In questo periodo diversi clienti di Achab hanno segnalato l'impossibilità di inviarci email vedendosi rifiutata la sessione SMTP dal nostro MDaemon con la seguente motivazione:
dominio.it does not designate permitted sender hosts.
Analizzando queste segnalazioni abbiamo scoperto che tutti coloro che hanno riscontrato questo problema spedivano attraverso un servizio di relay di Microsoft.
Cosa è successo?
Abbiamo formulato la nostra tesi analizzando i log del nostro MDaemon, in particolare la porzione dei log dove è riportata la verifica SPF sull'IP del mittente:
Wed 2016-07-13 12:02:00.671: 09: [288262] Performing SPF lookup (dominio.it / 40.107.5.109)
Wed 2016-07-13 12:02:00.707: 09: [288262] * Policy: v=spf1 include:spf.protection.outlook.com -all
[…]
Wed 2016-07-13 12:02:00.707: 09: [288262] * Policy (cache): v=spf1 ip4:207.46.101.128/26 ip4:207.46.108.0/25 ip4:207.46.100.0/24 ip4:207.46.163.0/24 ip4:65.55.169.0/24 ip4:157.55.133.0/25 ip4:157.56.110.0/23 ip4:157.55.234.0/24 ip4:213.199.154.0/24 ip4:213.199.180.0/24 include:spfa.pro
[…]
Wed 2016-07-13 12:02:00.707: 09: [288262] * Result: fail
Wed 2016-07-13 12:02:00.707: 09: [288262] Message will be rejected after DMARC processing.
Il log mostra che la sessione SMTP con il mail server di Achab viene fatta da un IP (40.107.5.109) che non appartiene al record SPF pubblicato nel DNS che gestisce il dominio del mittente.
Chi sbaglia quindi? Il ricevente, il mittente o Microsoft?
Ricordiamo che il record SPF – pubblicato sul DNS che gestisce il dominio di posta di chi spedisce – è una tecnologia che serve per legittimare il mittente della posta elettronica, bloccando phishing e spoofing. Pubblicando il record SPF con il parametro "-all" al termine del record stesso, il mittente dichiara al mondo intero che la propria posta è da considerare legittima solo se proveniente da un IP incluso nel record SPF.
In questo esempio, come si vede nei dettagli della verifica, l'IP del mittente non è incluso nel record SPF e quindi il server MDaemon di Achab rifiuta la sessione.
Ci sono due possibili cause:
- I record SPF non sono aggiornati. Attenzione che, se un record SPF contiene degli include, occorre esplodere tutti gli include per verificare l’intero set di IP o range IP del dominio cui il record appartiene.
- I record SPF sono aggiornati, ma il server di posta sta pescando il record da una cache che a sua volta non è aggiornata con le recenti modifiche del mittente.
Affinché la tecnologia SPF funzioni sempre correttamente è opportuno che:
- Il mittente verifichi periodicamente che il proprio record SPF sia aggiornato. Questo è particolarmente importante per coloro che si appoggiano a servizi forniti da terzi che potrebbero modificare o ampliare i range di IP da cui spediscono, come nel caso di questo esempio.
- Il destinatario svuoti periodicamente o elimini del tutto il caching di questi record.
Il destinatario potrebbe anche risolvere il problema con il mittente, mettendo nella white list del controllo SPF il dominio del mittente in modo che non sia bloccato dalla verifica SPF. Questa probabilmente è la soluzione più veloce, ma anche la meno corretta poichè risolve il problema con un particolare destinatario, ma resta presente con tutti gli altri destinatari che implementano la verifica SPF in ricezione (e sono molti).
Grazie per i commenti,
abbiamo aggiornato l’articolo aggiungendo un’ulteriore possibile causa del problema in oggetto: le cache…
Noi abbiamo deciso di eliminare completamente la cache dalla verifica SPF del server di posta per evitare di avere errori durante il transitorio in cui le modifiche ai record SPF vengono recepite (se usate MDaemon occorre andare in Sicurezza > Impostazioni di Sicurezza > Autenticazione mittente > Verifica SPF e disabilitare l’opzione "Record cache SPF").
Giusto a settembre dello scorso anno mi trovai di fronte allo stesso problema e sempre con Microsoft. Alla fine dovetti adattarmi ad utilizzare la terza soluzione.
Grazie Luca per le risposte sempre esaurienti. Manca solo di sapere come avete risolto voi. :-))