Sophos Email Message History: Nachrichten verfolgen und Fehler eingrenzen

Message History ist die erste Beweiskette für die Frage, was Sophos Email mit einer Nachricht gemacht hat. Sie unterscheidet verarbeitete Nachrichten von Verbindungen, die wegen eines nicht gefundenen Postfachs abgelehnt wurden. Ein Treffer beweist jedoch nicht allein die Endzustellung: Der letzte Empfängerstatus, der externe Provider-Trace und das Zielpostfach müssen zusammenpassen.

Dieses Runbook behandelt die interaktive Fehlersuche in Sophos Fusion (ehemals Sophos Central). Trendberichte sind ein eigener Auswertungsprozess; automatische Post-Delivery-Bereinigung und programmgesteuerte API-Aktionen sind nicht Bestandteil dieses Ablaufs.

Auftrag, Zugriff und Suchdaten vorbereiten

Man arbeitet mit einem benannten Adminzugang im richtigen Tenant und prüft, dass die Rolle Message History lesen und nur die im Auftrag erlaubten Aktionen ausführen darf. Vor der Suche erfasst man Zeitraum mit Zeitzone, SMTP-Absender und -Empfänger, Betreff, Internet Message-ID beziehungsweise bekannte Sophos-ID, Richtung und den erwarteten Zustellweg Gateway oder Mailflow.

Zusätzlich sichert man den Bounce beziehungsweise die vollständige SMTP-Antwort und, falls vorhanden, den Provider-Trace. Suchfelder verwenden SMTP-Envelope-Adressen, nicht zwingend die sichtbaren From- und To-Header. Bei mehreren Empfängern kann eine Zeile unterschiedliche Empfängerergebnisse enthalten.

Richtigen Bericht und Zeitraum wählen

1. In Sophos Fusion Reports > Email Security Logs > Message History öffnen.
2. Für von Sophos akzeptierte und verarbeitete Nachrichten Processed report wählen. Für wegen eines nicht gefundenen Postfachs abgelehnte Verbindungen Rejected report wählen.
3. Bei gemischten Domains unter Type gezielt Gateway, Mailflow oder alle Typen auswählen.
4. Zeitraum einstellen und danach Refresh klicken.

Standardmässig ist der aktuelle Tag sichtbar. Der auswählbare Verlauf beträgt höchstens 30 Tage; mit einer Sophos Email Plus-Lizenz beträgt er höchstens 90 Tage. Auch ein Export erweitert diesen Zeitraum nicht. Ein älterer Vorgang ist deshalb über den externen Mail-Provider, vorhandene Bounces oder bereits gesicherte Reports zu untersuchen, nicht durch die Annahme, Central müsse ihn noch enthalten.

Im Sophos EMS-Modus scannt Sophos Journal-Kopien und fängt die Originalnachricht nicht ab. Die dort angezeigten Statuswerte dienen nur dem Reporting und bilden den tatsächlichen Zustellstatus des Originals nicht zuverlässig ab.

Verarbeitete Nachrichten gezielt suchen

Im Processed report beginnt man mit Zeitraum und Richtung und grenzt danach über Category, Status, TLS encryption und Type ein. Unter Advanced Search stehen From, To, Subject, Message size, Attachment und DSN code zur Verfügung. Teilstrings sind nicht gross-/kleinschreibungssensitiv; mehrere Kriterien sind logisch mit AND verknüpft. Sonder-, Steuer- und Formatierungszeichen werden bei Suchkriterien ignoriert.

Message size ist die MIME-Grösse und kann wegen der Kodierung deutlich über der Rohdateigrösse liegen. Für DSN code kann man einen vollständigen Code oder die Klassen 2.. für Erfolg, 4.. für temporären Fehler und 5.. für dauerhaften Fehler wählen. Nach einer Änderung von Zeitraum oder Filter muss Refresh ausgeführt werden.

