SMTP-Relay in der Office 365-Umgebung | Fehlerbehebungsszenarien |Teil 4#4

Der aktuelle Artikel widmet sich dem Thema - Behebung möglicher Probleme bei der Verwendung eines SMTP-Mail-Relay-Servers zum Senden von E-Mails an die Office 365-Mail-Infrastruktur.

Senden Sie eine E-Mail an Exchange Online - Artikelserie

E-Mail an Exchange Online senden | Teil 1#4
Senden Sie E-Mails über eine Standard-SMTP-Sitzung an Exchange Online | Teil 2#4
SMTP-Relay in der Office 365-Umgebung | Teil 3#4
SMTP-Relay in der Office 365-Umgebung | Fehlerbehebungsszenarien |Teil 4#4

Im vorherigen Artikel besprechen wir das Konzept, wie der IIS-SMTP-Server als Mail-Relay in einer Office 365-basierten Umgebung konfiguriert wird.

Bei Verwendung der Option SMTP-Mail-Relay in einer Office 365-Umgebung kann der E-Mail-Fluss als komplex angesehen werden, da an diesem Prozess mehrere Elemente beteiligt sind und jedes dieser Elemente spezifische Eigenschaften oder spezifische Konfigurationseinstellungen aufweist.

In einem Szenario, in dem wir ein Problem haben, bedeutet dies, dass E-Mails, die vom Quell-Mail-Client (Hardwaregerät, E-Mail-Anwendung usw.) gesendet werden, ihr Ziel (den Office 365-Empfänger oder einen anderen externen Empfänger) nicht erreichen Auf die genaue Ursache des Problems hinzuweisen, ist nicht so einfach.

Ein Szenario, in dem ein FAX-Gerät beispielsweise eine E-Mail-Nachricht an den Office 365-Empfänger senden muss, umfasste die folgenden Schritte:

Das FAX-Gerät verbindet den IIS-SMTP-Mail-Relay-Server (IIS-Server in unserem Szenario).
2. Der SMTP-Mail-Relay-Server ist bereit, die Anfrage vom Mail-Client (in unserem Szenario das Faxgerät) anzunehmen.
Der SMTP-Mail-Relay-Server verbindet den „Ziel-Mail-Server“ (in unserem Szenario den EOP-Mail-Server).
Der „Ziel-Mailserver“ ist bereit, die Anfrage vom SMTP-Mail-Relay-Server anzunehmen.
Der „Ziel-Mail-Server“ (EOP) sendet die E-Mail-Nachricht an den Zielempfänger.

Tatsächlich umfasst der E-Mail-Fluss zusätzliche Schritte, die wir nicht erwähnt haben, wie z. B. die Durchführung eines DNS-Auflösungsprozesses und so weiter.

Aufgrund dieser Komplexität müssen wir mit den verschiedenen Komponenten vertraut sein, die am E-Mail-Fluss beteiligt sind, und mit den Fehlerbehebungsschritten, Fehlerbehebungstools und Methoden vertraut sein, die wir in einem Szenario verwenden können, in dem der E-Mail-Fluss nicht erfolgreich abgeschlossen wird.

E-Mail-Fluss simulieren | E-Mails, die vom internen E-Mail-Client über den IIS-SMTP-Mail-Relay-Server gesendet werden

Nachdem wir alle erforderlichen Konfigurationen abgeschlossen haben, besteht die beste Vorgehensweise darin, einen „POC“-Test (Proof of Concept) durchzuführen. Dadurch können wir überprüfen, ob der E-Mail-Fluss korrekt implementiert ist, was bedeutet, dass die E-Mail-Nachricht erfolgreich das Postfach des Zielempfängers erreicht.

Um den E-Mail-Fluss bei Verwendung eines SMTP-Mail-Relays testen und überprüfen zu können, simulieren wir einen E-Mail-Fluss, bei dem der E-Mail-Client der Organisation versucht, eine E-Mail an den Office 365-E-Mail-Empfänger zu senden.

Die „Parameter“, die wir überprüfen und verifizieren möchten, sind:

Die Fähigkeit des E-Mail-Clients, Kontakt zum IIS-SMTP-Mail-Relay-Server aufzunehmen, und die Fähigkeit des IIS-SMTP-Mail-Relay-Servers, mit dem Office 365-Mail-Server zu kommunizieren.
Die Fähigkeit des IIS-SMTP-Mail-Relay-Servers, E-Mails im Namen eines anderen E-Mail-Clients zu senden. Wie im Artikel -SMTP-Relay in der Office 365-Umgebung | erwähnt Teil 3#4, in einem Szenario, in dem der IIS-SMTP-Mail-Relay-Server Anforderungen von verschiedenen E-Mail-Clients akzeptiert und die E-Mail-Nachricht an den Office 365-Mail-Server „weiterleiten“ muss, das Benutzerkonto, das vom IIS-SMTP verwendet wird Der Mail-Relay-Server muss über die Berechtigung Senden als für jeden „Mail-Client“ verfügen, der ihn anspricht.

