[English]Microsoft hat etwas "richtig cooles" angekündigt. Es gibt jetzt eine öffentliche Vorschau (Public Preview) von Inbound SMTP DANE mit DNSSEC für Exchange Online. Microsoft zeigt sich erfreut, diese öffentliche Vorschau von Inbound SMTP DANE with DNSSEC ankündigen zu können. Mit der neuen Funktion von Exchange Online soll die Sicherheit der E-Mail-Kommunikation durch die Unterstützung zweier Sicherheitsstandards erhöht werden. Gab dann auf Facebook schon ein "vergiftetes" Lob für diesen Move.
Anzeige
Die Ankündigung Microsofts
Mir ist das Thema sowohl auf Facebook (über den erwähnten Post) als auch auf X über nachfolgenden Tweet untergekommen. Microsoft hat die Details im Techcommunity-Beitrag Announcing Public Preview of Inbound SMTP DANE with DNSSEC for Exchange Online veröffentlicht.
Dort freut man sich, die öffentliche Vorschau (Preview) von Inbound SMTP DANE with DNSSEC ankündigen zu können. Die neue Funktion von Exchange Online soll die Sicherheit der E-Mail-Kommunikation durch die Unterstützung zweier Sicherheitsstandards (DANE und DNSSEC) erhöhen.
DANE und DNSSEC, was ist das?
DANE (DNS-based Authentication of Named Entities) ist ein Netzwerkprotokoll, das dazu dient, den Datenverkehr abzusichern. Das Protokoll erweitert die verbreitete Transportwegverschlüsselung SSL/TLS in der Weise, dass die verwendeten Zertifikate nicht unbemerkt ausgewechselt werden können, und erhöht so die Sicherheit beim verschlüsselten Transport von E-Mails und beim Zugriff auf Webseiten. Die Normen und Standards sind 2011 bis 2015 entstanden.
Anzeige
DNSSEC steht für Domain Name System Security Extensions, eine Reihe von Internetstandards, die das Domain Name System (DNS) um Sicherheitsmechanismen zur Gewährleistung der Authentizität und Integrität der Daten erweitern. Ein DNS-Teilnehmer kann damit verifizieren, dass die erhaltenen DNS-Zonendaten auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen Cache Poisoning entwickelt. Es sichert die Übertragung von Resource Records durch digitale Signaturen ab. Eine Authentifizierung von Servern oder Clients findet nicht statt. Vertraulichkeit ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht verschlüsselt.
Microsoft stellt das neue Feature bereit
Die beiden neuen Features stehen sofort für Exchange Online bereit. SMTP DANE verwendet einen TLS-Authentifizierungs-DNS-Eintrag (TLSA), um die Identität eines Ziel-Mailservers zu überprüfen. Die neue Funktion bietet eine sichere Verbindung zwischen dem sendenden und dem empfangenden Mailserver, die sowohl gegen TLS-Downgrade-Angriffe als auch gegen Adversary-in-the-Middle-Angriffe resistent ist.
DNSSEC verwendet kryptografische Signaturen, um sicherzustellen, dass die DNS-Einträge der Zieldomäne authentisch sind und während der Übertragung nicht manipuliert wurden. Diese beiden Standards werden kombiniert, um Spoofing, Hijacking und das Abfangen von E-Mail-Nachrichten in Exchange Online zu verhindern.
Microsoft hat Outbound SMTP DANE mit DNSSEC im Jahr 2022 veröffentlich. Im Jahr 2024 zieht man nun mit der öffentlichen Vorschau für Inbound SMTP DANE mit DNSSEC nach. Ach so, das Ganze soll sogar kostenlos sein, weil Microsoft sich bemüht, die die E-Mail-Sicherheit für Nutzer zu verbessern.
Microsoft hat bereits Inbound SMTP-DANE mit DNSSEC für mehrere Outlook-E-Mail-Domänen implementiert und will die Implementierung für die übrigen Outlook-Domänen (einschließlich Hotmail) bis Ende 2024 abschließen. Die öffentliche Vorschau für Inbound SMTP DANE mit DNSSEC wird derzeit eingeführt.
Anleitungen zur Implementierung in einem Tenant finden sich im Artikel How SMTP DNS-based Authentication of Named Entities (DANE) secures email communications. Im Techcommunity-Beitrag, der noch einige Details beinhaltet, kommentiert ein Benutzer, dass die Commandlets noch nicht zu existieren scheinen, wenn er versucht, sie auszuführen.
Ein "vergiftetes" Lob aus dem Feld
Im Techcommunity-Beitrag feiert Microsoft sich als "Innovator" und fordert "andere E-Mail-Anbieter und Domaininhaber auf, diese Standards zu übernehmen und gemeinsam die Messlatte für die E-Mail-Sicherheit höher zu legen und die Benutzer vor böswilligen Akteuren zu schützen."
Ein mir namentlich bekannter Nutzer, der als Administrator unterwegs ist, zeigt sich "voll des Lobes"" für den innovativen Einsatz Microsofts, hat er dies doch bereits 2014 umgesetzt. Nun zieht Microsoft nach fast 10 Jahren nach. Passt, manche Dinge brauchen etwas länger und "gut Ding will Weile haben" dazu ein. Und wenn es dann auch noch funktioniert, sind alle glücklich.
Anzeige
gähn… weckt mich wenn Microsoft es endlich schafft, auf seinen Mailservern TLS 1.3 zu reden…
aber so richtig interessieren tut mich das auch wieder nicht. Bin eher am Überlegen den ganzen outlook.com MS Müll mit seinem Spam einfach auf meinem MX pauschal zu blocken…
Moin,
das kannst du privat evtl. machen aber im Business Umfeld wird dein AG keine 4 Wochen diese Strategie durchhalten. Dazu ist die Microsoft Cloud inzwischen zu mächtig.
ich bin meiner eigener Arbeitgeber und verzichte gerne…
Auf meinem MX kommen 90% aller Spams von gmail, hotmail und outlook.com
Für mich klingt es eher so, als ob Microsoft seinen eingehenden (inbound) Mail-Verkehr absichern will.
Vermutlich haben sie inzwischen auch ein massives Spam-Problem und wollen den Mist nicht erst mittels KI aus der eingegangenen Mail herausfischen, sondern gleich vor Einlieferung ablehnen.
Vermutlich wirst Du dann eher als nicht-MS-Anwender unsanft geweckt, falls z.B. Deine DNSSEC-Records nicht stimmen und Du überhaupt keine Mail mehr an Exchange Online einliefern kannst – selbst wenn Du es mal willst.
Microsoft wird das vermutlich abschaltbar machen (so wie jetzt auch die anderen Einstellungen in den Konnektoren, z.B. SPF), hat damit aber die Entscheidung zwischen Pest (Spam) und Cholera (wichtige Mails kommen nicht an) zum Anwender verlagert.
Ich wage zu behaupten mein Mailserver ist besser und strenger konfiguriert als der Müll bei MS, Google und den typischen Massenhostern wie IONOS.
Mach das und dein MX verschwindet in der Bedeutungslosigkeit.
Frage an @Exchange-Online-Administratoren:
Wir haben ein 3rd-party Email Gateway VOR Exchange-Online und relayen heute ALLE unsere Domains an den generischen Smarthost .mail.protection.outlook.com weiter.
Ab Ende 2024 erhalten alle neuen Domains einen MX-Record unter *.mx.microsoft, also z.B. neuedomain-de..mx.microsoft.
Wird dann der generische Smarthost .mail.protection.outlook.com für die neuen Domains noch funktionieren?
PS: Ich gehe davon aus, dass für die EXISTIERENDEN Domains der Smarthost noch funktionieren wird, solange ich nicht per Powershell Inbound SMTP DANE with DNSSEC für die existerenden Domains aktiviere und somit einen Umzug des MX records in die neue *.mx.microsoft-Infrastruktur veranlasse.
„ Ab Ende 2024 erhalten alle neuen Domains einen MX-Record unter *.mx.microsoft, also z.B. neuedomain-de..mx.microsoft."
Dazu habe ich bisher nichts gelesen bzw. gehört. Woher hast du die Info?
Ich würde aber davon ausgehen, dass ein generischer Smarthost weiter möglich ist und/oder sehr lange übergangsfristen bestehen. Schon jetzt ist es ja so, dass Emails für die Domain example.com auch bei example-de.mail… eingeliefert werden können. Wieso sollte man daran etwas ändern?
Zum den Übergangsfristen: wenn jetzt Anpassungen an Kundendomains erforderlich sind (also wenn auch bestehende Domains auf .mx.microsoft umgezogen werden – ist ja der nächste logische Schritt), wird es auf jeden Fall lange Fristen geben (wenn man das überhaupt ändert).
Ansonsten scheinst du die Thematik ja auf dem Schirm zu haben, also eine Änderung auch kurzfristig möglich.
Magst du mal deine Sorgen teilen? Würde mich interessieren.
@JohnRipper:
Der Fakt steht in obig verlinken TechCommunity-Beitrag:
"Transition provisioning of mail records for all NEWLY created Accepted Domains into DNSSEC-enabled infrastructure underneath *.mx.microsoft."
Wir haben größer 100 Domains und da ist es einfacher EINEN Smarthost fürs Relaying einzutragen als 100 individuelle Smarthosts a la domain1_de.mail.protection.outlook.com, domain2_de.mail.protection.outlook.com …
oder später eben
newdomain1_de.subdomain.mx.microsoft,
newdomain2_de.subdomain.mx.microsoft …
Ich habe den Artikel noch nicht vollständig gelesen, va als in den Kommentaren der Hinweis aufgetaucht ist, dass die Funktionen noch gar nicht aktiviert werden können …
Zum Thema: das Thema SMTP Dane ist doch eine Frage zwischen 3rd Party MX und deinem „3rd-Party Gateway". Die Weiterleitung erfolgt über einen Connector. Ob dieser zwangsläufig auf SMTP Dane besteht würde ich in Frage stellen, lassen sich doch heute schon/noch sämtliche EXO Protection Features (SPF/DKMI, Spam-Checks, usw.) deaktivieren.
Insofern würde ich *vermuten*, dass für Inbound SMTP Dane soweit abschaltbar ist. Insofern sind die technischen Hürden der Verschlüsselung zu umgehen.
Die andere Frage ist eben, ob es weiterhin ein Endpoint gibt den du nutzen kannst.
Im Grunde ist deine Konfiguration schon heute ja nicht (mehr) unterstützt. Natürlich ist sie einfach, aber du hast immer das Risiko, dass Microsoft kurzfristig die Einlieferung von Mails an spezifische Server bindet, die eben über die Domainspezifischen MX gesteuert werden. Innerhalb der Organisation unwahrscheinlich, aber bspw. Regionenübergreifend denkbar.
Ich habe keine Lust das zu überwachen und verwende die empfohlene Konfiguration.
@JohnRipper: Deine Ausführungen sind alle richtig, und ich stimme ihnen zu.
Für Deine Aussage "Im Grunde ist deine Konfiguration schon heute ja nicht (mehr) unterstützt" hätte ich jetzt gern eine Quelle ;-)
Klar hat jede accepted Domain einen eigenen MX record und damit einen eigenen Hostnamen für die Emailannahme, den ich je Domain nutzen könnte. Aber wo steht, dass man z.B. den Hostnamen der generischen Domain tenantname.onmicrosoft.com nicht nutzen soll, wo doch jeder Tenant definitiv eine solche Default-Domain hat?
Sagen wir so: es ist anders dokumentiert, aber im Moment läuft es.
Ein "dig" liefert
;; ANSWER SECTION:
mx.mail.protection.outlook.com. 10 IN A 52.101.11.19
mx.mail.protection.outlook.com. 10 IN A 52.101.42.9
mx.mail.protection.outlook.com. 10 IN A 52.101.41.4
mx.mail.protection.outlook.com. 10 IN A 52.101.41.26
wobei derselbe Record-Set geliefert wird wie bei all unseren Tenants als "tenantname".mail.protection.outlook.com.
Im SMTP-Protokoll spielt dieser Hostname sowieso keine Rolle mehr, nur das, was nach "HELO" kommt.
Ich habe teilweise andere RR-Sets bekommen, selbst bei Anfragen zu gleichen Zeitpunkt. Funktioniert hat es aber trotzdem immer.
Meine Beobachtungen sind aber auch schon eine Weile alt.
Wir sind nicht im öffentlichen Recht, wo erlaubt ist, was nicht verboten ist. Microsoft macht eine Vorgabe und an die sollte sich gehalten werden.
Die Anforderung ist, dass die im Admin-Center angezeigten MX verwendet werden. Insofern bedarf es keiner weiteren Ausführungen, dass es nicht unterstützt sei. Ich habe ja auch nicht behauptet, dass es nicht funktioniert, sondern nur gesagt, dass Microsoft jederzeit mit Änderungen deine Konfiguration lahmlegen kann. Auch habe ich gesagt, dass ich das als unwahrscheinlich ansehe.
Aber spätestens bei Problemen in die der Microsoft Support einbezogen wird, wird man dir sagen, dass das so nicht geht (wenn er es denn merkt :)
Dass du aber ggf ein Problem damit hast, weißt du schon selbst, sonst hätte sich deine ursprüngliche Frage erledigt :)
@JohnRipper: Alles klar! Nur noch für's Protokoll: Ich habe eine Email an user@domain1.de über den Smarthost domain2-de.mail.protection.outlook.com erfolgreich abgeben können. Domain1.de und domain2.de waren dabei beide accepted domains im ein- und demselben Tenant. Das zeigt nochmal deutlich, dass die empfangenden Server wohl einen großen Pool bilden und es egal ist, an welchem Smarthost man die Email abgibt. Hauptsache, die Empfangsdomain existiert im selben Tenant.
Meine letzten Beobachtungen (wie gesagt schon eine Weile alt) hatten gezeigt dass es nichtmal eine Domain in der selben Organisation sein muss. Selbst völlige andere Regionen waren möglich.
Ich gehe von einem sehr großen Pool an Servern inkl Multihoming aus. Alleine die DDos wird ein gutes Stück Arbeit, dazu die Spamabwehr, die ja teilweise erst während der Verbindung passiert.
Wir wissen vermutlich alle nicht genau, was Microsoft vorhat bzw. mit dieser Preview vielleicht auch schon umgesetzt hat.
Der neue Namensraum liegt jedenfalls nicht mehr unter .com, damit ist man für die Zertifikatskette nicht mehr auf die ICANN bzw. Verisign angewiesen, sondern für .microsoft hält man die nötigen Wurzelzertifikate selbst in der Hand.
"(tenant).mail.protection.outlook.com." war vermutlich ein Wildcard-DNS-Eintrag, für "(tenant).mx.microsoft." könnte ich mir vorstellen, daß Microsoft die notwendigen Einträge "on the fly" beim Anlegen eines Tenant generiert, signiert und binnen Minuten im DNS propagiert.
Vielleicht gibt es bald ein (tenant).sharepoint.microsoft. oder (tenant).teams.microsoft. Das ist ein völlig neuer Namensraum, wenn "borncity.com" schon weg ist, kann man dann halt "borncity.teams.microsoft" oder vielleicht irgendwann auch auch "borncity.microsoft" kaufen bzw. vermutlich eher mieten.
Und vor allem – wenn man einzelne Zertifikate für die Records hat, kann man bei Bedarf auch "(tenant).mx.microsoft." das Vertrauen entziehen und die Signatur des Eintrages widerrufen, ohne daß es andere Tenants tangiert.
Die gewählten Subdomains sollen unter x.cloud.microsoft sein und ein einheitlicher Namensraum für die Services zu dem bisherigen Wildwuchs.
Gestern auf meinem privaten Tenant eingerichtet. Funktionierte ohne große Mühen und war nach 20 Minuten vollständig eingerichtet und getestet. Schön, dass es auch mal unkompliziert geht.