blog.atwork.at

news and infos about microsoft, technology, cloud and more

Office 365 – Penetranter Junk-Mail Ordner - Troubleshooting

Ich wurde zuletzt von einem Kunden mit einem interessanten Problem kontaktiert. Der Kunde ist vollständig in Office 365 migriert und hat aktuell keine lokalen Exchange Mailboxen mehr. Ein lokaler Exchange Server wird zwar für Hybrid und Management Zwecke betrieben, hat aber keine sonstige Funktion. Das bedeutet auch, dass der MX-Record auf Exchange Online zeigt und alle Mails direkt von Office 365 empfangen und gesendet werden.

Jetzt wurde ich gefragt, ein Problem zu diagnostizieren das sich folgendermaßen äußert: Zwei Mitarbeiter bekommen ein Mail von einem gemeinsamen Absender zugestellt. Für einen User A landet das Mail in der Inbox und bleibt auch dort. User B bekommt das Mail in den Junk-Mail Ordner zugestellt. Lustiger Test – er kann den Absender auch als Safe Sender markieren oder serverseitig vom Spam Filter ausnehmen. Beides führte nicht zum Erfolg. Mails desselben Absenders landeten bei User B weiterhin im Junk-Mail Ordner. Was dem Ganzen dann die Krone aufsetzt: Schiebt der User das Mail in Outlook zurück in die Inbox wird es wenige Sekunden später wieder in den Junk-Mail Folder zurück geschoben. Ja, diesen Fall hatte ich auch noch nicht. Also mal auf die Suche machen…

Troubleshooting Step 1 – Mail Inbound checken

Der erste Step bei einem solchen Problem ist festzustellen ob man serverseitig sehen kann, warum dieses Mail überhaupt als Spam markiert wurde. In Office 365 kann man sich jetzt über das Web Portal Message Tracing holen und versuchen da etwas zu finden. Ich persönlich bin da etwas mehr... low level orientiert – Powershell muss her.

Auf die Exchange Office 365 Powershell verbinden:

Import-PSSession -Session ( New-PSSession -ConfigurationName 'microsoft.exchange' -ConnectionUri 'https://outlook.office365.com/powershell-liveid/' -Credential (Get-Credential) -AllowRedirection -Authentication Basic ) -AllowClobber | Out-Null

Nachdem man auf die Powershell verbunden ist, kann man mit Get-MessageTrace eine Nachricht suchen. Wie im Bespiel anbei:

image

Mit entsprechenden Parameter auf Get-MessageTraceDetail kann man sich Details dieser Kommunikation ansehen:

Message Trace ID : c7e434d3-fe34-4185-c145-08d37faf40e9
Message ID       : 0E901B09-00C8-41F8-9D27-C6BE19AF53F0@irgendwas.com
Date             : 19.05.2016 06:32:06
Event            : Spam Diagnostics
Action           :
Detail           :
Data             : <root><MEP Name="CustomData" Blob="S:MID=75741748268580" /></root>

Wie man sieht hat die Spam Diagnostics nicht besonders viel zu dieser Message zu sagen. Also – kein Spam aus Serversicht. Hier könnte man sehr detailliert erkennen warum eine Message als Spam erkannt wird. Eine genaue Übersicht gibt es dazu auch in der Technet bei den Spam Headern von EOP.

Troubleshotting Step 2 – Inbox Rules

Oft und leider immer öfter ist aber auch ein Bedienfehler des Users an diesem Phänomen schuld. Die einfachste Lösung ist eine Outlook-seitige Inbox Rule, die diese Message unabsichtlich verschiebt. Also checken wir auch das natürlich.

Das Powershell Commando Get-InboxRule zeigt Rules innerhalb der Mailbox des Users an. In meinem Fall eine Niete – es war keine einzige Inbox Rule vorhanden.

Troubleshooting Step 3 – Mailbox Junk-Mail Configuration

Wir haben zwar im ersten Step schon gelernt, dass eine Serverseitige Spam-Erkennung nicht zugeschlagen hat, aber zur Sicherheit überprüfen wir noch die Junk-Mail Configuration des Users. Dies wird mit dem Powershell CmdLet Get-MailboxJunkEmailConfiguration überprüft.