Um diese Parameter zu überprüfen, werden wir zwei verschiedene Tests verwenden.

Test 1 - ein einfacher Test, bei dem wir einen E-Mail-Client simulieren, der dieselbe E-Mail-Adresse verwendet wie die Benutzeranmeldeinformationen, die vom IIS-SMTP-Mail-Relay-Server verwendet werden.

Test 2 - E-Mail-Client simulieren, der eine andere E-Mail-Adresse als die Benutzeranmeldeinformationen verwendet, die vom IIS-SMTP-Mail-Relay-Server verwendet werden. In diesem Fall möchten wir überprüfen, ob die erforderliche Berechtigung Senden als für das Benutzerkonto des IIS-SMTP-Mail-Relay-Servers definiert wurde.

So simulieren Sie den E-Mail-Fluss.

In unserem Szenario könnte der „echte“ Mail-Client ein Hardwaregerät wie ein Faxgerät, ein Scanner oder ein Drucker oder eine E-Mail-fähige Anwendung sein.

Das Hauptproblem besteht darin, dass dieser „Mail-Client“ in den meisten Fällen nicht über die Möglichkeit verfügt, im Falle eines Ausfalls genaue Informationen bereitzustellen, d. h. in einer Situation, in der E-Mails nicht an den Zielempfänger gesendet werden.

Mit dem SMTP-Telnet-Client-Dienstprogramm können wir den E-Mail-Fluss simulieren und den Inhalt des Kommunikationskanals zwischen dem E-Mail-Client und dem E-Mail-Server (in unserem Szenario das IIS SMTP-Mail-Relay) „sehen“. Darüber hinaus können wir die Option „Debuggen“ (Schritt-für-Schritt-Senden aktivieren) verwenden, um Informationen über die spezifische Ursache des Problems zu erhalten.

Test 1 - Verwendung von SMTP-Mail-Relay | Zielempfänger=SMTP-Mail-Relay-Anmeldeinformationen

Im ersten Test möchten wir überprüfen, ob der E-Mail-Fluss erfolgreich abgeschlossen werden kann, was bedeutet, dass alle verschiedenen „Elemente“, die am E-Mail-Fluss beteiligt sind, miteinander kommunizieren können.

In unserem Szenario identifiziert sich der E-Mail-Client mithilfe einer E-Mail-Adresse, die mit den Benutzeranmeldeinformationen identisch ist, die vom IIS-SMTP-Mail-Relay verwendet werden.

Bezüglich der Betreffzeile „Zielempfänger“ zur E-Mail-Adresse des Ziels spielt der Empfänger keine Rolle, solange wir die Möglichkeit haben, auf das Postfach des Zielempfängers zuzugreifen und zu überprüfen, ob er unsere Testmail erhalten hat.

Der Charakter des aktuellen Szenarios ist:

Quellempfänger - John@o365info.com
IIS-SMTP-Mail-Relay-Anmeldeinformationen - John@o365info.com
Zielempfänger - John@o365info.com

Verwenden Sie die Registerkarte Telnet-Eigenschaften zum Konfigurieren der Kommunikationseinstellungen mit der internen Schnittstelle des IIS-SMTP-Mail-Relay-Servers.

Connector-IP empfangen: Fügen Sie die IP-Adresse des IIS-SMTP-Servers hinzu (in unserem speziellen Szenario lautet die IP-Adresse - 10.13.137.2).
TCP-Port: Dies ist die Portnummer des IIS SMTP-Mail-Relays „LAN-Schnittstelle“. Der Standardport, der für die „Auflistung“ im E-Mail-Client verwendet wird, ist - 25
Mail From: Im Textfeld müssen wir die E-Mail-Adresse hinzufügen, die den internen E-Mail-Client darstellt, der eine E-Mail-Nachricht über senden möchte IIS SMTP-Mail-Relay. In unserem speziellen Szenario ist der Quellempfänger - John@o365info.com
Empfänger an: in diesem Text Im Feld müssen wir die E-Mail-Adresse des „Zielempfängers“ hinzufügen, der die E-Mail vom internen E-Mail-Client erhalten soll. In unserem speziellen Szenario ist der Office 365-Zielempfänger - John@o365info.com
Betreff: Dies ist ein optionaler Parameter, der den „Betreff-Header“ erstellt. In unserem speziellen Szenario lautet der Betreff Test 001

Um die E-Mail-Nachricht zu senden, müssen wir die Registerkarte Telnet auswählen und auf die Option SENDEN klicken