Man vergleicht Direction, Sender, Recipients, Type, Subject, Last Status, Date und Category. Processing oder Queued for Delivery ist kein Endergebnis. Delivery Successful bedeutet, dass Sophos die Nachricht erfolgreich zur Zustellung weitergegeben hat; der abschliessende Beleg kommt aus dem Trace des empfangenden Providers. Delivery Failed, TLS Delivery Failed, Bounced, Failed to return to M365 und Clawback Failed verlangen die Auswertung der Empfängerereignisse.

Details und Empfängerereignisse auswerten

Durch Klick auf den Betreff öffnet man Message Details. Unter Details prüft man SMTP From, SMTP Recipients, Header From, Header Recipients, Category, Sub Category und IP Address. Danach klappt man jede betroffene Empfängerzeile auf und liest die Ereignisse chronologisch: Date, Status, Reason und Additional Details.

Beim Überfahren der drei Punkte stehen zusätzliche SMTP-Daten zur Verfügung, darunter TLS-Nutzung, TLS-Version, Cipher und Hostname des verarbeitenden Mailservers. Der letzte Status muss pro Empfänger bewertet werden; ein erfolgreicher Empfänger widerlegt einen Fehler bei einem anderen nicht. Zeit, Empfänger und SMTP-Antwort werden mit Microsoft Message Trace, Google Email Log Search oder dem Trace des jeweiligen Zielsystems korreliert.

Kategorien erklären die Klassifizierung, nicht automatisch die Ursache einer Zustellunterbrechung. Authentication failure wird anhand der Unterkategorie SPF, DKIM, DMARC, Header anomaly oder Domain anomaly untersucht. Spam, Malware, Intelix threat, URL/QR Code, Impersonation, Data control, Secure message und Legitimate werden mit Sub Category, wirksamer Richtlinie und Ereignisgrund abgeglichen. Realtime blocked, Admin blocked oder User blocked erfordern die Prüfung der passenden Blockquelle.

Bei einer Phish-Threat-Simulationsmail bedeutet Category: Legitimate mit Sub Category: PT campaign, dass Sophos Email die Nachricht als Teil einer Phish-Threat-Kampagne erkannt hat. Das ist noch kein Zustellnachweis. Empfänger und Zeitpunkt mit der Kampagne abgleichen und danach den letzten Empfängerstatus sowie den Provider-Trace prüfen. Fehlt die Mail oder endet der Verlauf nicht erfolgreich, im Runbook Sophos Phish Threat: Zustellungsfehler und Bounces beheben fortfahren.

Header, Anhänge und URLs prüfen

Unter Raw Header kann man mit Copy raw headers die vollständigen Header sichern, über Search keyword nach Namen oder Werten suchen und die Spalten sortieren. AI Analysis wertet nur die Header aus, nicht Inhalt oder Anhänge. Die Zusammenfassung zu SPF, DKIM, DMARC, Alignment, fehlenden Signaturen, Spoofing oder Weiterleitung ist ein Hinweis; Roh-Header und DNS- beziehungsweise Providerdaten bleiben die Grundlage.

Unter Attachments werden Name, MIME-basierte Size und gegebenenfalls File group angezeigt. File group erscheint nur, wenn der Anhang durch eine Data-Control-Richtlinie bewertet wurde. Ein fehlender Wert beweist daher weder einen unbekannten Dateityp noch einen Scanfehler. Anhänge werden nicht auf normalen Adminsystemen geöffnet.

Unter URLs stehen erkannte Links; bei keinem Treffer erscheint No URLs. Export kann diese Liste als CSV oder PDF sichern. Die Liste ist Untersuchungsmaterial und keine Aufforderung, Links anzuklicken. Bei geeigneten Spam-Nachrichten kann Report threat oder Report clean angeboten werden; diese Meldung verbessert die Klassifizierung, ersetzt aber keine unmittelbare Zustellkorrektur.

Grenze der URL-Anzeige: Message Details zeigt nur die Basis-URL an. URL-Parameter werden ausgeblendet, damit sensible oder personenbezogene Werte nicht offengelegt werden. Eine angezeigte URL ohne Query-Parameter beweist deshalb nicht, dass der Link in der Originalnachricht keine Parameter enthielt. Diese Grenze betrifft die Anzeige; daraus lässt sich weder ableiten, dass Sophos Parameter aus der Nachricht entfernt hat, noch welche Bestandteile bei der Sicherheitsanalyse geprüft wurden.

