Alle externen E-Mails an Office 365 schlagen fehl, SPF, von EOP in einer Hybridbereitstellung als Junk markiert

Kurz gesagt: legitime E-Mails landen in Junk-Ordnern, wenn EOP (Exchange Online Protection) E-Mail-Nachrichten als Junk (SCL5) und SPF-fehlgeschlagen stempelt. Dies geschieht mit allen externen Domänen (z. B. gmail.com/hp.com/microsoft.com) zur Domäne des Kunden (contoso.com).

Hintergrundinformation:

Wir stehen am Anfang der Migration von Postfächern nach Office 365 (Exchange Online). Dies ist eine Hybrid Deployment / Rich-Coexistence-Konfiguration, bei der:

• On-Premises = Exchange 2003 (Legacy) und 2010 (für die Hybridbereitstellung installiert)
• Off-Premises = Office 365 (Exchange Online)
• EOP ist für die SPF-Prüfung konfiguriert.
• MX-Datensätze verweisen auf die lokalen Daten, da wir nicht alle Postfächer von lokal nach Exchange Online migriert haben.

Das Problem besteht darin, dass EOP eine SPF-Suche und Hard / Soft durchführt, wenn externe Benutzer E-Mails an ein Office 365-Postfach in der Organisation senden (Nachrichtenfluss: Extern -> Mail-Gateway -> lokale Mailserver -> EOP -> Office 365) Fehlerhafte Nachrichten mit der externen IP-Adresse des Mail-Gateways, von dem die Mail empfangen wurde.

(In lokalen Postfächern wird dieses Problem nicht angezeigt. Nur Postfächer, die auf Office 365 migriert wurden, tun dies.)

Eine Illustration:

Beispiel 1: von Microsoft zu 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

Beispiel 2: von HP zu 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

Beispiel 3: von Google Mail zu 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

Informationen zu Nachrichtenkopfzeilen mit X-Forefront-Antispam-Report finden Sie unter http://pastebin.com/sgjQETzM

Hinweis: 23.1.4.9 ist die öffentliche IP-Adresse des lokalen hybriden Exchange 2010-Serverconnectors für Exchange Online.

Wie verhindern wir, dass externe E-Mails während der Koexistenzphase einer Hybridbereitstellung von EOP als Junk markiert werden?

[2015-12-12 Update]

Dieses Problem wurde vom Office 365-Support (dem eskalierten / Backend-Team) behoben, da es nichts mit unseren Einstellungen zu tun hat.

Uns wurde folgendes vorgeschlagen:

1. Whitelist der öffentlichen IP in der EOP-Zulassungsliste (Versucht. Es hat nicht geholfen.)
2. Fügen Sie einen SPF-Datensatz für unsere Domain hinzu: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY include: spf.protection.outlook.com -all" (Dieser Vorschlag ist nicht gültig da EOP gmail.com nicht mit unserer SMTP-IP-Adresse vergleichen sollte, da diese nicht in den SPF-Datensätzen von gmail.com angegeben ist. So scheint SPF nicht zu funktionieren.)
3. Stellen Sie sicher, dass TLS aktiviert ist (siehe unten).

Der Schlüsselteil ist der dritte Punkt. "Wenn das TLS nicht aktiviert ist, werden eingehende E-Mails von lokalem Exchange nicht als interne / vertrauenswürdige E-Mails markiert, und EOP überprüft alle Datensätze", sagte der Support.

Der Support hat ein TLS-Problem in unseren Mail-Headern anhand der folgenden Zeile festgestellt:

• X-MS-Exchange-Organisation-AuthAs: Anonym

Dies zeigt an, dass TLS nicht aktiviert war, als EOP eine E-Mail erhielt. EOP hat die eingehende E-Mail nicht als Vertrauens-E-Mail behandelt. Das richtige sollte sein wie:

• X-MS-Exchange-Organisation-AuthAs: Intern

Dies wurde jedoch nicht durch unsere Einstellungen verursacht. Die Support-Person hat uns dabei geholfen, sicherzustellen, dass unsere Einstellungen korrekt sind, indem sie die ausführlichen SMTP-Protokolle von unserem Exchange 2010-Hybridserver überprüft hat.

Etwa zur gleichen Zeit hat das Backend-Team das Problem behoben, ohne uns (leider) mitzuteilen, was genau es verursacht hat.

Nachdem sie das Problem behoben hatten, stellten wir fest, dass die Nachrichtenkopfzeilen einige wesentliche Änderungen aufwiesen (siehe unten).

Für E-Mails mit internem Ursprung von Exchange 2003 an Office 365:

• X-MS-Exchange-Organisation-AuthAs: Intern (es war "anonym")

• SCL = -1 (Es war SCL = 5)

• Received-SPF: SoftFail (es war das gleiche)

Und für externe Mails (z. B. gmail.com) an Office 365:

• X-MS-Exchange-Organisation-AuthAs: Anonym (es war das gleiche)

• SCL = 1 (Es war SCL = 5)

• Received-SPF: SoftFail (es war das gleiche)