Im folgenden Screenshot können wir sehen, dass der „erste Teil“ in unserem E-Mail-Fluss, der Teil, in dem der interne E-Mail-Client die interne Schnittstelle des IIS SMTP-Mail-Relays anspricht, abgeschlossen ist.

Das IIS-SMTP-Mail-Relay „stimmt“ der Annahme der E-Mail-Nachricht zu und „informiert“ den E-Mail-Client darüber, dass sich die E-Mail in der Warteschlange zur Zustellung befindet

Die Tatsache, dass der erste Teil des E-Mail-Versands erfolgreich abgeschlossen wurde, bedeutet nicht, dass wir davon ausgehen können, dass die E-Mail-Nachricht das Zielpostfach des Office 365-Empfängers erreicht hat.

Um überprüfen zu können, ob die E-Mail vom IIS-SMTP-Mail-Relay an die Office 365-Mailserver gesendet wurde (das EOP, das durch den Hostnamen smtp.office365.com dargestellt wird). ) müssen wir auf das Postfach des Zielempfängers (in unserem Beispiel John) zugreifen, um zu überprüfen, ob er die E-Mail-Nachricht erhalten hat.

Im folgenden Screenshot können wir sehen, dass die E-Mail-Nachricht Johns Postfach erreicht.

Test 2 - Überprüfen Sie die Fähigkeit des SMTP-Mail-Relays, E-Mails im Namen verschiedener E-Mail-Clients zu senden.

Falls der erste Test erfolgreich abgeschlossen wurde und wir wissen, dass der E-Mail-Fluss korrekt konfiguriert ist, besteht der nächste Schritt darin, die Fähigkeit des IIS-SMTP-Mail-Relays zu überprüfen, eine E-Mail-Nachricht im Namen verschiedener E-Mail-Clients zuzustellen.

Die zugrunde liegende Annahme besteht beispielsweise darin, dass jeder E-Mail-Client, der den IIS-SMTP-Mail-Relay-Server anspricht, sich anhand einer eindeutigen E-Mail-Adresse identifiziert.

Der IIS-SMTP-Mail-Relay-Server identifiziert sich gegenüber den Mail-Servern von Office 365, indem er ein bestimmtes Benutzerkonto (John@o365info.com in unserem Szenario) verwendet und E-Mails zustellen kann Namen eines anderen E-Mail-Empfängers; Das IIS-SMTP-Mail-Relay-Server-Benutzerkonto muss für jeden E-Mail-Client, den er verwenden möchte, mit der Berechtigung Senden als konfiguriert werden „Weiterleiten“ ihrer Anfragen an den Office 365-Mailserver.

Die Charaktere des aktuellen Szenarios sind:

Quellempfänger - Fax@o365info.com
IIS-SMTP-Mail-Relay-Anmeldeinformationen - John@o365info.com
Zielempfänger - John@o365info.com

Beachten Sie, dass in einem solchen Szenario das IIS-SMTP-Mail-Relay über die Berechtigung „Senden als“ verfügen muss, um dies zu ermöglichen um die E-Mail-Nachricht im Namen des Quell-E-Mail-Empfängers zu senden (in unserem Szenario Fax@o365info.com).

Verwenden Sie die Registerkarte Telnet-Eigenschaften zum Konfigurieren der Kommunikationseinstellungen mit der internen Schnittstelle des IIS-SMTP-Mail-Relay-Servers.

Connector-IP empfangen: Fügen Sie die IP-Adresse des IIS-SMTP-Servers hinzu (in unserem speziellen Szenario lautet die IP-Adresse - 10.13.137.2).
TCP-Port: Dies ist die Portnummer des IIS SMTP-Mail-Relays „LAN-Schnittstelle“. Der Standardport, der für die „Auflistung“ im E-Mail-Client verwendet wird, ist - 25
Mail From: Im Textfeld müssen wir die E-Mail-Adresse hinzufügen, die den internen E-Mail-Client darstellt, der E-Mail-Nachrichten über IIS senden möchte SMTP-Mail-Relay. In unserem speziellen Szenario ist der Quellempfänger - Fax@o365info.com
Empfänger an: in diesem Text Im Feld müssen wir die E-Mail-Adresse des „Zielempfängers“ hinzufügen, der die E-Mail vom internen E-Mail-Client erhalten soll. In unserem speziellen Szenario ist der Office 365-Zielempfänger - John@o365info.com
Betreff: Dies ist ein optionaler Parameter, der den „Betreff-Header“ erstellt. In unserem speziellen Szenario lautet der Betreff Test 002.

Um die E-Mail-Nachricht zu senden, müssen wir die Registerkarte Telnet auswählen und auf die Option SENDEN klicken

