[English]Kurze Frage in die Runde der Administratoren von Exchange Online. Ein Leser berichtet von Problemen bei der Zustellung von Mails, die von On-Premises Exchange-Servern zugestellt werden. Diese sollen seit dem November 2023-Patchday nach der Annahme direkt in Quarantäne verschoben werden. Der Empfänger der E-Mails bekommt diese also niemals in seinem Exchange Online-Postfach zugestellt.
Anzeige
Exchange Online blockt Mails
Blog-Leser Björn hat sich per Mail bei mir gemeldet, weil er von diversen Kundensystemen Probleme mit der Mail-Zustellung auf Exchange Online gemeldet bekommen. Hier die Kernpunkte:
- Mails von On-Premises Microsoft Exchange-Servern werden zwar von Exchange Online angenommen.
- Auf Exchange Online werden solche Nachrichten direkt in Quarantäne verschoben.
- E-Mails, die über denselben MTA gehen, jedoch deren Urspung nicht Microsoft Exchange-Server ist (dovecot / postfix / roundcube) gehen problemlos durch.
Das Problem tritt seit dem letzten Patchday (14. November 2023) auf. Der Leser hat mir noch einen Header der betreffenden Mails zukommen lassen.
X-MS-Exchange-Organization-SCL: 5 X-Forefront-Antispam-Report: CIP:212.53.151.***;CTRY:DE;LANG:en;SCL:5;SRV:;IPV:NLI;SFV:SPM;H:sg1ms1.****.de;PTR:sg1ms1****.de;CAT:SPM;SFS:(13230031)(230922051799003)(451199024)(336012)(36756003)(564344004)(86362001)(7636003)(7596003)(356005)(3480700007)(6916009)(8676002)(1096003)(7116003)(19618925003)(5660300002)(19627405001)(22186003)(108616005)(24736004)(26005)(2616005)(58800400005);DIR:INB; X-Microsoft-Antispam: BCL:0;
Gemäß diesem Microsoft Support-Dokument werden die Nachrichten als SPAM klassifiziert. Der Leser fragte, ob mir diesbezüglich die Tage was untergekommen sei, was ich aber verneinen musste. Bei einer kurzen Suche bin ich auf diese Diskussion bei administrator.de gestoßen, wo vor einem Jahr ein Fall aufgetreten ist, dass alle Mails im SPAM-Filter hängen blieben. Dort gab es den Hinweis, Microsoft zu kontaktieren.
Meine Gedanken dazu
Ad hoc gingen mir zu diesem Thema verschiedene Gedanken durch den Kopf. Das reicht von einem Bug in Exchange bis hin zu den angekündigten Sicherheitsregeln, um unsichere Exchange-Server aus dem Verkehr zu ziehen.
Anzeige
Ein Bug im Oktober 2023
Zum 11. Oktober 2023 kam es bei Exchange Online zu einer schweren Störung des Mail-Verkehrs. Mehrere Leser berichteten von Problemen beim Empfang von E-Mails von externen E-Mail-Adressen. Dort war eine eine fehlerhafte SPAM-Regel, die Microsoft ausgerollt hatte, die alle Nachrichten in der Zustellung blockiert. Ich hatte im Beitrag Exchange Online: Störung EX680695 (11.10.2023) berichtet. Eine ähnliche Meldung ist mir bisher noch nicht untergekommen.
Exchange Online blockt gezielt Mails
Spontan ging mir auch das zweite Thema durch den Kopf: Microsoft will ja die Mail-Annahme von unsicheren On-Premises Exchange Servern unter Microsoft Exchange Online blockieren. Dazu gab es im Frühjahr 2023 eine Ankündigung, bei der eine neue Sicherheitspolitik für Exchange Online vorgestellt wurde, mit der die Annahme von E-Mails von unsicheren On-Premises Exchange Servern (in hybriden Umgebungen) geblockt werden. Die betreffenden Administratoren erhalten eine Mitteilung, dass der On-Premises Exchange Server angreifbar sei. Wird binnen 90 Tagen nicht reagiert, verweigert Exchange Online die Annahme weiterer E-Mails.
Damit sollen künftig vor allem aus dem Support gefallene Systeme mit On-Premises Exchange Server 2007, 2010 und ab April 2023 auch 2013 eliminiert werden. Ich hatte beispielsweise im Blog-Beitrag Exchange Online blockt Mails von On-Premises Exchange Servern mit Schwachstellen über diesen Ansatz berichtet. Und im Mai 2025 ist Microsoft mit diesem Ansatz gestartet (siehe Exchange Online: Blockierung von Mails von ungepatchten Exchange-Systemen gestartet). Das passt aber auch nicht so recht zu obigem Thema, da die Administratoren der On-Premises Exchange-Server eine Rückmeldung von Exchange Online erhalten sollen, dass die Mail-Annahme verweigert wurde.
Ergänzende Informationen des Betroffenen
An dieser Stelle erst einmal mein Dank für die zahlreichen Vorschläge aus der Leserschaft. Der betroffene Administrator hat sich inzwischen mit zwei Nachträgen gemeldet, die ich hier nachtrage.
Kein unsicherer Exchange Server
Ich hatte ja in obigem Text das Thema Exchange Online: Blockierung von Mails von ungepatchten Exchange-Systemen gestartet angerissen, schrieb aber, dass ich dieses Szenario vom Fehlerbild als nicht plausibel einstufe. Die gleiche Vermutung wurde auch auf Facebook von einem Administrator an mich herangetragen. Björn hat sich diesbezüglich nochmals gemeldet und schrieb dazu:
Das Verhalten tritt von verschiedenen on-prem Exchange-Servern als sendendes System auf.
Einer der on-prem Exchange ist unser, der ist komplett durchgepatcht und Healthchecker sagt, alles grün bis auf Extentended Protection. Die werden wir demnächst aktivieren.
Geht aus den Headern hervor, ob Extentended Protection aktiv ist?
Das ist also nochmals die Negation, dass die neue Sicherheitsfunktion von Exchange Online geplant was blockiert. Zur letzten Frage hinsichtlich der Extentended Protection kann ich selbst wenig sagen.
Björn hat mir dann noch den vollständigen Header in einer von ihm anonymisierter Form per Mail zukommen lassen, den ich nachfolgend einstelle.
Received: from PAXPR08MB7419.eurprd08.prod.outlook.com (2603:10a6:102:2ba::11) by DU2PR08MB7237.eurprd08.prod.outlook.com with HTTPS; Mon, 20 Nov 2023 13:55:22 +0000 Received: from DB3PR06CA0018.eurprd06.prod.outlook.com (2603:10a6:8:1::31) by PAXPR08MB7419.eurprd08.prod.outlook.com (2603:10a6:102:2ba::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.27; Mon, 20 Nov 2023 13:55:20 +0000 Received: from DU2PEPF0001E9C4.eurprd03.prod.outlook.com (2603:10a6:8:1:cafe::3a) by DB3PR06CA0018.outlook.office365.com (2603:10a6:8:1::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.27 via Frontend Transport; Mon, 20 Nov 2023 13:55:20 +0000 Authentication-Results: spf=pass (sender IP is *.*.*.*) smtp.mailfrom=***.eu; dkim=none (message not signed) header.d=none;dmarc=bestguesspass action=none header.from=***.eu;compauth=pass reason=109 Received-SPF: Pass (protection.outlook.com: domain of ***.eu designates *.*.*.* as permitted sender) receiver=protection.outlook.com; client-ip=*.*.*.*; helo=***.***.de; pr=M Received: from ***.***.de (*.*.*.*) by DU2PEPF0001E9C4.mail.protection.outlook.com (10.167.8.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.12 via Frontend Transport; Mon, 20 Nov 2023 13:55:19 +0000 Received: from localhost (localhost [127.0.0.1]) by ***.***.de (Postfix) with ESMTP id 0E85B340517 for <info@***.de>; Mon, 20 Nov 2023 14:55:19 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ***.***.de Received: from ***.***.de ([127.0.0.1]) by localhost (***.***.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id qLMryEdIhwbD for <info@***.de>; Mon, 20 Nov 2023 14:55:18 +0100 (CET) Received: from ***.***.eu (***.dip0.t-ipconnect.de [*.*.*.*]) (Authenticated sender: relay@***.de) by ***.***.de (Postfix) with ESMTPSA id CA8473401A0 for <info@***.de>; Mon, 20 Nov 2023 14:55:18 +0100 (CET) Received: from [192.168.1.229] (port=14294 helo=***.***.eu) by ***.***.eu with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <***@***.eu>) id 1r54k8-0004Vc-2A for info@***.de; Mon, 20 Nov 2023 14:55:16 +0100 Received: from ***.***.local (192.168.1.229) by ***.***.local (192.168.1.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Mon, 20 Nov 2023 14:56:54 +0100 Received: from ***.***.local ([fe80::60e6:1863:5d32:509e]) by ***.***.local ([fe80::60e6:1863:5d32:509e%4]) with mapi id 15.01.2507.023; Mon, 20 Nov 2023 14:56:54 +0100 From: *** <***@***.eu> To: "info@***.de" <info@***.de> Subject: Test Thread-Topic: Test Thread-Index: AQHaG7lrVU0/tkXu1Eu4jckar5Dqsg== Date: Mon, 20 Nov 2023 13:56:53 +0000 Message-ID: <1c8c4c5fc2ed409db57c72c44e8424a4@***.eu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.242.2.10] Content-Type: multipart/alternative; boundary="_000_1c8c4c5fc2ed409db57c72c44e8424a4***eu_" MIME-Version: 1.0 Return-Path: ***@***.eu X-MS-Exchange-Organization-ExpirationStartTime: 20 Nov 2023 13:55:19.5843 (UTC) X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000 X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit X-MS-Exchange-Organization-Network-Message-Id: 0a81698e-827c-44f8-e757-08dbe9d05540 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 32c17c4d-863b-4a0c-a8bb-012f38c616e8:0 X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PEPF0001E9C4:EE_|PAXPR08MB7419:EE_|DU2PR08MB7237:EE_ X-MS-Exchange-Organization-AuthSource: DU2PEPF0001E9C4.eurprd03.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Office365-Filtering-Correlation-Id: 0a81698e-827c-44f8-e757-08dbe9d05540 X-MS-Exchange-Organization-SCL: 5 X-Forefront-Antispam-Report: CIP:*.*.*.*;CTRY:DE;LANG:en;SCL:5;SRV:;IPV:NLI;SFV:SPM;H:***.***.de;PTR:***.***.de;CAT:SPM;SFS:(13230031)(230922051799003)(451199024)(336012)(36756003)(564344004)(86362001)(7636003)(7596003)(356005)(3480700007)(6916009)(8676002)(1096003)(7116003)(19618925003)(5660300002)(19627405001)(22186003)(108616005)(24736004)(26005)(2616005)(58800400005);DIR:INB; X-Microsoft-Antispam: BCL:0; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2023 13:55:19.3968 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0a81698e-827c-44f8-e757-08dbe9d05540 X-MS-Exchange-CrossTenant-Id: 32c17c4d-863b-4a0c-a8bb-012f38c616e8 X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF0001E9C4.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7419 X-MS-Exchange-Transport-EndToEndLatency: 00:00:03.4629586 X-MS-Exchange-Processed-By-BccFoldering: 15.20.7002.027 X-Microsoft-Antispam-Mailbox-Delivery: ucf:0;jmr:0;auth:0;dest:J;OFR:SpamFilterAuthJ;ENG:(910001)(944506478)(944626604)(920097)(930097)(3100021)(140003);RF:JunkEmail;
Vielleicht fällt noch jemand aus der Leserschaft was dazu ein.
Ursache bleibt weiter unklar
Interessant fand ich in den nachfolgenden Leserkommentaren den Hinweis, dass in Mails integrierte QR-Codes Auslöser für eine Quarantäne sein könnten. Auch hier hat sich Björn in einem Nachtrag per Mail geäußert.
Das Thema QR-Code wurde nach dem Hinweis sofort geprüft. Dazu schreibt Björn "Das habe ich natürlich auch gesehen und sofort geprüft. Sie haben zwar Bilder und Links in der Signatur, aber keine QR-Codes."
Der Hinweis erwiest sich hier also als Sackgasse. Der Leser ergänzte dann in der Mail noch folgende Erkenntnisse:
Was ich total nervig finde, und womit ich nicht weiter komme, ist dass beim Empfänger (sofern man Zugang dazu hat, was sehr selten ist) ich unter:
*ttps://security.microsoft.com/quarantine
die E-Mails sehe, jedoch nur sehr allgemeine Gründe für die Abweisung bekomme:
- Grund für Quarantäne: Nachricht mit hoher Phishingwahrscheinlichkeit
- Richtlinientyp: Antispamrichtlinie
- Richtlinienname: Default
Wenn man dann in die Header-Analyse geht, dann landet man immer wieder bei den "Spam rules", z.B.
(13230031)(7916004)(230922051799003)(230173577357003) (230273577357003)(451199024)(1690799017)(6916009)(58800400005) (19627405001)(26005)(336012)(36736006)(7636003)(7596003)(356005) (166002)(6506007)(6512007)(6486002)(966005)(33964004)(6666004) (9686003)(8676002)(22186003)(1096003)(5660300002)(3450700001) (33716001)(9316004)(76236004)(83170400001)(76899018)(131040200001)Aber es ist überhaupt nicht klar, welche Regel gegriffen hat und was welche Regel macht. Dort komme ich nicht weiter.
Unabhängig davon haben wir zwischenzeitlich DKIM bei dem Kunden eingerichtet und nun nimmt Exchange Online die E-Mail mit einem SCL von 1 an.
Auf jeden Fall Danke für Ihre Mühe! Ich wüsste echt gern, was die Ursache ist.
Den Dank des Betroffenen muss ich an die Leserschaft für die Beteiligung an der Diskussion weiter geben. In der Sache sind wir aber kein Stück weiter gekommen – Exchange Online bleibt in dieser Beziehung wohl eine Black Box, oder?
Ergänzung: Auf Mastodon hat sich Henning gemeldet und schreibt: Ist bei unseren Kunden auch vorgekommen. Hängt mit dem Content Filtering von Exchange Online Protection zusammen. Die URLs müssen wohl einzeln über einen Case freigeschaltet werden.
Ergänzung 2: Aktuell ist unklar, ob es mit rein spielen kann. Gerade bin ich auf einen Facebook-Post von Frank Carius gestoßen, der den Artikel OrganizationConnector und Spamfiltererwähnt, den sollte man auf jeden Fall berücksichtigen.
Anzeige
"bis hin zu den angekündigten Sicherheitsregeln, um unsichere Exchange-Server aus dem Verkehr zu ziehen."
gute Idee, aber Microsoft wird ja wohl kaum so vollständig inkompetent sein und emalis von solchen kaputten Server anzunehmen und nach der Annahme als "Spam" dem Zugriff und wissen des rechtmäßigen Empfängers zu entziehen und darauf hoffen(!) das der Admin des kaputten Servers schon reagieren wird (wäre er kein kompletter Depp, wäre sein Server korrekt gepatcht, oder?) oder der Admin des Servers des Empfängers die false positives schon aus der Quarantäne holen wird. sofern irgendwo auffällt, dass der Kunde seit Monaten seine Rechnungen nicht bezahlt, nicht auf Mahnungen reagiert…
Der Admin des Empfängers at ja sonst nix zu tun. In der Cloud wäre das ja nicht passiert..lasst uns wechseln.
Wenn man solche Belehrungsaktionen meint durchführen zu müssen, gibt man dem ablieferndem Server schon nach dem eHELO ein klares "550 Email rejected. see ms-kb081515" aber kein "220 Received" am Ende der Email um sie dann wegzuwerfen.
Wobei ich mich frage, wenn MS erkennen kann, dass der Server anfällig ist, kann das doch auch jeder Angreifer, oder?
Das 550 reject bekommt der Absender sofort als NDR in sein Postfach, kann dem Kunden anrufen/faxen und den Admin falten, emm informieren.
So ein Problemchen gab es vor Jahren schon Mal.
Zum einen bei Firmen die über eine billige Dialup IP Adresse Email versenden wollten, wie auch die Spammer heute noch oder bei Servern mit feste IP besaßen, aber keinen passenden Reverse DNS was erfahrungsmässig auf ein generell schlecht gewartetes System hinweist.
Damals ist keiner auf die Idee gekommen, die E-Mails nicht zu rejecten, sondern anzunehmen und nach /dev/null umzuleiten…absurde Idee.
ich hoffe sehr dass MS nicht so völlig verblödet ist, sondern dass die Ursache woanders liegt (was wir nie erfahren werden,wie üblich)
Von wem ich E-Mails empfangen möchte darf ich bestimmen.
Wenn ich kein E-Mails von chinesischen IP Adressen annehmen will, dann ist das mein Gutes Recht.
Und wenn wer meint, den lokal Part meiner eMail Adresse "pau1" schreiben zu müssen, obwohl RfC sagt, das dieser Teil der Adresse casesensitive behandelt werden muss, dessen emails möchte ich auch nicht sehen.
Aber das der Lieferant einer E-Mail-Software das entscheidet lassen sich nur Microsoft Kunden gefallen.
Sind MS-Kunden nur für hilflose Luschen?
Case sensitive ist so eine unnötige Einschränkung, dass man darauf zurecht meist keine Rücksicht nimmt. Aber, aber, RFC sagt das!
Ist wie dieses andauernde "www.example.org" und "example.org" sind zwei verschiedene Dinge!
Ja. RFC sagt das. Wird aber so nicht gelebt. Kann ja jeder Serverbetreiber für sich selbst entscheiden.
Ich gebe Admon Recht. Der durchschnittliche Nutzer von E-Mail geht davon aus, dass es Wurst ist, ob eine Mailadresse Groß- oder Kleinbuchstaben enthält. Und die meisten Mailserver stellen Mails ohne Probleme an "das eine" Postfach zu, egal ob Groß- oder Kleinbuchstaben enthalten sind.
Nun kann man als IT-Nerd oder verantwortlicher IT-Mensch darauf beharren, dass das einen Unterschied macht, und seinen Mailserver entsprechend konfigurieren. Aber man schafft sich dadurch keine Freunde.
Ich empfehle zu diesem Thema den Mitschnitt eines Vortrags von Dylan Beattie auf der NDC Oslo 2023. Er hat sich mit dem Thema RFCs und Mailadressen (auch auch technischen Aufbau von Mails) beschäftigt und bringt das wie gewohnt sehr unterhaltsam rüber:
https://www.youtube.com/watch?v=mrGfahzt-4Q
Auf so einigen Handwerker Fahrzeugen stehen E-Mail Adressen in reinen Grossbuchstaben oder GrossKlein z.B. KlimaMayer@Yahoo.de usw.
Das ist aber (hoffentlich) nur der besseren Lesbarkeit geschuldet. Nur Großbuchstaben ist wohl eher designbedingt.
DiesIstEineSehrL@ngeEmailAdresse
ist einfacher zu lesen als
DIESISTEINESEHRL@NGEEMAILADRESSE
oder
diesisteinesehrl@ngeemailadresse
Die Alternative wären Minuszeichen als Trenner oder Punkte. Der Unterstrich ist wenn ich mich recht erinnere nicht erlaubt.
Den Mailserver hingegen würde ich niemals auf case sensitive konfigurieren, das sorgt nur für Ärger.
also ein generelles Problem ist es nicht. Ich setze nur auf On-Prem, Cloud kommt mir nicht ins System und meine Mails kommen an… spielt also zumindest die Konfiguration noch mit rein. Vielleicht ist das System ja tatsächlich infiltriert und landet korrekterweise in Quarantäne. Wäre nicht der erste Admin der nicht bemerkt das seine Systeme nicht mehr unter seiner alleinigen Kontrolle stehen.
Einfach mal sämtliche X-Header des Exchanges vor der finalen Übermittelung entfernen und prüfen, ob dadurch die E-Mails wieder ankommen. Exchange on-prem bis Version 2016 bietet hierfür allerdings leider keine einfache integrierte Lösung. Bei 2019 weiß ich es nicht. Wenn man einen SMTP-Proxy (z.B. einer Firewall Appliance) als Last-Hop einsetzt, dann würde ich dort mit der Headermanipulation ansetzen.
Ich kann bei unserem Exchange Online in der Quarantäne keine solche geblockten Mails erkennen. Hier liegt "nur" der übliche Spam (Gewichtsverlust, Hochdruckreiniger (mal was neues) und der afrikanische Prinz).
Das mit der Quarantäne als "Lösung" verstehe ich immer nicht.
Entweder ich nehme eine Mail an und damit ist sie "zugestellt" und in meinem Einflussbereich, mit allen rechtlichen Folgen.
Oder ich weise eine Mail ab, womit sie "nicht zugestellt" ist und der Ball beim Sender bleibt.
Aber eine Mail annehmen, dem Absender ein "zugestellt" als Argument in die Hand geben und dann die Mail aber nicht dem Bearbeiter anzeigen, erscheint mir nicht sehr hilfreich für das eigene Unternehmen.
Wenn man das so macht, hat man dann ein Prüfteam und strenge Regeln, wie schnell das zum Bearbeiter weiter muss? Was macht man dann mit Mails, die man nicht dem Bearbeiter weiterreicht? Zum Beispiel mit der von Willi Kunterbunt, in dessen Kündigungsdokument ein gefährliches Skript schlummert? Kann man die einfach löschen oder hat der trotzdem rechtmäßig gekündigt? Oder macht man dann eine Aktennotiz, warum man das nicht bearbeitet hat, damit man da keine Probleme bekommt? Oder nimmt man das einfach locker und weg ist halt weg und dann wird schon alles irgendwie passen?
Annehmen oder Abweisen als einzige Alternativen erscheint mir irgendwie einfacher. Und der normale Sender bekommt dann wenigstens sofort mit, dass es ein Problem gibt.
Gut. Web- und Massensendedienste scheinen abgewiesene Mails dann einfach zu vergessen und melden dem Sender eine Nichtzustellung wohl nicht zurück. Wie es ordentliche Spamsender halt tun. Aber, deren Probleme wären mir ja vergleichsweise egal.
Habe über unserem On-Prem Exchange Server 2016 mit dem November Update eine Mail an ein Postfach auf einer O365 Instanz gesendet und die Mail ist normal im Postfach angekommen. Keine Klassifizierung als Spam.
Das Problem habe ich auch bei einem Kunden, der EX2019 OnPrem hat und seit dem 24.10 anscheinend Probleme mit einigen Empfängern hatte, die seine Mails nicht mehr bekommen haben. Es hat etwas gedauert, bis es klar war, dass diese Empfänger alle MS 365 Postfächer haben. Auch hier kamen keine NDRs zurück. Der Kunde sendete seine Mails nicht direkt vom internen EX2019-Server sondern über den Ionos-Mailserver.
Der Ionos-Mailserver hatte die ausgehenden Mails anstandslos angenommen und offensichtlich auch weitergeleitet. Der Support von Ionos war hier wenig kooperativ (wie sollte man hier sehen, was danach passiert…). Es hat sich herausgestellt, dass die Mails beim Empfänger in der Quarantäne landeten und der Empfänger hatte so keine Chance (ohne seinen Admin) etwas davon zu bekommen… Aber warum passierte das? Ganz einfach: QR-Code in der Mail-Signatur des Absenders! Ich hatte mich gewundert, dass einige Test-Mails doch durchkamen. Sie waren zwar mit dem selben Attachments, mit dem selben Subject und Body-Text gesendet, aber notgedrungen mit OWA von mir erstellt und hier hatte ich die Standardsignatur den Kunden nicht eingepflegt!
Der QR-Code, der einfach als Kurzlink (auch ein Problem!!) für Mobilgeräte auf die WEB-Seite des Kunden gezeigt hat, hat nach dem 24. Oktober bewirkt, dass die Mails auf dem MS-Mailserver direkt in Quarantäne landeten. Anscheinend hat Microsoft dies silently ab dem 24. Oktober einfach aktiviert, um die QR- Quisching Attaken zu unterbinden. Denn, ohne den QR-Code in der Signatur kamen alle Mails wieder bei allen MS 365 Postfächer wieder an!
Unter security… ms … com – email – überprüfen – quarantäne, müssten die Mails aufgelistet sein und genau drin stehen, wieso diese als Spam klassifiziert wurden.
Allenfalls liegt ein Konfig Fehler mit den Konnektoren vor oder eine IP ist auf einer Blacklist gelandet. Einfach mal aus einer Laune raus wird die SCL nicht hochgestuft.
Es gibt regelmäßig Mails die hier als Inhaltsspam deklariert werden, was an dem Inhalt jedoch diese Vermutung auslöst ist meines Wissens nach von MS nirgends dokumentiert
Klar das MS nicht dokumentiert auf welche Inhalte sie triggern.
Stiftung Warentest verrät ja auch nicht, wie sie Fahrradschlösser testet. Sie würde ja die Diebe schlau machen…?
Das ist halt der Nachteil, wenn man keinen eigenen Server betreibt. uups. Es geht hier um Probleme Just bei on-prem Servern. Das ist ja seltsam.
Hast Du Dir Mal die Email im Source code angesehen?
Vielleicht ist das Multipart oder es werden Sachen vor dem Blick des Users verborgen.
Aber "eigentlich" sollte der Spam Filter schon sagen warum das Spam istm Das darf natürlich kein Geheimnis sein.
Hallo Tom,
kannst Du den Punkt
-> Unter security… ms … com – email – überprüfen – quarantäne
genauer definieren? Admin-Center? Exchange-Admin? OWA? Outlook? Wo soll das im Detail angezeigt werden?
Bis jetzt haben wir nur die Header mit dem Regelnummern – die uns nicht weiterbringen.
Danke!
Wir haben leider keine Lösung und genauere Erkenntnisse, können aber bestätigen das wir aktuell auch mit dem Problem kämpfen. Einige unserer E-Mails kommen bei einigen unserer Kunden die O365 nutzen nicht an bzw. landen dort als Phishing-Versuch im Spamfilter.
ja, das ist das größte Gesetz des Internets.
Sei Konservativ in dem was Du sendest, und tolerant mit dem was Du empfängst.
Es ist natürlich wenig sinnvoll eine Regel anzuwenden die kaum ein Benutzer noch kennt. Aber die Software hält sich meist daran.
Dem stimme ich nicht zu. Mein Haus, Meine Hausordnung.
Wer mit "DOC"-Dateien sendet, bekommt einen REJECT.
Ich bin aber bei dir, wenn man sagt: Keine Quarantäne und keine unerkannten Unzustellbarkeiten :-)
Ich habe es gerade mal probiert.
Exchange 2019 jedoch mit NoSpamProxy dahinter aber alles onPrem. Keine Probleme mit der Zustellung an MS365.
CIP:212.53.151.***;CTRY:DE;LANG:en;SCL:5;SRV:;IPV
212.53.151.0 ist in einem /17 AS eines einzigen Providers in Norddeutschland.
Entweder liegt der Block fast komplett brach oder der DNS hat ein Problem den PTR, reverse DNS Eintrag zu liefern oder das Tool ist kaputt.
Wie schon geschildert, ist es inzwischen tabu, eMails von Servern zu versenden/anzunehmen, deren IP Adresse sich nicht in einen Host Namen auflösen lässt um ihn mit dem HELO vergleichen zu können.
Die Erfahrung hat einfach gezeigt, das Server ohne hostnamen auch in anderen Bereichen schlecht gewartet/konfiguriert sind und gerne von Spammern offenes Relay und schlimmeres missbraucht werden.
In der Header Zeile fehlt auch der Eintrag PTR und eigentlich sollte da der HELO wiederholt werden. So ist das zwar nett aber rel. nutzlos.
Unverschämt wäre, wenn Microsoft E-Mails von solchen Servern annimmt, aber dann lautlos entsorgt.
Eigentlich könnte man nach dem TCP IP connect und auf das HELO ein freundliches, klares
550 server rejected, host address does not sesolve
Antworten oder die IP schon im Router rejekten (bitte nicht nur droppen)
Das "scalliert" sehr gut, weil der absendende User garantiert ein NDR bekommen kann und sofort dem Kunden anrufen kann, oder seinen Admin…
Dem Admin des kaputten Systems zu informieren ist so effektiv wie eine Diskussion über Farben mit einem Blinden. Wenn aber die User, der Chef selbst seine hochwertigen Powerpoint Folien nicht zum Kunden bekommt,wird sich etwas ändern.
Auf den ersten Blick scheint dieser Test den Nachteil zu haben, das eine "kostbare" DNS Abfrage gemacht werden muss, bei jeder Spam Mail. Aber auf dem 2. Blick würde man sehen dassSpammer nicht diese Vollidioten sind, und diesen Host nicht mehr benutzen werden und so der Traffic herunter geht.
Die Email anzunehmen und zu entsorgen hat für den Betreiber den Vorteil, dass er viel Traffic auf sich zieht, den der Empfänger Kunde teuer bezahlen muss. Auch kann man so bessere Statik verkaufen….(darum lassen sich manche Email Provider das Feature "Catch all abschalten" teuer bezahlen. Es bringt ja kostenpflichtigen Traffic. Zweimal.)
Vielleicht mag Günter mal nachfragen, ob der Hostname doch bekannt ist und nur aus schwer nachvollziehbaren Gründen gelöscht wurde?
Solche Konfigurations Fehler.(z.B. DNS über lastet) sind ätzend zu finden.
Sie fallen oft nicht sofort auf und wenn, wird schnell die E-Mail noch einmal geschickt anstatt den Admin zu belästigen.
Hallo Pau1,
der Server ist sauber durchkonfiguriert.
Ein Test auf https://www.mail-tester.com/ ergibt 10 von 10 Punkten.
DNS, PTR, DKIM, SPF etc. alles nach Vorschrift.
VG
Im Sec Center in der Quarantäne müsste doch der Grund zu sehen sein welche Spam Regel das aussortiert hat.
Wir hatten mal ein ähnliches Problem als Empfänger, da hat ein Mailgateway vom Sender die E-Mail verändert, danach ging die dkim Prüfung nicht mehr und die Mail wurde als Phishing von MS aussortiert.
Die E-Mails werden in den Junk-Ordner des adressierten Empfängers abgelegt, nicht in die globale Qurantäne des Tenants.
Dort kann man sich zwar die Header anschauen, hat aber nicht die Funktionen des Sec Ctr
Microsoft macht bei EXO in der Standardkonfiguration mW keinen silent Drop. Entweder die Ablehnung erfolgt im SMTP Dialog oder es gibt einen NDR.
Man kann das aber natürlich auch anders konfigurieren, sodass bestimmte Email nicht und/oder woanders hin zugestellt werden bzw. eben verworfen werden.
Da email per Definition nicht verloren gehen kann, gibt es nicht die Möglichkeit eines Silent Drops. In welchem RfC sollte das stehen?
Die Geschichte mit dem NDR ist keine akzeptable Lösung, da Spammer fast immer die Adressen andere Opfer als Absender verwenden. So also völlig Unschuldige mit NDRs belästigt werden.
Es bleibt nur das reject auf SMTP Ebene als sozial verträgliche und technisch schnellste Lösung.
Warum man keine E-Mail annehmen darf, die man dann nicht weiterleiten kann sieht man ja hier sehr schön.
Niemand weiß so genau was MS sich zurechtfiltert und false Positives fallen nicht oder nur mit Verzögerung auf.
Aber unser Mailserver muß emails für 5000 Domains annehmen.
muss er das? Muss er das 220 schon geben, bevor die Prüfung ob man den Müll annehmen will/kann/darf?
Wo steht das?
Warum gibt es dann überhaupt einen SMTP Code "250 warte noch etwas"?
Ja, man hat dann 40000 offene SMTP Verbindungen.
So what?
Was ist besser?
E-Mails ungeprüft annehmen und lautlos entsorgen, oder dem anliegenden Server direkt zeitnah zusagen, das seine E-Mails unerwünscht sind.
Das diese Diskussion immer noch geführt werden muss?
Was willst du eigentlich jetzt? Jemals einen E-Mail Server selbst verwaltet?
Ich sagte dir nur, was technisch bei EXO konfiguriert ist bzw werden kann. Ob das RFC konform ist oder nicht möge jeder für sich selbst beantworten.
Und selbst wenn EXO nicht jeden RFC zu 100% einhält, wer will etwas sagen? Du? Oder dein Mallserver mit „5000 Domänen". Ich lach mich tot in dem Moment indem EXO dich mit seinen NDRs platt macht… hahaha
Ich würde mal die internen Daten, alles hinter dem Mailgateway, im Header beim Versenden entfernen lassen.
Das geht keinen was an und bei mancher AntiSpam Appliance führt das zu Problemen.
BG Jan
Es dürfte wieder das gleiche Problem sein: "Tenant Attribution".
– Die Umgebung nutzt Exchange Hybrid
– OnPrem gibt es einen Send Connector für .mail.onmicrosoft.com
– In EXO gibt es einen "Inbound Connector from " , der die OnPrem Mails annehmen und "trusted" soll.
– Schaut euch den an was der eingestellt hat uns lest dann https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143
Im Exchange Online Header sollte stehen:
x-MS-Exchange-Organization-AuthAs: internal
und einige andere: Siehe auch
Irgend eine Konfigurationsänderung führst dazu dass Exchange Online deinen OnPremises Server nicht mehr erkennt.
Es darf NIE ein Fremdsystem zwischen OnPrem und EXO sein, da die kein XOORG unterstützen.
https://www.msxfaq.de/cloud/exchangeonline/transport/xoorg_und_exchange.htm
https://www.msxfaq.de/cloud/exchangeonline/transport/x-originatororg.htm