Tutta la posta esterna a Office 365 non riesce SPF, contrassegnata come indesiderata da EOP in una distribuzione ibrida

In breve: le e-mail legittime stanno finendo nelle cartelle Junk mentre EOP (Exchange Online Protection) contrassegna i messaggi e-mail come junk (SCL5) e SPF fallito. Ciò accade con tutti i domini esterni (ad esempio gmail.com/hp.com/microsoft.com) al dominio del client (contoso.com).

Informazioni sullo sfondo:

Siamo all'inizio della migrazione delle cassette postali a Office 365 (Exchange Online). Questa è una configurazione Hybrid Deployment / Rich-Coexistence, dove:

• On-premise = Exchange 2003 (legacy) e 2010 (installato per la distribuzione ibrida)
• Fuori sede = Office 365 (Exchange Online)
• EOP è configurato per il controllo SPF.
• I record MX puntano ai locali poiché non abbiamo completato la migrazione di tutte le cassette postali da locali a Exchange Online.

Il problema è quando gli utenti esterni inviano e-mail a una cassetta postale di Office 365 nell'organizzazione (flusso di posta: esterno -> Gateway di posta -> server di posta locale -> EOP -> Office 365), EOP esegue una ricerca SPF e hard / soft messaggi non riusciti con l'indirizzo IP esterno del gateway di posta da cui ha ricevuto la posta.

(Le cassette postali locali non mostrano questo problema; solo le cassette postali migrate a Office 365 lo fanno.)

Un'illustrazione:

Esempio 1: da Microsoft a O365

Authentication-Results: spf=fail (sender IP is 23.1.4.9) 
smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9; 
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5

Esempio 2: da HP a O365

Authentication-Results: spf=none (sender IP is 23.1.4.9) 
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none 
(message not signed) header.d=none; Received-SPF: None 
(protection.outlook.com: hp.com does not designate permitted sender hosts) 
X-MS-Exchange-Organization-SCL: 5

Esempio 3: da Gmail a O365

Authentication-Results: spf=softfail (sender IP is 23.1.4.9) 
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com; 
dkim=fail (signature did not verify) header.d=gmail.com; 
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning 
gmail.com discourages use of 23.1.4.9 as permitted sender)  
X-MS-Exchange-Organization-SCL: 5

Per le intestazioni dei messaggi con X-Forefront-Antispam-Report, consultare http://pastebin.com/sgjQETzM

Nota: 23.1.4.9 è l'indirizzo IP pubblico del connettore del server Exchange 2010 ibrido locale a Exchange Online.

Come possiamo impedire che le e-mail esterne vengano contrassegnate come spazzatura da EOP durante la fase di coesistenza di una distribuzione ibrida?

[Aggiornamento 12-12-2015]

Questo problema è stato risolto dal supporto di Office 365 (il team con escalation / backend) in quanto non ha nulla a che fare con le nostre impostazioni.

Ci è stato suggerito quanto segue:

1. Inserite nella lista bianca l'IP pubblico nell'elenco Consenti EOP (provato. Non ha aiutato).
2. Aggiungi record SPF per il nostro dominio: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY include: spf.protection.outlook.com -all" (Non pensare che questo suggerimento sia valido poiché EOP non dovrebbe controllare gmail.com rispetto al nostro indirizzo IP SMTP poiché non è specificato nei record SPF di gmail.com. Questo non sembra il modo in cui funziona SPF.)
3. Assicurati che TLS sia abilitato (vedi sotto)

La parte chiave è il terzo punto. "Se il TLS non è abilitato, l'e-mail in arrivo da Exchange locale non sarà contrassegnata come e-mail interna / attendibile ed EOP controllerà tutti i record", ha affermato il supporto.

Il supporto ha determinato un problema TLS dalle nostre intestazioni di posta dalla riga seguente:

• X-MS-Exchange-Organization-AuthAs: Anonimo

Ciò indica che TLS non è stato abilitato quando EOP ha ricevuto e-mail. EOP non ha trattato l'e-mail in arrivo come e-mail di fiducia. Quello corretto dovrebbe essere come:

• X-MS-Exchange-Organization-AuthAs: Interno

Tuttavia, ciò non è stato causato dalle nostre impostazioni; l'addetto all'assistenza ci ha aiutato a verificare che le nostre impostazioni fossero corrette verificando i log SMTP dettagliati dal nostro server ibrido di Exchange 2010.

Più o meno nello stesso periodo, il loro team di backend ha risolto il problema senza farci sapere cosa lo ha causato esattamente (sfortunatamente).

Dopo averlo risolto, abbiamo scoperto che le intestazioni dei messaggi avevano alcune modifiche significative come di seguito.

Per la posta di origine interna da Exchange 2003 a Office 365:

• X-MS-Exchange-Organization-AuthAs: Internal (Era "Anonimo")