Das IIS-SMTP-Mail-Relay „stimmt“ der Annahme der E-Mail-Nachricht zu und „informiert“ den E-Mail-Client darüber, dass sich die E-Mail in der Warteschlange zur Zustellung befindet

In unserem Szenario werden wir feststellen, dass die E-Mail nicht erfolgreich an die Office 365-Empfänger gesendet wurde.

Das IIS-SMTP-Mail-Relay stimmt der Annahme der E-Mail zu, aber im nächsten Abschnitt werden wir sehen, dass der Ziel-Mailserver (der Office 365 EOP-Server) der Annahme der E-Mail-Nachricht nicht zugestimmt hat .

Wenn wir auf das Postfach des Zielempfängers (in unserem Beispiel John) zugreifen, stellen wir fest, dass die E-Mail-Nachricht Johns Postfach nicht erreicht hat!

Die Fragen, die angezeigt werden, sind:

F1: Was ist der Grund für das Scheitern des E-Mail-Flusses?

F2: Wie können wir Informationen über die Ursache des Fehlers im E-Mail-Fluss finden?

F3: Wie können wir dieses Problem mit dem Nachrichtenfluss beheben?

Lesen Sie die Protokolldatei des IIS-SMTP-Servers, um weitere Informationen zu erhalten

A1: Die Ursache für den Fehler beim Nachrichtenfluss ist ein Berechtigungsproblem, oder wenn wir genauer sein wollen - „Senden als ”Berechtigungsproblem. Das Benutzerkonto, das die IIS SMTP-Mail-Relay-Benutzer (John@o365info.com) verwenden, verfügt nicht über die erforderlichen Berechtigungen zum Senden von E-Mails im Namen des E-Mail-Empfängers - Fax@o365info.com

A2: Um detailliertere Informationen über den E-Mail-Fluss und die Ursache des Fehlers zu erhalten, verwenden wir den E-Mail-Zustellungsbericht des IIS-SMTP-Mailservers, der in einem Ordner mit dem Namen Badmail gespeichert ist.

Der vollständige Pfad des Badmail-Ordners lautet: C:\inetpub\mailroot\Badmail

Im folgenden Screenshot sehen wir die Informationen, die im Badmail-Ordner gespeichert wurden. Der IIS-SMTP-Server generiert für jeden „Mail-Zustellungsfehler“ drei verschiedene Dateien.

Zwei der Dateien, die im Badmail-Ordner erscheinen, oder nur eine einfache Textdatei.

Um weitere Informationen über die Ursache des Fehlers zu erhalten, werden wir versuchen, die Informationen in der Datei mit der Dateierweiterung *.BDR zu lesen

In der Protokolldatei sehen wir die folgende Fehlermeldung: Der spezifische Fehlercode war 0xC00402C7

Das Problem ist, dass wir dieser Fehlermeldung nicht viel entnehmen können.

Weitere nützliche Informationen über die Ursache des Fehlers finden Sie in der Datei mit der Erweiterung - *.BAD

Wenn wir uns den Inhalt der „BAD-Datei“ ansehen, können wir sehen

Die Zustellung an die folgenden Empfänger ist fehlgeschlagen. - john@o365info.com

Und zusätzlich -

Endempfänger: rfc822;john@o365info.com
Aktion: fehlgeschlagen
Status: 5.7.60
Diagnosecode: smtp;550 5.7.60 SMTP; Der Client verfügt nicht über die Berechtigung, als dieser Absender zu senden

Die Bedeutung dieser Fehlermeldung besteht darin, dass das IIS-SMTP-Mail-Relay den Office 365-Mailserver (EOP-Server) anspricht und versucht, die E-Mail an den Quell-Mail-Empfänger „zuzustellen“ - Fax@o365info .com

Weil die „Wolke“ das IIS-SMTP-Mail-Relay als - John@o365info.com identifiziert und weil John nicht über die erforderliche „Senden als"-Berechtigung zum Senden einer E-Mail im Namen des „Faxempfängers“ verweigert der EOP-Server die Annahme der E-Mail-Nachricht.

Weisen Sie dem IIS-SMTP-Server-Benutzerkonto die erforderliche Berechtigung „Senden als“ zu

Um dieses Problem „beheben“ zu können, weisen wir das Benutzerkonto zu, das vom IIS-SMTP-Mail-Relay verwendet wird - John@o365info.com im Senden als-Berechtigung für den „FAX-Empfänger“.

Hinweis: Die Grundannahme ist, dass wir bereits eine Verteilergruppe erstellt haben, die
die Mail-fähige FAX-Geräteentität darstellt.

Um die Berechtigung Senden als zuweisen zu können, melden wir uns bei der Exchange Online-Man-Agent-Schnittstelle an.

Wählen Sie das Empfängermenü und dann das Gruppenmenü
Doppelklicken Sie auf die gewünschte Verteilergruppe (in unserem Szenario FAX-Gruppe).