Für den Nachweis hält man fest, ob ein Wert aus Message Details, einem Export oder der Originalnachricht stammt. Ein Screenshot der URL-Liste dokumentiert die Anzeige, nicht den vollständigen ursprünglichen Link. Auch einen CSV-/PDF-Export behandelt man nicht ungeprüft als Originalnachricht: Vor der Weitergabe Inhalt und Umfang kontrollieren, statt eine vollständige URL oder eine bestimmte Parameter-Unterdrückung im Export anzunehmen. Benötigt die konkrete Untersuchung den ursprünglichen Link, wertet man die autorisiert gesicherte .eml-Nachricht als Text in einer dafür vorgesehenen Untersuchungsumgebung aus, ohne Links aufzurufen oder Anhänge zu öffnen.

Für Tickets und Screenshots genügt zunächst die angezeigte Basis-URL zusammen mit Message-ID, Zeitpunkt und Empfängerereignis. Vollständige Links und Query-Werte sammelt man nur, wenn sie für die konkrete Fehlerfrage nötig und ihre Verarbeitung freigegeben ist. Tokens, personenbezogene Parameter und nicht benötigte Nachrichtendaten werden in der Ticketkopie geschwärzt; ein erforderliches Original bleibt getrennt und zugriffsbeschränkt erhalten. Vollständige verdächtige Links gehören nicht in öffentliche URL-Prüfdienste, Chats oder ungeschützte Tickets.

Ablehnungen und SMTP-Antworten untersuchen

Der Rejected report ist auch der Rejection Log. Er enthält ausschliesslich Nachrichten, die wegen eines nicht gefundenen Postfachs abgelehnt wurden, sowie die dazu aufgezeichneten Gründe wie Mailbox not found, TLS failure, Version mismatched oder Unencrypted. Man filtert über Rejection Reason oder sucht unter Advanced Search nach From, To und Sender Ip; nach jeder Änderung folgt Refresh.

Harte Grenze: Eine abgelehnte Nachricht wird von Sophos nicht quarantänisiert oder aufbewahrt. Sie kann deshalb weder freigegeben noch erneut gesendet werden. Der Absender muss nach Korrektur von Empfänger, TLS oder Routing neu senden. Erkennt Sophos mehr als 1'000 Nachrichten derselben IP innerhalb von fünf Minuten, pausiert die weitere Protokollierung dieser IP vorübergehend, erzeugt einen Alert und nimmt sie nach fünf Minuten wieder auf. Eine Lücke im Rejection Log kann daher Drosselung bedeuten und beweist nicht, dass keine Verbindungsversuche stattfanden.

Bei einem temporären 4xx-Fehler gilt exakt dieser Rhythmus: Der erste Zustellversuch erfolgt sofort, der zweite ebenfalls sofort, danach folgen Versuche nach 5, 10 und 15 Minuten. Anschliessend versucht Sophos die Zustellung eine Stunde lang alle 30 Minuten und danach stündlich. Nach 24 Stunden beendet Sophos die Versuche und sendet einen Bounce. Ein fataler 5xx-Fehler wird nicht erneut versucht.

Der exakte Sophos-Antwortcode bestimmt die Korrektur:

Reports speichern, planen und exportieren

Nach dem Setzen und Prüfen der benötigten Filter wählt man Save as Custom Report. Beim Processed report wird damit auf der Seite Reports ein benutzerdefinierter Report aus dem Template Message History gespeichert; beim Rejected report wird das Template Email Rejection Report verwendet. Den gespeicherten Custom Report unter Reports öffnen und dort Zeitplan und Empfänger konfigurieren.