• SCL = -1 (era SCL = 5)

• Received-SPF: SoftFail (era lo stesso)

E per mail esterne (ad es. Gmail.com) a Office 365:

• X-MS-Exchange-Organization-AuthAs: Anonimo (era lo stesso)

• SCL = 1 (era SCL = 5)

• Received-SPF: SoftFail (era lo stesso)

Anche se il controllo SPF continua a non riuscire per gmail.com (esterno) su Office 365, il tecnico dell'assistenza ha detto che era OK e che tutti i messaggi sarebbero andati nella Posta in arrivo anziché nella cartella Posta indesiderata.

Come nota a margine, durante la risoluzione dei problemi, il team di backend ha riscontrato un problema di configurazione apparentemente minore: avevamo l'IP dal nostro connettore in entrata (ovvero IP pubblico del server ibrido di Exchange 2010) definito nel nostro elenco di indirizzi IP consentiti (suggerito da un altro supporto di Office 365 persona come fase di risoluzione dei problemi). Ci fanno sapere che non dovremmo aver bisogno di farlo e in effetti ciò può causare problemi di routing. Hanno commentato che al passaggio iniziale l'e-mail non veniva contrassegnata come spam, quindi qui c'era anche un possibile problema. Abbiamo quindi rimosso l'IP dall'Elenco indirizzi IP consentiti. (Tuttavia, il problema relativo allo spam esisteva prima che venisse effettuata l'impostazione dell'elenco indirizzi IP consentiti. Non pensavamo che la causa fosse l'elenco di indirizzi consentiti.)

In conclusione, "dovrebbe essere il meccanismo EOP", ha detto la persona di supporto. Pertanto, l'intera cosa dovrebbe essere causata dal loro meccanismo.

Per chiunque sia interessato, il thread di risoluzione dei problemi con una delle loro persone di supporto può essere visualizzato qui: https://community.office365.com/en-us/f/156/t/403396

Sei sicuro che il flusso di posta passi direttamente dal tuo server ibrido a O365?

Quando è stata eseguita la procedura guidata ibrida, avrebbe dovuto creare connettori localmente e in O365, che eseguirà il flusso di posta tra le foreste come posta interna. Ciò significa che ignorerà i controlli EOP / Spam e non dovresti mai vedere quei messaggi SPF.

Se il dispositivo periferico sta modificando le intestazioni, ciò potrebbe causare il problema: tra il server e O365 nulla dovrebbe modificare le intestazioni dei messaggi. Assicurarsi che non si disponga di un connettore esistente che potrebbe sostituire quelli creati dalla procedura guidata ibrida. È sempre possibile eliminare i connettori esistenti creati e rieseguire la procedura guidata per ricrearli.

Controlla le tue regole di trasporto in Exchange e assicurati che non stiano modificando il messaggio prima di andare a O365, se sono disabilitate e prova di nuovo per accertarti che non siano il tuo problema.

Ultimo (o forse prima) verifica che la tua federazione sia configurata correttamente. In caso contrario, potrebbe essere il motivo per cui la tua posta non viene trattata correttamente. Qui è dove rieseguire anche la procedura guidata ibrida può aiutarti.

Non sono un esperto qui, è passato molto tempo da quando ho giocato con Exchange ma cercherò di rispondere al meglio delle mie capacità.

Consente di ignorare la progettazione per un secondo, perché non instradare prima tutto il traffico su EOP e poi sui server Exchange locali? stai perdendo una buona funzionalità lì, sicuramente renderebbe le cose più facili per te controllare lo spam da una singola posizione (supponi che anche il tuo Exchange locale abbia un filtro anti spam).

Ora passiamo al problema dello spam:

1. Flusso di posta e connettori : ho la sensazione che i connettori non siano impostati correttamente, se tutte le e-mail in arrivo sembrano provenire dallo stesso indirizzo IP 23.1.4.9 anziché dall'indirizzo IP del server di posta dei mittenti, per certo che i controlli SPF fallirebbero , poiché lo scopo è verificare l'IP del mittente e il nome di dominio dell'IP del mittente. Dedicherei sicuramente un po 'di tempo a rivedere come sono configurati i connettori, ecco un buon link per questo: https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150 ) aspx
2. Filtri di spam EOP e filtri di connessione : se la configurazione IP dei connettori viene eseguita correttamente, forse è il momento che guardi i tuoi filtri di spam / connessione in EOP, creerei filtri per bypassare il controllo delle e-mail in arrivo dall'IP 23.1.4.9, ma ciò farebbe in modo che tutte le e-mail in arrivo ignorino gli elenchi di controllo del filtro antispam, questo ti porta al problema menzionato nel punto precedente, controlla i tuoi connettori e preferibilmente, instrada prima l'e-mail in arrivo a EOP.