Wählen Sie das Menü - Gruppendelegation. Im folgenden Screenshot sehen wir, dass standardmäßig kein Empfänger über die Option Senden als verfügt Berechtigung für diese Gruppe.

Klicken Sie im Abschnitt Senden als auf das Pluszeichen, um Empfänger hinzuzufügen, die über die erforderlichen < verfügen span style="color: #008000;">Senden als-Berechtigung. In unserem speziellen Szenario möchten wir diese Berechtigung dem Empfänger namens John zuweisen, dem E-Mail-Empfänger, der vom IIS SMTP-Mail-Relay verwendet wird.

Nachdem wir die erforderlichen Berechtigungen hinzugefügt haben, können wir erneut versuchen, die E-Mail-Nachricht zu senden.

Im folgenden Screenshot können wir sehen, dass die Nachricht zu diesem Zeitpunkt erfolgreich das Postfach des Zielempfängers erreicht hat.

Falls Sie neugierig sind und Informationen über die E-Mail-Zustellung anzeigen möchten, die vom IIS-SMTP-Mail-Relay implementiert wird, können wir uns die Protokolldateien des IIS-SMTP-Mail-Relays ansehen.

Standardmäßig befinden sich die IIS-SMTP-Mail-Relay-Protokolldateien im folgenden Pfad:

C:\Windows\System32\LogFiles\SMTPSVC1

Im folgenden Screenshot können wir sehen, dass der Ordner SMTPSVC1 viele Protokolldateien enthält.
Wir müssen die aktuellsten Protokolldateien auswählen.

Wenn wir uns die Protokolldatei ansehen, können wir eine sehr detaillierte Beschreibung für jeden der Schritte sehen, die im E-Mail-Fluss zwischen dem IIS-SMTP-Mail-Relay und den Office 365-Mailservern implementiert wurden.

Wir können zum Beispiel sehen, dass die E-Mail aus wenigen Phasen besteht:

Phase 1 - die Phase, in der das IIS-SMTP-Mail-Relay den Office 365-Mailserver anspricht und die Sitzung auf einer TLS-Sitzung basiert.
Phase 2 - die Authentifizierungsphase, in der das IIS-SMTP-Mail-Relay seine Anmeldeinformationen dem Office 365-Mailserver bereitstellt
Phase 3 - die Phase, in der das IIS-SMTP-Mail-Relay die E-Mail-Nachricht an den Office 365-Mailserver „zustellt“ und Informationen über den Quell- und Zielempfänger bereitstellt.
Phase 4 - Der Office 365-Mailserver akzeptiert die E-Mail-Nachricht vom IIS-SMTP-Mail-Relay und speichert die E-Mail-Nachricht in der Warteschlange.

Überprüfen der Fähigkeit, über das TLS-Protokoll auf den Office 365-Mailserver zuzugreifen

In diesem Abschnitt erfahren Sie, wie Sie häufige „Ursachen“ für E-Mail-Flussprobleme bei Verwendung der IIS-SMTP-Relay-Option beheben können.

Fehlerbehebung beim TLS-basierten E-Mail-Fluss | Das Eliminierungskonzept

In einem Szenario, in dem es uns nicht gelingt, E-Mails an den Zielempfänger zu senden, ist die häufigste Reaktion: „Mit der Cloud stimmt etwas nicht.“

Wenn wir einen praktischeren Ansatz verfolgen möchten, sollte der Fehlerbehebungsprozess so implementiert werden, dass bestimmte Komponenten, die am Mail-Flow-Prozess beteiligt sind, eliminiert werden, bis wir klar auf das bestimmte Element hinweisen können, das nicht richtig konfiguriert ist.

Wenn beispielsweise eine E-Mail-Nachricht, die von einem E-Mail-Client wie einem FAX-Gerät gesendet wurde, ihr Ziel nicht erreicht hat, müssen wir überprüfen, ob alle am Prozess beteiligten Komponenten korrekt konfiguriert sind.

Im folgenden Diagramm sehen wir einen Standard-Mail-Fluss, wenn die Option des SMTP-Mail-Relays zum Senden einer E-Mail an die Office 365-Mail-Infrastruktur verwendet wird.

Im folgenden Abschnitt zeigen wir, wie Sie die folgenden Komponenten umgehen können:

Mail-Client (in unserem Beispiel das FAX-Gerät)
Das IIS-SMTP-Mail-Relay

Unser Hauptzweck besteht darin, dies zu überprüfen

Wir können mit der „Cloud“ (dem Office 365-Mailserver, dargestellt durch den Hostnamen -
smtp.office365.com ) über das TLS-Protokoll kommunizieren
Dass der Office 365-Mailserver bereit ist, unsere Anfrage anzunehmen und dem Zielempfänger zuzustellen oder eine E-Mail zu senden.

