Ich stelle mal eine Leserbeobachtung zu Exchange Online hier im Blog ein. Exchange Online liefert beim Leser gespoofte E-Mails zu, obwohl ein E-Mail-Gateway verwendet wird.
E-Mail-Spoofing ist eine betrügerische Methode, bei der sich ein Angreifer als eine vertrauenswürdige Person oder Organisation ausgibt, um das Vertrauen eines Opfers zu gewinnen und an sensible Informationen zu gelangen oder Schaden anzurichten.
Eine Lesermeldung
Blog-Leser André hat sich gestern mit folgender Information per E-Mail gemeldet, die nicht so schön klingt. Er hat vor ein paar Tagen ein sehr unschönes Verhalten des Exchange Online Servers festgestellt. Ein paar Anwendern wurden gespoofte Nachrichten zugestellt, was technisch eigentlich ausgeschlossen sein sollte, da SPF, DKIM und DMARC über ein E-Mail-Gateway geprüft werden.
Nachdem er sich das Ganze angesehen habe, war ich tatsächlich erst mal ratlos. Die Emails kamen nicht von unserem Gateway, sondern wurden direkt an Exchange Online gesendet.
Analyse des Headers
Auch dies sollte technisch nicht möglich sein, schrieb der Leser. Anhand des E-Mail-Headers und der Nachrichtenverfolgung in Exchange konnte er das aber zweifelsfrei sehen.
Die E-Mails wurden wie echte, interne Nachrichten behandelt, auch wenn aus den Headern klar hervorgeht, dass es von einer anderen IP versendet wurde und Microsoft auch einen SPF-Fail erkannt hat. Dennoch wurden die Nachrichten den Endanwendern zugestellt.
Noch jemand mit der Beobachten?
Der Leser meinte: "Eventuell wäre das etwas für ihr Blog, unser Dienstleister für unser E-Mail-Gateway berichtete zum 30.7.2025 ebenfalls von einigen Kunden, die solche E-Eails erhalten haben."
Hier noch der Auszug der E-Mail des Dienstleisters:
Hallo Herr xxx,
uns haben heute bereits mehrere dieser Meldungen erreicht, scheinbar gibt es Microsoft-seitg ein Problem. Um dem genauer auf die Sprünge zu gehen, würde ich sie bitten ein Ticket bei Microsoft zu eröffnen.
Der Ratschlag war, sich "per Ticket direkt an Microsoft zu wenden". Den Leser interessiert nun, ob auch andere Administratoren diese Probleme haben, oder ob es ein gezielter Angriff auf einzelne Exchange Instanzen ist.
Zusammenfassung der Feststellungen
Der Leser hat eine Zusammenfassung, was er festgestellt hat, so beschrieben:
- Ein Anwender meldete per per Ticket-System eine verdächtige E-Mail.
- Die E-Mailwurde nicht über unser Emailgateway geleitet, sondern direkt im Exchange zugestellt. Dies sollte nicht möglich sein.
- Die Email war gespooft und hatte als Absender, wie auch Empfänger die Adresse anwender.anwender@firma.com.
Dies sei eine valide und aktive Emailadresse des betroffenen Anwenders, schrieb der Leser. Die Email wurde über Exchange Online von der IP 51.77.93.35 versendet. Wir haben keine Vertrauensstellung oder ähnliches zu dieser IP.
Nach Recherche des Lesers gehört die IP zu einem Cloud-Hoster (*ttps://www.ovhcloud.com/de/), die der Angreifer vermutlich nutzt. Der Leser kann sich nicht erklären, wie ein Angreifer das E-Mail-Gateway der Firma umgehen kann. Die Nachricht stammt eindeutig von einer externen IP und wurde nicht über den eigenen Exchange Online-Tenant versendet.
Die Nachricht verhält sich aber exakt wie eine interne Email, die ja nicht über das Gateway geroutet werden. Der Leser hat dann überprüft, ob der Anwender eventuell kompromittiert wurde. Allerdings ist das Anmelde-Log im Admin Center unauffällig. Das Passwort hat die IT direkt geändert. Multifaktor ist ebenfalls aktiv.
Bei der E-Mail handelt es sich um (schlechtes) Phishing, die Bedrohungslage ist also da, schrieb mir der Leser. Hier ist noch der Mail-Header.
Received: from FR3PPF6BBA5F47A.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d18:2::14e) by FR6P281MB4000.DEUP281.PROD.OUTLOOK.COM with HTTPS; Mon, 28 Jul 2025 11:30:27 +0000 Received: from DUZP191CA0017.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:4f9::28) by FR3PPF6BBA5F47A.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d18:2::14e) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8964.24; Mon, 28 Jul 2025 11:30:24 +0000 Received: from DB1PEPF000509EF.eurprd03.prod.outlook.com (2603:10a6:10:4f9:cafe::57) by DUZP191CA0017.outlook.office365.com (2603:10a6:10:4f9::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8964.27 via Frontend Transport; Mon, 28 Jul 2025 11:30:24 +0000 Received: from [127.0.0.1] (51.77.93.35) by DB1PEPF000509EF.mail.protection.outlook.com (10.167.242.73) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8989.10 via Frontend Transport; Mon, 28 Jul 2025 11:30:24 +0000 From: "Anwender, Anwender" anwender.anwender@firma.com To: "Anwender, Anwender" anwender.anwender@firma.com Subject: firma Bonus and Payslip ready July 28, 2025 at 07:30:21 AM Thread-Topic: firma Bonus and Payslip ready July 28, 2025 at 07:30:21 AM Thread-Index: AQHb/7MEuiuozb+3uUGWqMoax029qw== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Mon, 28 Jul 2025 11:30:23 +0000 Message-ID: 4603a6d5-c683-70c0-3143-82dffa1360ee@firma.com List-Unsubscribe: mailto:unsubscribe@firma.com Content-Language: de-DE X-MS-Exchange-Organization-AuthSource: DB1PEPF000509EF.eurprd03.prod.outlook.com X-MS-Has-Attach: yes X-MS-Exchange-Organization-Network-Message-Id: beb7bfcf-af45-46bd-4c81-08ddcdca24db X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ms-exchange-organization-originalserveripaddress: 10.167.242.73 x-ms-exchange-organization-originalclientipaddress: 51.77.93.35 received-spf: Fail (protection.outlook.com: domain of firma.com does not designate 51.77.93.35 as permitted sender) receiver=protection.outlook.com; client-ip=51.77.93.35; helo=[127.0.0.1]; x-ms-publictraffictype: Email authentication-results: spf=fail (sender IP is 51.77.93.35) smtp.mailfrom=firma.com; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=firma.com;compauth=none reason=451 x-ms-office365-filtering-correlation-id: beb7bfcf-af45-46bd-4c81-08ddcdca24db x-ms-traffictypediagnostic: DB1PEPF000509EF:EE_|FR3PPF6BBA5F47A:EE_|FR6P281MB4000:EE_ x-ms-exchange-transport-crosstenantheadersstamped: FR3PPF6BBA5F47A x-eopattributedmessage: 0 x-eoptenantattributedmessage: 220ec385-dd32-4662-884e-f820d9e51a98:0 x-forefront-antispam-report: CIP:51.77.93.35;CTRY:FR;LANG:en;SCL:-1;SRV:;IPV:NLI;SFV:NSPM;H:[127.0.0.1];PTR:ip35.ip-51-77-93.eu;CAT:NONE;SFS:(13230040)(4022899009)(4053099003)(39101999004)(7095599003);DIR:INB; x-microsoft-antispam: BCL:0;ARA:13230040|4022899009|4053099003|39101999004|7095599003; x-ms-exchange-crosstenant-originalarrivaltime: 28 Jul 2025 11:30:24.0173 (UTC) x-ms-exchange-crosstenant-network-message-id: beb7bfcf-af45-46bd-4c81-08ddcdca24db x-ms-exchange-crosstenant-id: 220ec385-dd32-4662-884e-f820d9e51a98 x-ms-exchange-crosstenant-fromentityheader: Internet x-ms-exchange-transport-endtoendlatency: 00:00:03.5495026 x-ms-exchange-processed-by-bccfoldering: 15.20.8964.025 x-ms-exchange-crosstenant-authsource: DB1PEPF000509EF.eurprd03.prod.outlook.com x-ms-exchange-crosstenant-authas: Anonymous X-Microsoft-Antispam-Mailbox-Delivery: ucf:0;jmr:0;auth:0;dest:I;ENG:(910005)(944506478)(944626604)(920097)(930097)(140003); X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?TsepPSj1HIpjGozCjX6q0LGG/YYZTOl4jxp3uanif+0wk/PMQjhq2ga4gaXH?= =?us-ascii?Q?qDhTgL4cAGmgump+MYyDJWAZrUVZwpp6ED5xP20KeaBRnI5y1KrFhCXHG3NA?= =?us-ascii?Q?7o8ARnFoe6hFHBXs/BQRtKgSWKMuXJHV/6W9/VGgTbYkXioVF6qrQU6siOY4?= =?us-ascii?Q?GjyufL3NBFnyc+4ceJiuEjbYNOetW/wPJC8Ms1xrLfKyXXvcLg5nGJ1USaZK?= =?us-ascii?Q?mkievGoU/QrmOlsnCGabxVfbDfR7xdK/W3ds6KDkZbfi8/lN8YrvOCG+Y+/G?= =?us-ascii?Q?LFE8V9AiVkt2rjfMbGuTvvM6Qby/wk8a81yAtBbFcM6uvSC0lyKve+UKjRUG?= =?us-ascii?Q?wq5kWJvohBcc+uPBWhD65P/0ZoZjPKCcJvc0srqH0KGk472Ai4AhmZNUMRYT?= =?us-ascii?Q?/PlXmhWFSgylVE7k9aCyYj1iL4cDW4GFMkol7jxvT/ST/sI+Qx1htWfD55l9?= =?us-ascii?Q?pVBiJ8NQUOUIYxm4Q6J6nsIevJKOmg1D9RCF27v1C6iSYqVj4rL4bZ8ojsUd?= =?us-ascii?Q?qsyg1I+zTt4RG3kiWswfpD83IYvtdgxHWTocSQ3GJp9DUEZwzETWclxg94gl?= =?us-ascii?Q?jsmsXdSrafL3KHgzWD/UYHXxAkn88mzcsObCendWsEd7axrKKE5utebk8lIB?= =?us-ascii?Q?O9R3H3tALjoTRmMBm/qFldd1CEykYa/pENhSH+NaM7G+NT50WpqKLvXhtD/N?= =?us-ascii?Q?VrpeIdOa1j5VGNlPDF6D/GltZuwol9ybo+ZtkZZL2aqj5cLguZLalkVJ8wdN?= =?us-ascii?Q?M/uwDG7uhcX7mLXUaj7/p8MkhwccNH4KL4Wx6GGIVUjLWK5XIhc/75PkkgwK?= =?us-ascii?Q?tES50BM1w5J6Xl5lIOYqCgK0ikNcMiciPDSiIW9RwHY5QbbuX/D5OkLoH9Oe?= =?us-ascii?Q?GyvKw2KnEKNkhtxtP5kcOOtyNJt40kCXfRF8uXFdLnCKK8G7YSYpAU+nzY4U?= =?us-ascii?Q?oAl/vyb+GK5ruRn5ZoaH0zDq/CHl1RpR+9Xk1+Qbb0DNQ03er4HgLbSlIRG0?= =?us-ascii?Q?1jLOTNQc6Z8Z4OVkZx8sWHN6AQJFRQPxMcXg9O41qbJICSiBPzkXhEdfR2wQ?= =?us-ascii?Q?MiF0/4tctRwPYgzsrPXhWpoD+gKuH4MqHhar6ONGWGgY2hksw39khm4Ch4bm?= =?us-ascii?Q?a+qQ1SnLkaqIDS209LfdJBY0PRDZUb+GfedgMJjR0AX+Vmsri+X64TJ5tdp9?= =?us-ascii?Q?TN+SF4ox4tFEvWdgq2E4vkXLbjkD9Z8m4d87dVvxHRqnCjLP5uHMLFdtBXfU?= =?us-ascii?Q?5BvxdIumiCz0ApGp5p8H3ycyFMBInhFjCuBK4pdlBOP+XaBuFkxnHMoy+Tim?= =?us-ascii?Q?58dwpcOckJaGPCBrfZRIaz7aG0m/KyxowSV+qI6+/DONc0cC/sf3UpexL7zn?= =?us-ascii?Q?Rnec12r/JpMZ0xRtBixTqyUpEy8YYKcs06xoa6Kxr/RVyjDRKfv8c/QPAg/3?= =?us-ascii?Q?sdNeVdBDUk+nVdMz+WkCUqByNMlk6V2NjB9cdO9X8DC2WEw2clgVzZC7o7CO?= =?us-ascii?Q?W9Ay5KW9JKN4pg6dEwozvpD6RpKFrWzn3uZaid+cZsZJLdvhGPij+zVF+Imo?= =?us-ascii?Q?gZ2EQU9NJIGMzADftr5ZYWvq8H92Yde5YcnZgUwoW371ew4oloLkYb1+4wra?= =?us-ascii?Q?4mAQDE62b53tL91G9a7aamjX+6ryFdqLwaon2zFVTFK+T1i5ykSUdNBmfdjh?= =?us-ascii?Q?+xnhjgxcJOUf536yhyco64koF6XL0210IHNyYAB9lvC/GrfxtJXo8cHK0GXn?= =?us-ascii?Q?S1kW+WcR1ieRyGXS74nqHJiN0anRbUFYoZyX7AIEjIVkh4Rb5CpiJN0DzfIe?= =?us-ascii?Q?1fVrnbmviZBEJ41CniNelxOnZpshRm/RDoHjTXEj04Q4c45znso5qR8863zj?= =?us-ascii?Q?tAuDZuS4BDQ2eUUQ706Zz6xNc69wdkwq3Uq2EDc9D37Bt1ohHZyTNfFXyDsU?= =?us-ascii?Q?AfX1DtXF/5XBnuMlW2oxzAn13PMNg8Xz4HrQdYZoyfnjjgpgvJaiVkJfynVn?= =?us-ascii?Q?K/JjkIIkKeKVw309XFGqjwP78lrqhCH9RAl6NrdioFWsjfDPJD87nTYOfE0p?= =?us-ascii?Q?xmCu8H1pthXpbY/Zo1G3yNuNvdkt/d8k2f15BdF20DLrVzj8JSE6q5mOBxTZ?= =?us-ascii?Q?Dg+oI+B7PlQ4yDMBbUNqsK7fOGsOSi5j5WJl/zPkFn/y2ga+GrHGiIonyPmO?= =?us-ascii?Q?+luBlZ17UXpyKNOhC8/m04bkvvkJ+KtXGcp5mIX/S0tB+9b7oT560HpnBJ7y?= =?us-ascii?Q?mtzjS/Qzs/AWyxijvOf/V9QKBLlyVcibFZEsSEevlYZDHrKZ6GKWaPjx8pOk?= =?us-ascii?Q?cfEsPLDzCB39aRJAB1Bk4rZE?= Content-Type: multipart/mixed; boundary="_002_4603a6d5c68370c0314382dffa1360eefirmacom_" MIME-Version: 1.0
MVP: 2013 – 2016
So auf die Schnelle klingt das ein bisschen nach dem hier:
https://www.bleepingcomputer.com/news/security/microsoft-365-direct-send-abused-to-send-phishing-as-internal-users/
Kann der Kunde einmal kontrollieren, ob DirectSend im Tenant aktiviert ist?
das ist aktiv, wenn man das nicht selbst deaktiviert hat. Wir hatten das gleiche Problem, Absenderserver war eine Adresse bei Hetzner in unserem Fall.
Und wenn man den "harten" SPF Check einschaltet in einer Hybridumgebung werden auch gerne mal legitime Mails nicht zugestellt und als Spam markiert.
Wir haben bei einem Kunden genau das gleiche verhalten
Nur weil man als MX ein separates Gateway eingerichtet hat heißt es ja idR. nicht, dass die Mails bei Microsoft nicht auch direkt verarbeitet werden können. Den zuständigen MX bei Microsoft zu erraten ist ja nicht wirklich schwer.
Da wäre es halt interessant zu wissen was man im Exchange Online und Defender for Office eingerichtet hat um das abzuschalten. Wenn ein SPF-Fail im Exchange direkt keine Auswirkung hat, hat man da wahrscheinlich auch nichts dafür eingerichtet. Kenne die Microsoft Tenant Standards nicht (hängt ja auch davon ab wann dieser mal eingerichtet wurde), halte ich aber absolut für möglich.
Hört sich nach "direct send" an. Da hat der Betroffene anscheinend etwas verschlafen.
https://old.reddit.com/r/sysadmin/comments/1mcpale/spoofed_emails_bypassing_email_gateway_security/
Leider zu wenig Daten und Infos, um da was zu sagen zu können. Wenn DMARC mit entsprechender Policy gesetzt ist, was es ja angeblich sei, sollte das nicht möglich sein.
Die angeblich betroffene Domain wäre zumindest hilfreich.
Spannend ist folgender Header (vom Artikel kopiert):
"header.d=none;dmarc=fail action=oreject header.from=firma.com;compauth=none reason=451"
Laut dem Header ist die DMARC-Prüfung zwar fehlgeschlagen und eine reject-Policy gesetzt. Jedoch wurde das Reject übersteuert vom Empfängerserver ("o[verride]reject").
Der Reason-Code 451 deutet auf ein temporäres Problem am Empfänger-Server hin.
Eventuell ist der DNS-Server (der Empfangs-Domain) nicht zuverlässig genug, und der Empfänger-Mailserver konnte die DMARC-Policy nicht abrufen.
Ist natürlich ins blaue geraten…
Ich würde mir mal ansehen, ob der DNS-Server sporadisch überlastet ist.
Sowohl SPF, DKIM als auch DMARC scheint da fehlzuschlagen.
Das einzige, was da interessant ist das override "oreject"
Alles andere ist Microsoft Schmus. Wie gesagt, ohne die Domain zu kennen und schnell die Policy im DNS prüfen zu können lässt sich da nichts weiter zu sagen.
Hmm,
ist das sendende Mail-System eventuell selbst in der MS-Cloud zuhause? Dann wäre es ja einfacher, direkt MS-intern zuzustellen statt 'außenherum'. Jedenfalls sehe ich in dem Header nix außer Microsoft-Servern. Und die vertrauen sich natürlich gegenseitig ;-)
Da war doch auch mal ne Sache, dass man als authentifizierter MS-Client jede Absenderadresse einsetzen konnte, die auch bei MS gehostet war.
Irgendwie in dem Kontext wird das wohl auch stehen.
authentication-results: spf=fail (sender IP is 51.77.93.35)
Nur so als Beispiel für Nicht-Microsoft im Header…
Das ist dann wohl der einliefernde Client.
Der kann ja gerne irgendwo sein, aber die Mailserver in der Kette sind alle von MS. Oder hab ich da wirklich was übersehen?
tldr:
Powershell:
Set-OrganizationConfig -RejectDirectSend $true
—
Es reicht ein einziger Powershell-Befehl "Send-MailMessage", siehe Varonis-Artikel (*1), um Sicherheitsmaßnahmen wie SPF, DKIM und DMARC zu umgehen, weil die email als "intern" gewertet wird und Authentifizierungen von Microsoft als unnötig betrachtet werden, weil Microsoft dieses "Direct-Send"-Feature standardmäßig aktiviert hat.
"Because the email is routed through Microsoft's infrastructure and appears to originate from within the tenant, it can bypass traditional email security controls, including:
– Microsoft's own filtering mechanisms, which may treat the message as internal-to-internal traffic. "
(*1)
varonis. com/blog/direct-send-exploit
Dort stehen auch die Gegenmaßnahmen:
Prevention: What you can do to protect your org
– Enable "Reject Direct Send" in the Exchange Admin Center., siehe Microsoft Quelle unten (*2)
– Implement a strict DMARC policy (e.g., p=reject).
– Flag unauthenticated internal emails for review or quarantine.
– Enforcing "SPF hardfail" within Exchange Online Protection (EOP).
– Use Anti-Spoofing policies.
– Educate users on the risks associated with QR code attachments (Quishing attacks).
– It's always recommended to enforce MFA on all users and have Conditional Access Policies in place, in case a user's credentials are stolen.
– Enforce a static IP address in the SPF record to prevent unwanted send abuse — this is recommended by Microsoft but not required
Anleitung von Microsoft:
(*2):
"Reject Direct Send Feature":
By its definition, Reject Direct Send covers anonymous messages sent from your own domain to your organization's mailboxes. Enabling this setting will block any email sent to your tenant that is sent anonymously using an address that matches one of your accepted domains.
How to enable this feature
By default, the new opt-in RejectDirectSend setting is set to False. To enable the Reject Direct Send feature, Exchange Online administrators can run the following PowerShell cmdlet:
Set-OrganizationConfig -RejectDirectSend $true
The change should propagate out to our entire service within 30 minutes. With the feature enabled, any received Direct Send messages will see the following message:
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources
Unless Direct Send is re-enabled again, any messages that hit this error will need a partner connector created to authenticate their source as an approved sender.
techcommunity. microsoft. com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790
—
Die Fehler von Microsoft sind:
– dieses "RejectDirectSend" Feature ist standardmäßig auf "false" eingestellt, aus Sicherheitsgründen aber auf "true" eingestellt sein sollte.
– SPF "fail" wird ignoriert, weil standardmäßig kein "hardfail" eingestellt ist.
– DMARC steht standardmäßig auch nicht auf "reject".
– Authentifizierungen als unnötig betrachtet werden.
Soviel zu "Security first".
Danke, also MS Schmus… wie vermutet…
Also Dinge, die man bei Betrieb eines "normalen" GNU/Linux Mailservers nicht hätte…
Ja und nein. Das Feature wurde im April eingeführt. Im Mai habe ich zum ersten mal einen Beitrag dazu gelesen, wie man dieses Feature am Besten gleich wieder deaktiviert. Der Bericht von Bleeping Computer ist vom Juni. Jetzt ist es Ende Juli und man hat sich offensichtlich nicht damit beschäftigt.
Sorry, was machst Du gerade? Du schiebst dieses Problem den Admins/Usern in die Füße, die Deiner Ausführung zufolge über hinreichend viel Zeit zur Anpassung gehabt hätten?
Sorry da gehe ich nicht mit. Es gibt anerkannte und etablierte Standards wie SPF, DKIM, DMARC. Die werden aus nicht nachvollziehbaren Gründen von Microsoft unterwandert und dann auch noch dilettantisch ausgerollt. Nämlich maximal offensiv und nicht wie es RFCs üblicherweise vorgeben, defensiv und fehlertolerant.
Das ist typischer, selbstverursachter Microsoft Schmus.
Kategorie: Probleme, die man ohne Microsoft nicht hat.
Mein Mitleid mit den Betroffenen hält sich zwar in engen Grenzen. Diese werden aber vermutlich kein Mitspracherecht bei der Entscheidung gehabt haben, Email in die Hände eines solchen Saftladens abgegeben zu haben.
Von daher ist Deine Schuldzuweisung bilig.
Verursacher ist hier ganz klar Microsoft.
Kann man diese Einstellung auch über Microsoft Lighthouse über mehrere Tenants zentral verteilen?
@Tomas Jakobs: Sorry, Ihre aggressive Art und Weise sich auszudrücke hat hier nichts zu suchen.
back to topic: Den "Schmu" kann man umgehen durch Deaktivierung des Features und/oder durch ein zusätzliche Transport Regel, welche nur Emails von der IP des Gateways zulässt.
Keiner weiß inwiefern der Betroffene hier Einfluss drauf nehmen kann, aber so sieht aktuell die "Lösung" aus.
Sorry, den Schuh ziehe ich mir nicht an.
Der passiv-aggressive, der anderen die Schuld in die Schuhe schiebt und unterschwellig behauptet, diese hätten ja genügend Zeit gehabt, bin nicht ich…
Ich rede Klartext und benenne Bullshit, wo ich Bullshit sehe! Und das ist Bullshit!
In diesem Sinne!
Danke für Ihren "Bullshit" ;)
@Tomas Jakobs
Vielen Dank für deine Worte. Bin 100%ig bei dir.
Welches Gateway wird verwendet? Ist MTA-STS aktiv?
Der Grund liegt hier: header.d=none;dmarc=fail action=reject header.from=firma.com;compauth=none reason=451
-> "4xx or 9xx: The message bypassed composite authentication (compauth=none). The last two digits are internal codes used by Microsoft 365."
Damit sind die Connectoren vermutlich nicht genug beschränkt (oder beschränkbar).
Mit der Anleitung von Practical365 kann man die Mails aus dem Tenant per TransportRule dann zum Gateway umleiten: https://practical365.com/how-to-ensure-your-third-party-filtering-gateway-is-secure/
Hallo,
wir hatten genau dieses Problem.
MX ist für die domain nicht EXO. Zustellung sollte _nur_ über unseren MX erfolgen.
Lösung (via MS Support):
einen neuen Inbound-Connector erstellen vom Typ "Partner"
Reject Mail auf Basis von IP und hier eine öffentliche Mail eintragen (z.B. den Google DNS 8.8.8.8)
Damit ist dann verhindert, dass ein Spammer direkt via .mail.protection.outlook.com:25 Mails relayen kann.
ja, das funktioniet. Aber dann schaltest du auch z.B. Mails von Entra ab, die an Admins gehen. Aktuell bekommen wir z.B. keine Benachrichtungen mehr von PIM-Freigaben.
Hab das ganze noch nicht gestestet, aber ich vermute auch das Ablaufen von Entra-Gruppen oder andere Security-Benachrichtungen gehen nun nicht mehr rein.
@Basti: Ich teile Deine Bedenken und wäre vorsichtig beim Blocken von tenantname.mail.protection.outlook.com. Zusätzlich zu Entra-Emails würde ich noch Power-Automate-/Yammer/Sharepoint-Emails erwähnen (hab's aber auch noch nicht getestet).
Hier werden noch weitere Email-Varianten erwähnt:
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790
"Most of these use cases are related to internal Microsoft Communications. :
1) messages from Microsoft systems (alerts, notifications, etc…) apparently use DirectSend so they must be excepted by the rule.
2) Internal forwards between internal users must be excepted.
3) If an external entity sends a calendar invite (through normal MX workflow), and that internal user forwards that calendar invite to another internal user, that has to be excepted by looking for a specific header.
4) If an internal user sends a calendar invite to an external person, and they accept/decline, that response has to be excepted by looking for a specific header, but you can't look for multiple headers in the same transport rule.
Hallo zusammen,
vielen Dank für die vielen konstruktiven Beiträge!
Ich konnte es jetzt tatsächlich nachvollziehen und "Direct Send" ist hier tatsächlich das Problem.
Ich konnte mir erfolgreich gespoofte Emails zusenden. Es ist echt erschreckend, wie einfach das geht.
"Verschlafen" habe ich das Thema nicht, ich bin nur nicht davon ausgegangen, dass Microsoft so einen Irrsinn direkt live schaltet.
Also noch mal vielen Dank an alle Helfer. Eventuell hilft es ja auch noch anderen.
Das wird wohl bedeuten, dass es da draußen unzählig viele Exo-Instanzen gibt, die genauso offen sind, weil durch die Admins versäumt wurde, die verschärften Settings zu aktivieren? Trivial ließt sich das alles ja nicht, und jetzt ist auch noch Sommer=Urlaubszeit, wo in vielen Firmen auch die IT eher im unterbesetzten Zustand betrieben wird. Ich muss mir den Link mal ins Büro weiter leiten, um das mal bei uns checken zu lassen, sobald ich wieder im Land bin. Ich weiß nicht, ob die Kollegen den Blog hier auch so regelmäßig abklappern.
Schick doch mal deinen Kollegen per Powershell-DirectSend eine gespoofte "interne" eMail mit dem Link auf diesen Blog-Artikel.
Wenn die Mail durchkommt, dann sehen die Kollegen auch direkt die Lösung zum Problem.
Das wäre doch mal witzig.
Da du im Ausland bist können sie die IP-Adresse auch nicht zu dir zurück verfolgen, sondern nur zum Hotel-WLAN.
Hallo Bolko,
genau das habe ich vorhin bei meinen "Security" Dienstleistern gemacht. Scheint durchgegangen zu sein. Wir sind echt am Arsch…
Ich werde noch das ein oder andere Gespräch führen müssen.
Hier im Blog sind alle User "White Hats".
Hat hier irgend jemand eine Vorstellung von der enormen Schlagkraft der "Black Hat"-Blogs?
Die haben Datenbanken mit mehreren zehntausend Sicherheitslücken und Tools, die diese Datenbanken einfach auf das Opfer loslassen und durchprobieren, welche Lücke noch offen ist und den Feind rein lässt.
[START] -> [BANG!]
EASY!
Das klappt praktisch immer.
Da kannst du als "White Hat" jahrzehntelange Erfahrung haben, aber irgend etwas übersiehst du.
Die "Black Hats" kommen nach wenigen Stunden fast immer durch, weil die Macht der Datenbanken einfach zu groß ist und ein engagierter trainierter Normalo-Admin einfach nicht hinterher kommt, um gegen die Black-Hat-Datenbanken und die Blödheiten von Microsoft gleichzeitig permanent zu gewinnen.
DIE müssen nur 1 mal Glück haben, aber man selber muss immer zu 100 Prozent Glück haben.
Das ist realistisch unmöglich, also gewinnt der Angreifer früher oder später.
Dieses Risiko kann man verringern, indem an eine der Schwachstellen eliminiert, und das ist Microsoft.
RAUS damit, dann hat man noch etwas länger eventuell eine Chance.
Ich liebäugle immer mehr und mehr Landwirt oder ähnliches zu werden. Nun bin ich nunmal Win-Admin und gerade die vollkommen irren "Design"-Entscheidungen von Microsoft halten mich in Lohn und Brot, allerdings empfinde ich es als täglich härter und härter den "Lohn" zu verdienen. Das sind wieder mal so unsinnige Dinge, die nur den verantwortlichen Admins auf die Füße fallen und im schlimmsten Fall natürlich die Firma zu Fall bringen. Raus aus "Windows" ist eine schöne Utopie, aber zeig mir doch mal realistisch auf, wie man das in einer Bude mit 500+ Mitarbeitern machen kann. Autodesk, Adobe, usw. usf. sind da nicht mit einverstanden…
Sehr schön ausgedrückt, das Problem ist auch meins: Ich kann nix anderes als diesen IT-Kram… Naja, Tapezieren und Fertigparkett verlegen kann ich auch, aber das ist nicht gerade mein Traumjob,
Es geht da in diesem Falle nicht darum, ein Windows zu ersetzen. Du musst die Gefahren mitigieren. Das Toolkit ist da überschaubar. Vermeiden, Isolieren oder Externalisieren.
AD nur noch offline zu betreiben, vorzugsweise in Terminalservern. Einzelne Stationen mit besonderen Rollen (z.B. Konstruktions oder Entwicklerstationen vom Rest wegisolieren etc.). Email auf jeden Fall selbst betrieben und nicht in die Hände von Dritten legen.
Wer da als Admin/ Entscheider keinen Arsch in der Hose hat, der oder die muss dann halt (anders) leiden. Um das Leiden an sich, da kommt niemand rum ;-)
> DIE müssen nur 1 mal Glück haben, aber man selber muss immer zu 100 Prozent Glück haben.
Das ist realistisch unmöglich, also gewinnt der Angreifer früher oder später.
In meinen Folien breche ich es auf diese Sätze runter:
"Angreifer haben unendlich viel Zeit, Ressourcen und Versuche. Zum Erfolg bedarf es nur einer kleinen Lücke."
"Verteildiger haben begrenzte Zeit und Ressourcen und dürfen sich keine Fehler leisten."
Von daher bleibt IMHO für Microsoft ADs nur der Weg, diese offline einzusetzen und die Schnittstellen im close Monitoring zu halten. Und wie dieses Thema eindrucksvoll beweist, sollte man seine Email nicht in die Hände von Microsoft legen.
https://blog.jakobs.systems/blog/20240506-service-tips-windows/
> …durch die Admins versäumt wurde, die verschärften Settings zu aktivieren?
Wieder jemand, der Victim Blaming betreibt? Der Irrsinn liegt ganz alein bei Microsoft.
Was mich interessieren würde:
Gibt es einen Inbound-Connector vom Typ Partnerorganisation der die IP des Mail-Gateways enthält? Dadurch werden Mails die "nebenher" gesendet werden nämlich eigentlich blockiert.
Diese DirectMail Einstellung hab ich bei uns nicht angefasst und wenn ich eine Mail wie beschrieben mit Send-Mailmessage einliefere kommt folgendes:
Die Serverantwort war: 5.7.51 TenantInboundAttribution; Rejecting.
Recipient has a partner connector with RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set.
Genau so ist es bei uns auch.
Eigentlich nur viel Rauch um nichts.
Hätte der Dienstleister oder die Firma den ExO korrekt konfiguriert passiert das nicht. Aber das ist inzwischen ja nicht mehr zu erwarten..
Hätte, hätte Fahradkette. Solche Blog-Beiträge sind auch dazu da, dass die Leserschaft lernt und der Betroffene sein Problem bestätigt hat. Ich denke, es ist kein Grund, hier (zumindest von mir gefühlt) selbstgefällig daher zu kommen. Beim nächsten Problem könnte es ja durchaus sein, dass es nicht an einer Konfiguration liegt. Vielleicht mal drüber nachdenken.
Ich finde den Artikel sehr gut und sehr wichtig!
Ich will nicht wissen, wie viele davon nichts wissen und dadurch verwundbar sind.
Ich bin über 20 Jahre Admin und für mich ist der Blog immer eine gute und oftmals hilfreiche Anlaufstelle.
Daher @Günther Born
Danke und weiter so!
typisch deutscher Blockwart Kommentar. Kaum weiß man etwas aus Zufall, weil man gerade nicht ins Phone geguckt und aufgepasst hat oder glücklichen Umständen, sind alle anderen unterbelichtet.
@MichaelS: Gib Dir alle Inbound-Connector aus mit
get-inboundconnector|sort enabled |ft enabled,name,connectortype,sender*,tlssendercerti*,restrict*
Vermutlich sind alle Deine Inbound-Partner-Connectoren auf IP-Adressen oder Certificates eingeschränkt?
Dann werden alle eingehenden Emails einem dieser Inbound-Connectoren zugeordnet, es passen aber weder Quell-IP noch Quell-Zertifikat und Dein Tenant nimmt keine Emails über den Nebeneingang tenantname.mail.protection.outlook.com an.
Bei uns passt es ja, da sind alle Inbounds eingeschränkt.
Ich wollte damit nur die Frage in den Raum werfen ob der Kollege im Ursprünglichen Beitrag solche Connectoren eingerichtet hat.
Kann ja durchaus auch eine temporäre Fehlfunktion bei MS sein.
Der INBOUND Partner Connector scheint sich noch „vor das direct send zu setzen".
Wir hatten da direkt bei der Einrichtung von EXO damit rumprobiert (aktuelles Thema bei uns).
Als wir "RejectDirectSend" auf True gesetzt hatten, wurde eine Mail von user1@company an user2@ Company abgelehnt, mit dem Hinweis, dass Direct send deaktiviert ist.
Sobald der Partner Connector eingerichtet wurde (da vorgelagertes cloud-based email gateway), hat sich die Meldung auf die von dir beschriebene „Recipient has a partner connector" Antwort geändert.
Wir haben beides: "RejectDirectSend" auf True und einen Partner Connector.
@Stefan A.: Das heißt: Legitime Emails von @company an @company, die vom vorgelagerten Cloud-based Email gateway kommen, werden dem Partner-Connector zugeordet (über IP-Adresse oder Zertifikat)?
Dieselben Emails, die von einem beliebigen Absender-Host direkt an euren Tenant gesendet werden, werden dem Partner-Connector nicht zugeordnet, da ja weder IP noch Zertifikat passen?
Daher kommt diese Fehlermeldung:5.7.51 TenantInboundAttribution; Rejecting.
Recipient has a partner connector with RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set.
IMHO spielt daher der Status von RejectDirectSend bei Euch keine Rolle, aber sicherheitshalber kann man es (zusätzlich) auf $True setzen.
@Stefan A.:
Das heißt, dass der Partner-Connector auf die IP oder das Zertifikat des vorgelagerten cloud-based Email Gateway limitiert ist. Dieses Gateway wird dem Connector zugeordnet und darf Emails von @company zu @company schicken.
Bei allen anderen Sender-Hosts passt weder IP noch Zertifikat, daher kommt die Fehlermeldung: 5.7.51 TenantInboundAttribution; Rejecting. Recipient has a partner connector with RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set.
IMHO ist bei Euch die Einstellung von RejectDirectSend egal, da ja schon der Partner-Connector ungewünschte Spoofing-Emails abfängt. Aber sicherheitshalber kann man den Wert schon auf $true setzen.
so einfach ist das evtl. auch, nicht, vor allem wenn das GW auch in der Cloud ist und der Anbieter die Quell IPs Netze nicht rausrückt oder es z.B. AWS ist. Die Frage ist auch bei dieser Lösung, was ist mit System Mails die aus M365 an die Tenantdomain geschickt werden? Davon gibt es leider viel zu viele, auch wenn man bereits eine Systemadresse mit eigener Domain in den Portalen gesetzt hat.
Du kannst auch ein Zertifikat an den Connector binden anstelle einer IP
New-InboundConnector -Name "From Mailgateway" -RequireTls $true -RestrictDomainsToCertificate $true -TlsSenderCertificateName mailgateway.domain.tld -SenderDomains *
auch das unterliegt nicht Deiner Kontrolle und es bleibt dem Anbieter frei, seine Zertifikate und FQDNs zu tauschen, wie er will. Was dann zur Untebrechung des Mailsflows führt.
Abgesehen davon, was ist mit den Systemmails? Die werden eben an tenant.onmicrosoft.com geschickt und werden ebenfalls blockiert – zumindest nach ersten Tests.
@Martin B: Vielen Dank für die Rückmeldung bzgl. der System-Mails (Entra, Yammer, Sharepoint, Power Automate …). Ich vermute auch, dass diese nicht mehr ankommen, wenn man tenantname.onmicrosoft.com per Inbound-Partner-Connector blockt.
Ja richtig, wenn man das Gateway nicht selbst betreibt (so machen wir es) oder einen Anbieter wählt, der sowas ohne Information an seine Kunden ändert. Nur… welcher seriöse Anbieter macht das? Die üblichen Verdächtigen (Hornet, NoSpamProxy, Barracuda, …) geben Dir alle Infos, stellen Powershell-Scripts zur Verfügung, mit denen Du die Konnektoren anlagen kannst oder legen die Connectoren direkt an.
@Alle:
Ich wollte schon den Befehl ausführen "Set-OrganizationConfig -RejectDirectSend $true", da kam mir dieses mögliche Problem in den Sinn:
Meine von mir erstellten Power-Automate-Notifications haben im P1-Envelope-From meine Emailadresse und gehen an eben dieselbe To-Adresse von einer IP 13.69.71.193, die zu MS gehört.
Sie richten sich nicht nach dem MX-Record, der bei uns auf ein vorgelagertes Security-Gateway zeigt.
Einem Inbound-Connector sind sie auch nicht zugeordnet.
Damit werden solche Emails doch von ExO über Directsend angenommen?
Einzig die Directionality ist nicht Inbound, sondern Intra-Org. Könnte dies für eine Ausnahme von DirectSend sprechen?
Kann ich also guten Gewissens DirectSend deaktivieren?
ich hatte heute einen Fall, wo eine der größten Firmen der Welt Multi-Page-Tiffs schickt.
WTF.
Mal Hand aufs Herz, wer kennt wirklich Multi-Page-Tiffs?
Weder Photoshop noch sonst ein Programm kann das interpretieren. Nur die alte "Windows Bild- und Faxanzeige" kennt dieses Format und interpretiert es korrekt.
Das ist leider kein Einzelfall, du kannst noch so versiert sein, was IT anbelangt, am Ende des Tages musst du die Anforderungen der Firma erfüllen, ihr Tagesgeschäft umzusetzen. Und dabei noch sämtliche Sicherheitsrisiken einpreisen und am besten direkt zu eliminieren.
Mir ist schon lange klar, dass ich Don Quixote bin. Es macht mir keinen Spaß mehr, aber ich muss meine Hypothek bedienen.
Ist zwar offtopic, aber IrfanView kann das.
Envince (der Default Gnome Dokumentenbetrachter unter Debian GNU/Linux) auch ;-)
ELO und andere DMS arbeiten auch gerne mit Multi-Page-Tiffs, von daher kenne ich das "Problem".
Kein Einzelfall, das ist etwas vergleichbar mit Dateianhängen in PDFs (gerne bei E-Rechnungen genutzt) – je nach PDF-Viewer werden die nicht angezeigt und sind somit nicht zugreifbar. Edge und Chrome z.B. können das nicht, Firefox und Adobe Reader schon.
Es ist extrem nervig, wenn Anwendungen bestimmte Formate implementieren, dies aber nicht vollständig umsetzen und dem Anwender auch keinerlei Hinweis über fehlende Details geben.
Jetzt sagst du was! Bei uns das Selbe. Vielleicht die gleiche Firma. An sowas wie Multi-Page Tiffs habe ich gar nicht gedacht. Wir haben immer eine PDF eingefordert, aber das scheint bei denen ein automatischer, vom System erstellter Prozess zu sein. Werde das gleich mal testen.
Kann mir mal wer erklären, wo jetzt der Kritikpunkt an Microsoft an dem konkreten Fallbeispiel ist?
Ich mein, der Betreiber hat sich doch ganz bewusst für eine Dritte Partei entschieden, die den Security Kram abhandelt. Also SPF, DMARC, DKIM Checks werden von einem Dritten betrieben und alles was da durch geht, wird an EXO weiter geschickt.
Soweit sogut – aber was kann Microsoft jetzt dafür, dass der Betreiber den Weg nicht selbst verschlossen hat, Mails direkt an EXO zuzustellen?
Streiten kann man sich sicher über die Default Settings von MS für viele Dinge. Aber auf der anderen Seite. Nur weil man einen Dienst bucht entbindet das doch den Betreiber nicht sich damit zu beschäftigen?
Ich sehe hier einen ziemlich großen Interessenskonflikt seitens der Betreiber und seitens der Anbieter. MS bietet den Dienst und möchte u.A. dass es funktioniert. Der Betreiber bucht den Dienst und möchte auch, dass es funktioniert. Aber beide sind sich in der Mitte uneinig, WIE.
Wenn ich mich als Betreiber in vollem Bewusstsein über dem generellen SMTP Mail Flow Thema für eine Dritte Partei entscheide, die für mich den ersten Hop für meine Mails public stellt, dann MUSS!!! ich mir auch im klaren sein, dass alles was hinter diesem Gateway passiert, nicht mit Default 0815 wird schon passen, Settings abgebildet werden kann/darf/sollte. Warum? Weil SPF, DMARC und DKIM primär am ersten Hop ansetzen.
Der Server hinter dem ersten Gateway wird alle Mails als SPF fail sehen, wenn da wer in der Kette zwischen hängt. Das ist der Sinn der Sache. Die Einstellung von Microsoft das nicht strikt wegzublocken ist mMn erstmal nachvollziehbar. Aber unverständlich ist für mich, das als Betreiber selbst nicht gegen geprüft zu haben und mich dann noch zu wundern dass dem so ist??
Ich will keine Grundsatzdiskussion anfangen, aber hätte M$ das RejectDirectSend per default aktiviert, können Exchange Online Kunden andere Probleme bekommen:
Alle die, die via SPF (-all), DKIM und DMARC (p=reject) schon über Jahre hinweg anderen Anbietern (zum Beispiel Newsletter Versendern) erlauben Mails von seiner eigenen Domain zu versenden, würden ihre eigenen Mails nicht mehr empfangen.
Von daher finde ich es schon legitim dass diese Option bei der Einführung nicht sofort aktiv ist.
Ich kann schon verstehen, nutzt man das selber nicht nutzt, ist es logisch ist diese Funktion zu aktiven.
Aber in heutigen Zeiten würde ich es bei Exchange Online zwingend Voraussetzen, dass SPF/DKIM/DMARC sauber konfiguriert sind, dann ist das "Direct Send" auch kein Problem.
@Dirk: Da sind sich die Kommentatoren aber nicht sicher, ob korrekt konfiguriertes SPF/DKIM/DMARC die Annahme von gespooften Emails der eigenen Domain verhindert:
https: //techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790?after=MjUuM3wyLjF8aXwxMHwxMzI6MXxpbnQsNDQwOTI0MCw0NDMwODg2&topicRepliesSort=postTimeAsc
"As others have said – you can bypass SPF/DMARC with direct-send, even if HARDFAIL is enabled."
@MaxM
Hast du auch die Antwort von M$ gesehen:
https://techcommunity.microsoft.com/blog/exchange/announcing-new-dmarc-policy-handling-defaults-for-enhanced-email-security/3878883
Ja davor sind solche Mails zumindest in die Quarantäne gelaufen.
Was aber definitiv dazu gehört, der Tenant muss seine eigene DKIM Konfiguration vorweisen, benutzt man den Default Signing Key kann die eigene Domain kompromittiert werden.
Wir nutzen eigene DKIM Signaturen für alle Domains (60+) die auf Exchange Online gehostet werden.
Ich kann es nicht zu 100% ausschließen, aber ich wüsste nicht wie man das aushebeln könnte. Meine Versuche sind bisher immer gescheitert.
P.S.: Was anders ist es natürlich wenn jemand meine Mails spoofed und diese an "Kunden" versendet werden. Das Abzuweisen liegt natürlich in der Hoheit des empfangenden Servers.
P.P.S: Wie gesagt, es ging ja nur darum dass man das "per default" deaktiviert. Exchange Online Kunden könnten dann "einfach so "ihre eigenen Mail nicht mehr empfangen.
Gruß
Dirk
@Dirk: Danke für Deine detaillierte Antwort. Und ja, ich habe den MS-Artikel gelesen.
Mein Beispiel:
Voraussetzungen:
1/ Für Eure Domain firma.de ist SPF Hardfail, DKIM-Signatur und DMARC reject gesetzt. Im Defender for Office ist festgelegt:
Honor DMarc policy UND
"If the message is detected as spoof and DMARC Policy is set as p=reject": Reject the message
2/ Nun schickt ein Spoofer ein Email mit Absender P1=john.doe@firma.de an john.doe@firma.de
Deine und meine Erwartung: Die Email wird zurückgewiesen.
Ist das Deiner Erfahrung nach so?
@MaxM
Ich kann zumindest von nichts gegenteiligen Berichten. Gemäß der Wahrscheinlichkeit und Millionen an Mails, hätte das bei uns in den vergangenen Jahren ja mindestens einmal passieren müssen, ist es aber nicht.
Jetzt fällt es mir schwer, mal eben einen Mailserver auszusetzen und das im Detail zu prüfen, um meinen Aussage auch technisch zu untermauern. Auch funktionieren nicht alle der zahlreichen SMTP test Sites/Tools, weil diese teilweise bei Spamhaus gelistet sind (ja M$ verwendet auch noch die guten alten Blacklists, mindestens aber die Dialin IP BL).
Ich kann aber sagen, dass ich einen Test Fehlversuch von mir im Security Center sehen kann:
Detection technology: Spoof DMARC
Delivery action: Blocked
Die Mail selber wurde nicht angenommen ich sehe nur die Meta Daten zu dem Versuch.
Ich meine so steht es auch in der Doku.
@Dirk: Wie Du es schilderst, ist auch meine Erwartung und Dein Beispiel bestätigt es.
Im Ausgangsfall und meiner Erfahrung nach schert sich MS in bestimmten Fällen, die ich nicht spezifieren kann, nicht um die Defender-Einstellungen.
Man sieht das im Header "Authentication-Results" am Eintrag action=oreject. [overwrite-reject]
Zum einen steht in den Header des Beispiel-Emails aus diesem Thread, zum anderen hat sich Frank Carius darüber geäußert:
https: //www.msxfaq.de/cloud/exchangeonline/transport/exo_dmarc_reject.htm
Zitat: "Microsoft meint wohl immer noch, dass sie einem "DMARC p=reject" einer Absenderdomain nicht vertrauen sollten, weil sie ja doch falsch sein könnte und damit die Support Tickets für nicht zugestellte Mails ansteigen würden."
@MaxM
ich hab da jetzt 2x überflogen, aber geht es hier nicht um einen Spoof der @microssoft.com Domain zu seinem eigenen Tenant?
Das wäre aber doch etwas anders, als einen Spoof von @meinerEigendenDomain.com.
Wir Unterhalten uns ja über das "direct send", und das gilt ja nur für seine eigene Domain.
Kann mir gut vorstellen, dass M$ da mit der Verwendung ihrer eigenen Domains mehr Probleme hat (nur eine Vermutung) und Exchange Onlineprotection deshalb anders reagiert.
P.S.: Ich habe im übrigen eine E3 und bekomme die Mail nicht zugesendet
P.P.S: Ich habe im nur eine die Default Office365 AntiPhish Regel. Unterschiedliche Einstellungen bewirken da sicherlich auch ein anders Verhalten. Aber da arbeite ich mit den von M$ empfohlenen Settings.
@Dirk: Der Thread-Ersteller hatte Probleme mit einer Email, die von anwender.anwender@firma.com an anwender.anwender@firma.com über DirectSend eingeliefert wurde. Also ein Spoff der eigenen Domain.
Mit der microsoft.com-Domain hat das nichts zu tun.
Und er schreibt: "Ein paar Anwendern wurden gespoofte Nachrichten zugestellt, was technisch eigentlich ausgeschlossen sein sollte, da SPF, DKIM und DMARC über ein E-Mail-Gateway geprüft werden."
Dh. seine Einstellungen sind (anscheinend) korrekt, trotzdem missachtet Exchangeonline-Protection diese und stellt das gespoofte Email mit Absender @meinerEigendenDomain.com zu.
Das sieht man schön an action=oreject.
Egal: Das lässt sich nicht final klären, aber es gibt IMHO eindeutige Indizien, dass EOP p=reject (auch bei richtigen Defender-Settings) im Einzelfall nicht beachtet.