Für einen gefilterten Ablehnungsnachweis stellt man einen Zeitraum von höchstens 30 Tagen beziehungsweise mit Sophos Email Plus höchstens 90 Tagen ein, setzt Rejection Reason und gegebenenfalls Advanced Search, klickt Refresh und prüft das Ergebnis. Danach Export as CSV wählen. Die heruntergeladene CSV enthält alle zum Exportzeitpunkt angewendeten Filter; Zeitraum und Zeitzone werden mit dem Nachweis dokumentiert.

Korrektur sicher auswählen und validieren

Redeliver email ist nur mit Sophos Email Plus für von Sophos erfolgreich akzeptierte eingehende Nachrichten der letzten 90 Tage und nur bei unterstütztem Status verfügbar: Delivery Successful, Delivery Failed, Returned to M365, Failed to Return to M365, Clawback released oder TLS Delivery failed. Abgelehnte Nachrichten sind nie zulässig. War die Nachricht schon erfolgreich zugestellt, erzeugt die Redelivery eine neue E-Mail mit dem Original als Anhang; mögliche Duplikate werden vorab berücksichtigt.

Initiate clawback wird nur für erfolgreich zugestellte eingehende Nachrichten in Postfächern einer für Post-Delivery Protection verbundenen Domain verwendet, wenn On demand clawback aktiviert ist. Das Ergebnis wird pro Empfänger unter Additional Details bis Clawback Successful oder Clawback Failed verfolgt und anschliessend in der Post-Delivery-Quarantäne geprüft. Die Provider-Verarbeitung kann bis zu zehn Minuten dauern. Eine Nachricht oder interne Kopie kann nur einmal zurückgezogen werden; nach Freigabe aus der Post-Delivery-Quarantäne ist kein zweiter Clawback möglich.

Nach einer Korrektur führt man dieselbe Suche erneut aus und validiert Nachricht, Empfänger und Endstatus gegen den externen Trace und das Zielpostfach. Eine verschwundene Zeile allein ist kein Erfolgsbeleg: Zeitraum, Filter oder Aufbewahrungsgrenze können denselben Effekt erzeugen.

Typische Fehlerbilder eingrenzen und eskalieren

• Kein Treffer: Tenant, Bericht, 30-/90-Tage-Grenze, Richtung, Type, Envelope-Adresse und Refresh prüfen; Kriterien einzeln entfernen.
• Eingehende Richtlinie scheint unwirksam: Empfängerereignis und zugewiesene Richtlinie vergleichen, danach User- und Admin-Einträge in Inbound Allow/Block prüfen. Keine breite Ausnahme als Diagnose setzen.
• Zustellung steht in Queue: 4xx-Antwort und nächsten Versuch beobachten; bei 5xx Empfänger-, Authentifizierungs-, TLS-, Grössen- oder Rate-Limit-Ursache korrigieren und einen neuen Versand veranlassen.
• Delivery Successful, aber Empfänger hat nichts: Zeit und Message-ID im Provider-Trace suchen und dortige Quarantäne, Regel, Weiterleitung oder Postfachzustand prüfen.
• UCEPROTECT-Ablehnung: den ablehnenden Empfänger beziehungsweise dessen Betreiber kontaktieren und bitten, UCEPROTECT nicht als RBL, DNSBL oder IP-Prüfung zu verwenden. Nicht für kostenpflichtiges Delisting zahlen.
• Urteil vermutlich falsch: für Sophos Email bevorzugt Smart Banners, Message History oder das Sophos Outlook Add-in verwenden; sofern angeboten in den Details Report threat oder Report clean wählen.

Für die Eskalation sammelt man Tenant-ID, UTC-Zeitfenster, SMTP- und Header-Adressen, Betreff, Message-ID, Richtung, Type, Kategorie und Unterkategorie, vollständige Empfängerereignisse, SMTP-/DSN-Code, Roh-Header, Provider-Trace, Richtlinienname und Screenshots. Bei einer scheinbar unwirksamen Richtlinie ergänzt man die zugestellte Nachricht im .eml-Format gemäss Datenschutzvorgaben und den bisherigen Verlauf. Passwörter, Tokens und unnötige Nachrichtendaten gehören nicht in das Ticket.