Das Konzept des „sicheren Kommunikationskanals“ in einer Office 365-Umgebung.

Nur eine kurze Erinnerung: Der „sichere Kommunikationskanal“ wird über Port 25 oder 587 implementiert. In unserem Szenario wird davon ausgegangen, dass der E-Mail-Fluss wie folgt angewendet wird:

Der Client adressiert den Ziel-Mailserver (den EOP-Server).
Der EOP-Server signalisiert dem Quellclient, dass er das TLS-Protokoll verwenden und Benutzeranmeldeinformationen bereitstellen muss.
Der Kunde stellt die erforderlichen Benutzeranmeldeinformationen bereit.
Es wird ein „Sicherer Kommunikationskanal“ (TLS) erstellt.
Der Client fordert vom EOP-Server an, eine E-Mail-Nachricht an einen Zielempfänger zu senden.

Der E-Mail-Client, der für den Testzweck verwendet wird

Im folgenden Abschnitt zeigen wir, wie Sie die TLS-Kommunikation mit dem Office 365-Mailserver mithilfe von drei verschiedenen E-Mail-Clients testen

Windows-Betriebssystem-Client
PowerShell-Skript
Grafischer Mail-Client namens JBMail

Option 1 - Überprüfen Sie die Kommunikation mit dem EOP-Server mithilfe des Windows-Telnet-Clients

Eine der einfachsten Möglichkeiten, einen Kommunikationskanal mit einem Mailserver (in unserem Szenario dem EOP-Server) zu überprüfen, ist die Verwendung einer Telnet-Sitzung.

Falls es uns gelingt, den Zielhost per „Telnet“ zu erreichen, können wir Folgendes wissen:

Es gelingt uns erfolgreich, den Hostnamen (smtp.office365.com in unserem Szenario) in IP-Adressen aufzulösen.
Dass uns die Netzwerk-Firewall den „Ausstieg“ über die erforderliche Portnummer (25 oder 587) ermöglicht.
Dass der Zielserver (Office 365-Mailserver) „aktiv“ ist und auf unsere Kommunikationsanfrage antworten kann.

Der einzige Haken ist, dass die Kommunikation mit dem Office 365-Mailserver - smtp.office365.com - über eine TLS-Sitzung implementiert werden sollte und der Standard-Telnet-Client des Windows-Betriebssystems dies nicht tut Unterstützt die Verwendung des TLS-Protokolls nicht.

Trotz dieser Einschränkung verwende ich die Option für den Telnet-Client unter Windows, da sie einfach und unkompliziert ist und es mir ermöglicht, die genannten wesentlichen Elemente zu überprüfen (Hostnamen auflösen usw.).

Verwendung des Windows-Telnet-Clients für die Kommunikation mit dem Office 365-Mailserver

Beispiel: Öffnen Sie eine Eingabeaufforderung und geben Sie die folgenden Befehle ein:

Telnet smtp.office365.com 25
Helo
mail from:john@o365info.com

Im folgenden Screenshot können wir sehen, dass der Kommunikationstest fehlschlägt und der EOP-Server die Fehlermeldung sendet:

530 5.7.57 SMTP; Der Client wurde während MAIL FROM nicht zum Senden anonymer E-Mails authentifiziert

Die Bedeutung dieser Fehlermeldung besteht darin, dass es dem „Quell-Client“ (in unserem Beispiel der Telnet-Client) nicht gelingt, die zwingende Anforderung für einen verschlüsselten Kommunikationskanal (in unserem Szenario TLS) erfolgreich zu erfüllen.

Der Grund für unser Scheitern liegt darin, dass wir für die konkrete Aufgabe die „falschen Werkzeuge“ verwenden. Ein „Standard-OS-Telnet-Client“ weiß nicht, wie er mithilfe von TLS einen sicheren Kommunikationskanal implementieren kann.

Option 2 - Verwendung eines PowerShell-Skripts zur Simulation eines sicheren Kommunikationskanals mit dem EOP-Server

Um einen sicheren Kommunikationskanal (TLS-Kanal) zwischen einem bestimmten Host und dem Office 365-Mailserver (dem EOP-Exchange Online-Schutzserver) simulieren zu können, könnten wir ein PowerShell-Skript verwenden.

Um die Eingabe komplizierter und seltsamer PowerShell-Befehle zu vermeiden, habe ich ein PowerShell-Skript bevorzugt, das einfach zu verwenden ist.

Der Code, der im PowerShell-Skript SendMail.ps1 enthalten ist

Im folgenden Screenshot sehen wir den Inhalt des PowerShell-Skripts SendMail.ps1.

Das Skript enthält vordefinierte Variablen wie den SMTP-Servernamen und die Portnummer smtp.office365.com und den Port 25 in unserem Szenario).