image

Anhand der BlockSendersAndDomains Liste könnte man einzelne Mailadressen sperren die dann auch in den Junk-Mail Ordner verschoben werden. Dies würde man aber auch schon serverseitig in der Spam Diagnostics sehen. Dafür ist der Wert SFV zuständig. Wird dieser auf BLK gesetzt, so ist die Absender-Adresse auf der Blocklist des Users. (siehe E-Mail Spam Header)

Troubleshooting Step 4 – Audit Logging

Wenn jetzt aus Serversicht keine Spam Detection Methode gegriffen hat, muss dieses Verhalten durch den Client verursacht werden. Aber wie diagnostiziert man sowas? Ganz einfach: Man verwendet das Audit Logging der jeweiligen Mailbox um zu sehen _wer_ diese Message wirklich verschiebt.

Das Audit Logging wird auf der individuellen Mailbox aktiviert. Mit dem Powershell Befehl Set-Mailbox und dem Audit Parametern setzt man dass “move” Operationen für Owner, Delegate oder Administrator auditiert werden sollen. Tun wir das doch einfach mal.

image

Wie man sieht habe ich für alle Audit Optionen Update und Move als Aktion sowie Auditing generell aktiviert. Also warten wir, bis das nächste Mail eintrifft und eventuell den User noch bitten, dass er nochmal explizit die Nachricht aus dem Junk-Mail Ordner in die Inbox zurückschiebt und wartet, ob sie wieder in den Junk-Mail Ordner zurückgeschoben wird. Und wir merken uns die Zeit oder das Subject der Message, damit wir uns in der Suche leichter tun.

FINALLY!

Man glaubt es kaum: Der Fehler ist natürlich wieder aufgetreten und wir können uns anhand des vorher aktivierten Audit Logs nun genau ansehen warum diese Message verschoben wurde.

Mit dem Powershell CmdLet Search-MailboxAuditLog können wir das AuditLog der Mailbox durchsuchen.

Search-MailboxAuditLog -ShowDetails -Identity irgendwer@domain.com -StartDate (get-date).AddDays(-1) -EndDate (Get-Date).AddDays(1)  -Operations move

Gleichzeitig wird StartDate und EndDate angegeben um die Suche einzuschränken. Eigentlich Interessieren uns nur MOVE Operationen. Filtert man das ganze noch etwas genauer nach dem Subject…

$result | ? { $_.sourceitemsubjectslist –eq ‘Subject of Message’ }

…kommt man schnell zu folgendem Output:

image

Das Problem war…

Siehe da: Der Übeltäter ist ein ActiveSync Client der die Message selbst nach manuellem Verschieben durch Outlook zurück in den Posteingang einfach Sekunden später wieder verschiebt. Dann nimmt man sich sein Handy mal zur Brust und schaut, welche Einstellungen hier Messages verschieben oder eventuell welche Absender als Blocked Sender markiert sind.

Fazit

Nicht immer ist ein der Server an einer falsch erkannten Spam Nachricht schuld. Die zweite Erkenntnis ist, dass Audit Logging kann nicht nur zum Ausspionieren von Mitarbeitern verwendet werden kann, sondern hilfreiche Daten zur Fehlersuche liefert. Diese Schritte helfen dem Exchange-Admin zu verstehen, was genau schief geht.

Bis zum nächsten Mal!

LG Christoph

Comments (1) -

  • Uwe Ulbrich

    5/26/2016 9:42:03 AM |

    Der Fall zeigt sehr schön, das Komfort und Management von Email Security auch im O365 Umfeld Erweiterungabedarf hat.  Bisher haben wir onpremise dafür Gateways genutzt.  Das geht auch in der O365 Welt.  Das Gateway darf auch in Azure laufen. Dann hat man eine komplette Cloud Lösung.  Und Junkmail Folder waren unseres Erachtens noch nie eine gute Idee.  Siehe www.nospamproxy.de/.../

  • E0zGYwYba

    7/20/2016 12:45:12 PM |

    882453 858016Howdy! Do you know if they make any plugins to safeguard against hackers? I�m kinda paranoid about losing everything I�ve worked hard on. Any recommendations? 107867

Loading