Obwohl die SPF-Prüfung für gmail.com (extern) in Office 365 immer noch fehlschlägt, sagte die Support-Person, dass dies in Ordnung sei und alle E-Mails an den Posteingang anstatt an den Junk-Ordner gesendet würden.

Nebenbei bemerkt, während der Fehlerbehebung stellte das Backend-Team ein scheinbar geringfügiges Konfigurationsproblem fest: Wir hatten die IP von unserem Inbound Connector (dh die öffentliche IP des Exchange 2010-Hybridservers) in unserer IP-Zulassungsliste definiert (vorgeschlagen von einem anderen Office 365-Support) Person als Fehlerbehebungsschritt). Sie lassen uns wissen, dass wir dies nicht tun müssen und dies kann tatsächlich zu Routing-Problemen führen. Sie kommentierten, dass die E-Mail beim ersten Durchgang nicht als Spam markiert wurde, sodass hier auch ein mögliches Problem auftrat. Wir haben dann die IP aus der IP Allow List entfernt. (Das Spam-Problem bestand jedoch bereits vor der Einstellung der IP-Zulassungsliste. Wir dachten nicht, dass die Zulassungsliste die Ursache ist.)

Abschließend "sollte es ein EOP-Mechanismus sein", sagte die unterstützende Person. Daher sollte das Ganze durch ihren Mechanismus verursacht werden.

Für alle Interessierten kann der Thread zur Fehlerbehebung mit einer ihrer Support-Personen hier eingesehen werden: https://community.office365.com/en-us/f/156/t/403396

Sind Sie sicher, dass der Nachrichtenfluss direkt von Ihrem Hybridserver zu O365 erfolgt?

Wenn Sie den Hybrid-Assistenten ausgeführt haben, sollte er lokal und in O365 Konnektoren erstellt haben, die den Nachrichtenfluss zwischen den Gesamtstrukturen als interne E-Mails verarbeiten. Dies bedeutet, dass die EOP / Spam-Prüfungen umgangen werden und Sie diese SPF-Nachrichten niemals sehen sollten.

Wenn Ihr Edge-Gerät die Header ändert, kann dies zu Ihrem Problem führen. Zwischen Ihrem Server und O365 sollten die Nachrichtenkopfzeilen durch nichts geändert werden. Stellen Sie sicher, dass kein Connector vorhanden ist, der möglicherweise die vom Hybrid-Assistenten erstellten Konnektoren überschreibt. Sie können die vorhandenen Konnektoren, die erstellt wurden, jederzeit löschen und den Assistenten erneut ausführen, um sie neu zu erstellen.

Überprüfen Sie Ihre Transportregeln in Exchange und stellen Sie sicher, dass sie die Nachricht nicht ändern, bevor Sie zu O365 wechseln. Wenn sie deaktiviert sind, testen Sie sie erneut, um sicherzustellen, dass dies nicht Ihr Problem ist.

Zuletzt (oder vielleicht zuerst) überprüfen Sie, ob Ihr Verbund richtig konfiguriert ist. Wenn dies nicht der Fall ist, wird Ihre E-Mail möglicherweise nicht richtig behandelt. Hier können Sie auch den Hybrid-Assistenten erneut ausführen.

Ich bin hier kein Experte, es ist sehr lange her, dass ich mit Exchange gespielt habe, aber ich werde versuchen, nach besten Kräften zu antworten.

Lassen Sie uns das Design für eine Sekunde diskutieren. Warum leiten Sie nicht zuerst den gesamten Datenverkehr an EOP und dann an Ihre lokalen Exchange-Server weiter? Wenn Sie dort eine gute Funktionalität verlieren, wird es Ihnen definitiv einfacher, Spam von einem einzigen Ort aus zu kontrollieren (vorausgesetzt, Ihre lokale Exchange verfügt auch über einen Anti-Spam-Filter).

Kommen wir nun zum Spam-Problem:

1. Nachrichtenfluss und Konnektoren : Ich habe das Gefühl, dass die Konnektoren nicht korrekt eingerichtet sind, wenn alle Ihre eingehenden E-Mails von derselben IP-Adresse 23.1.4.9 anstelle der IP-Adresse des Absenderservers stammen, werden die SPF-Prüfungen mit Sicherheit fehlschlagen , da der Zweck darin besteht, die Absender-IP und den Domänennamen dieser Absender-IP zu überprüfen. Ich würde auf jeden Fall einige Zeit damit verbringen, zu überprüfen, wie die Konnektoren eingerichtet sind. Hier ist ein guter Link dafür: https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150 ) .aspx
2. EOP-Spamfilter und Verbindungsfilter : Wenn die IP-Einrichtung der Konnektoren korrekt durchgeführt wurde und Sie möglicherweise Ihre Spam- / Verbindungsfilter unter EOP überprüfen, würde ich Filter erstellen, um das Überprüfen eingehender E-Mails von IP 23.1.4.9 zu umgehen. Dies würde jedoch dazu führen, dass alle eingehenden E-Mails die Spamfilter-Checklisten umgehen. Dies bringt Sie zu dem im vorherigen Punkt erwähnten Problem, überprüfen Sie Ihre Konnektoren und leiten Sie eingehende E-Mails vorzugsweise zuerst an EOP weiter.