Um die TLS-Sitzung mit dem EOP-Server erfolgreich abschließen zu können, ist es wichtig zu verstehen, dass die zwingende Voraussetzung für die Erstellung des sicheren Kommunikationskanals mit dem EOP-Server die Bereitstellung der erforderlichen Office 365-Benutzeranmeldeinformationen (UPN-Name + Passwort) ist.

Die ersten beiden Parameter, die wir angeben müssen, sind der Office 365-Benutzername und das Passwort.

Der letzte Parameter ist die „E-Mail-Adresse des Zielempfängers“.

Verwendung des PowerShell-Skripts SendMail.ps1

Dann kann das E-Mail-PowerShell-Skript über die integrierte PowerShell-Konsole des Betriebssystems aufgerufen werden.
Um PowerShell ausführen zu können, müssen wir einen PowerShell-Richtlinienbefehl ausführen, der es uns ermöglicht, das PowerShell-Skript auszuführen (standardmäßig die PowerShell-Richtlinie erlaubt es uns nicht, ein Skript auszuführen).

In unserem Szenario wird versucht, einen sicheren Kommunikationskanal zwischen einem bestimmten Host und dem Exchange Online Protection-Server zu erstellen, indem die Anmeldeinformationen von Office 365-Benutzern mit dem Namen John@o365info.com verwendet werden

Um den Test zu vereinfachen, verwenden wir die E-Mail von John als „Ziel-E-Mail-Adresse“.

Erstkonfiguration eines PowerShell-Skripts ausführen

Suchen Sie die PowerShell-Konsole
Klicken Sie mit der rechten Maustaste auf das PowerShell-Symbol und wählen Sie die Option: Als Administrator ausführen

Führen Sie auf der PowerShell-Konsole den folgenden Befehl aus:

Set-ExecutionPolicy Unrestricted -force

Führen Sie das PowerShell-Skript SendMail.ps1 aus

Um das PowerShell-Skript „SendMail.ps1“ starten zu können, müssen wir das Skript über die PowerShell-Konsole „aufrufen“.

In unserem Beispiel wurde das PowerShell-Skript SendMail.ps1 im folgenden Pfad gespeichert:

C:\Script

Um ein PowerShell-Skript starten zu können, müssen wir die folgenden Zeichen eingeben: „.\ ” und dann den Skriptnamen.

Im folgenden Screenshot sehen wir ein Beispiel für die Ausführung des PowerShell-Skripts SendMail.ps1:

Im folgenden Screenshot sehen wir das Postfach von John. Wir können sehen, dass die von John gesendete E-Mail über das PowerShell-Skript Johns Postfach erreicht.

Option 3 - E-Mail-Nachricht über TLS an Exchange Online senden | GUI-Mail-Client

Im folgenden Abschnitt zeigen wir, wie Sie E-Mail-Nachrichten über eine verschlüsselte Kommunikationsverbindung (TLS) an Exchange Online (EOP) senden.

Die Mail-Client-Anwendung, die ich zum Zweck der Simulation der TLS-Sitzung namens JBMail gefunden habe.

Sie laden den Mail-Client über den folgenden Link JBMail herunter.

Die folgende Demonstration wurde mithilfe von zwei Schritten implementiert:

Konfigurieren Sie das E-Mail-Client-Profil - der Schritt, in dem wir die Benutzeranmeldeinformationen definieren, die für die Verbindung mit dem Exchange Online-Server verwendet werden, die Art des Kommunikationsprotokolls usw.
Erstellen (verfassen) Sie eine neue E-Mail-Nachricht.

Szenariobeschreibung

In unserem Szenario wird ein sehr einfacher Test implementiert: ein Empfänger namens: John@o365info.com, der E-Mails an sich selbst sendet, indem er eine Verbindung zum EOP-Server herstellt (smtp.office365.com) mit TLS.

Wählen Sie die Registerkarte Konto
Fügen Sie im Feld Benutzername die Anmeldeinformationen des Empfängers hinzu, mit denen er sich beim EOP-Server authentifiziert. In unserem Beispiel - John@o365info.com

Wählen Sie die Registerkarte Sendeeinstellungen
Geben Sie im Feld SMTP-Host den Hostnamen des EOP-Servers ein - smtp.office365.com (Nummer 1).
Geben Sie im Feld Benutzername den Namen des Empfängers ein, an den die E-Mail gesendet werden soll. In unserem Beispiel - John@o365info.com (Nummer 2).
Geben Sie im Feld Passwort das Passwort des Empfängernamens ein, den die E-Mail an ihn senden soll (Nummer 3).
Wählen Sie im Abschnitt Protokoll die Option - SSL über STARTTLS (Nummer 4 ). ).
Wählen Sie die Option - SMTP AUTH verwenden (Nummer 4).
Geben Sie im Feld „Ihre Adresse“ die E-Mail-Adresse des Empfängers ein, an den die E-Mail gesendet werden soll - in unserem Beispiel - John@o365info.com (Nummer 5).
Geben Sie im Feld „Port“ die Portnummer ein. In unserem Szenario Port 25 (Nummer 6).

Erstellen Sie eine neue E-Mail-Nachricht, indem Sie die Registerkarte Konto auswählen und auf Verfassen klicken

Fügen Sie im Feld AN die E-Mail-Adresse des Zielempfängers hinzu. In unserem Beispiel - John@o365info.com
Klicken Sie auf die Schaltfläche Senden, um die E-Mail-Nachricht zu senden

Die folgende Meldung wird angezeigt:
Wählen Sie die Option Akzeptieren

Im folgenden Screenshot können wir sehen, dass die E-Mail-Nachricht erfolgreich an den EOP-Server gesendet wurde.

Im folgenden Screenshot können wir sehen, dass die E-Mail von John akzeptiert wurde.

Wenn wir sicher sein möchten, dass die E-Mail über einen sicheren Kommunikationskanal (TLS) gesendet wurde, können wir uns den E-Mail-Header ansehen.

Doppelklicken Sie auf die E-Mail-Nachricht
Wählen Sie das Symbol für weitere Optionen (die drei Punkte)
Wählen Sie das Menü - Nachrichtendetails anzeigen

Im folgenden Screenshot sehen wir den Mail-Header der Nachricht, die an John gesendet wurde. Wir können sehen, dass die Kommunikation mithilfe von TLS implementiert wurde.

Überprüfen Sie die TLS-Einstellung des Mailservers

Die Implementierung eines „sicheren Kommunikationskanals“ zwischen dem IIS-SMTP-Mail-Relay im Office 365 EOP-Server wird mithilfe des TLS-Protokolls implementiert.

Das IIS-SMTP-Mail-Relay verfügt über eine integrierte Unterstützung im TLS-Protokoll und bietet alle erforderlichen Konfigurationseinstellungen, die im Artikel beschrieben wurden - xxx, den Kommunikationskanal zwischen dem IIS-SMTP-Mail-Relay und dem Office 365 EOP-Server dargestellt durch den Hostnamen: smtp.office365.com erstellt.

In einigen Fällen, wenn wir den Verdacht haben, dass das Problem mit der TLS-Infrastruktur zusammenhängt, liegt das E-Mail-Problem darin, dass der TLS-Kommunikationskanal eine „Black Box“ ist und wir standardmäßig keine einfache Möglichkeit haben, uns das TLS anzusehen Parameter.

Falls Sie daran interessiert sind, weitere Informationen über den Inhalt der TLS-Sitzung zu erhalten, können wir ein hervorragendes Website-Tool namens checktls verwenden, das uns dabei helfen kann, eine TLS-Sitzung zwischen Client und Mailserver zu testen.

Im nächsten Beispiel betrachten wir die TLS-Sitzung zwischen dem Office 365-Empfänger mit dem Namen: John@o365info.com und dem Office 365 EOP-Server - smtp.office365.com

Im Adresstext fügen wir die E-Mail-Nachricht des Empfängers hinzu - John@o365info.com und klicken auf Probieren Sie es aus

Im folgenden Screenshot sehen wir die Ergebnisse.

Nummer 1 - Dies ist eine Zusammenfassung aller TLS-Parameter, die am Kommunikationsprozess beteiligt sind. In unserem Szenario können wir sehen, dass der TLS-Kommunikationskanal erfolgreich abgeschlossen wurde und alle verschiedenen Parameter korrekt sind.

Nummer 2 - der Teil, der die E-Mail-Adresse des „Zielempfängers“ anzeigt.

Nummer 3 - die Webtestanwendung findet den Hostnamen des Office 365-Mailservers. In unserem Szenario - o365info-com.mail.protection.outlook.com

Nummer 4 - wir können sehen, dass die TLS-Sitzung „beginnt“, indem wir den SMTP-Befehl STARTTLS verwenden

Nummer 5 - In diesem Abschnitt sehen wir den Inhalt des SSL-Zertifikats, das der „Ziel-Mailserver“ bereitstellt.

Nummer 6 - in diesem Abschnitt können wir sehen, dass der TLS-Kommunikationskanal erfolgreich erstellt wurde.

Zusammenfassung und Zusammenfassung

Ich habe das Gefühl, dass wir gemeinsam eine lange Reise in die „IIS-SMTP-Welt“ unternommen haben.

Ich hoffe, dass diese Informationen Ihnen bei der Implementierung der SMTP-Relay-Lösungen in einer Office 365-Umgebung helfen werden.