Wie man Test-E-Mails über SMTP mit Telnet sendet und Authentifizierungsprobleme behebt
Das Testen von SMTP-Servern mit Telnet ist nicht immer so einfach, wie es klingt. Grundsätzlich ist es eine schnelle Methode, um zu prüfen, ob der Server Verbindungen akzeptiert und Befehle funktionieren. Schwieriger wird es jedoch, wenn Authentifizierung erforderlich ist – insbesondere bei modernen Servern, die auf anonyme Relays oder die Übertragung im Klartext verzichten. Ziel ist es, eine Verbindung herzustellen, sich zu authentifizieren und eine Test-E-Mail zu senden, um zu überprüfen, ob die Konfiguration funktioniert oder ob Probleme mit den Anmeldeinformationen, der Verschlüsselung oder den Servereinstellungen vorliegen. Dies spart enorm viel Zeit im Vergleich zum Versenden dutzender Test-E-Mails über einen Client und ist äußerst hilfreich bei der Fehlersuche in Verbindungsproblemen oder der Optimierung von Serverkonfigurationen. Ein kleiner Hinweis: Die Verwendung von Telnet zur SMTP-Authentifizierung ist veraltet und unsicher (da die Anmeldeinformationen Base64-kodiert und nicht verschlüsselt sind).Bei einer Konfiguration funktionierte es, bei einer anderen nicht. Verwenden Sie Telnet daher mit Vorsicht und nur in sicheren Umgebungen oder für schnelle Tests. Für anspruchsvollere Aufgaben sind sicherere Tools wie OpenSSL für TLS oder dedizierte SMTP-Clients besser geeignet. Dennoch ist es ein guter Ausgangspunkt für die Fehlersuche.
Wie man die SMTP-Authentifizierung mit Telnet behebt
Testen der SMTP-Authentifizierung mit Telnet
Dieser Abschnitt ist hilfreich, wenn Ihr SMTP-Server für die Basisauthentifizierung konfiguriert ist. Dabei werden Benutzername und Passwort Base64-kodiert gesendet. Viele lokale Exchange-Server haben dies standardmäßig aktiviert, Cloud-Dienste oder besonders sichere Umgebungen können dies jedoch blockieren oder SSL/TLS voraussetzen. Sobald die Telnet-Verbindung erfolgreich hergestellt ist (Sie sollten eine 220-Meldung vom Server erhalten), können Sie sich anmelden: Geben Sie im Klartext EHLO IhreDomain.de ein. Der Server antwortet mit einer Liste der unterstützten Funktionen – suchen Sie nach „AUTH LOGIN“.Wenn Sie diesen Eintrag finden, unterstützt Ihr Server die Anmeldung mit Base64-kodierten Anmeldeinformationen. Jetzt wird es ernst: Sie müssen Ihren E-Mail-Benutzernamen und Ihr Passwort in Base64 konvertieren. Warum das funktioniert, ist nicht ganz klar, aber auf manchen Systemen erzielen die integrierten PowerShell- oder Perl-Encoder die besten Ergebnisse. Verwenden Sie beispielsweise diesen PowerShell-Befehl, um Ihren Benutzernamen zu kodieren: `powershell [System. Convert]::ToBase64String([System. Text. Encoding]::UTF8. GetBytes(„[email protected]“))`.Analog dazu verwenden Sie für Ihr Passwort: `powershell [System. Convert]::ToBase64String([System. Text. Encoding]::UTF8. GetBytes(„yourPassword“))`.Alternativ können Sie auch einfach nach „Base64 kodieren“ googeln, um einen Online-Konverter zu finden. Sobald Sie diese Zeichenketten haben, starten Sie die Authentifizierung wie folgt: Klartext AUTH LOGIN. Der Server antwortet: Klartext 334 VXNlcm5hbWU6. Fügen Sie anschließend den Base64-kodierten Benutzernamen ein. Der Server fragt dann nach dem Passwort: Klartext JHVwM1JzVHIpbmc=.Sind die Anmeldedaten korrekt, antwortet der Server mit: Klartext 235 2.7.0 Authentifizierung erfolgreich. Andernfalls erhalten Sie eine Fehlermeldung wie: Klartext 535 5.7.8 Fehler: Authentifizierung fehlgeschlagen. Es ist etwas seltsam, aber manchmal kann ein kleiner Tippfehler bei der Kodierung oder das Vergessen der Reihenfolge Probleme verursachen. Beachten Sie außerdem, dass manche Server die Anmeldung ablehnen, wenn die Verbindung nicht über eine TLS-Sitzung hergestellt wird.
Verwendung von OpenSSL für eine TLS-gesicherte SMTP-Verbindung
Die meisten modernen SMTP-Server *erfordern* heutzutage Verschlüsselung – einfaches Telnet reicht nicht aus. Wenn die Authentifizierung fehlschlägt, weil der Server TLS verlangt, sollten Sie auf OpenSSL umsteigen. Laden Sie OpenSSL herunter und installieren Sie es (für Windows ist [dieser Link](http://slproweb.com/products/Win32OpenSSL.html) empfehlenswert; Linux-Nutzer finden es in ihren Paketmanagern).Stellen Sie eine sichere Verbindung her mit: `bash openssl s_client -starttls smtp -connect smtp.yourprovider.com:587`.Nach erfolgreicher Verbindung erhalten Sie die EHLO-Antwort mit den unterstützten Funktionen. Authentifizieren Sie sich erneut mit: `plaintext EHLO yourdomain.com`.Achten Sie auf die Antwort „AUTH LOGIN“ oder „AUTH PLAIN“.Gehen Sie dann wie bei Telnet vor: Geben Sie „AUTH LOGIN“ ein und senden Sie Ihren Base64-kodierten Benutzernamen und Ihr Passwort. Diese Methode ist sicherer und entspricht dem Verhalten Ihres Clients bei verschlüsselten SMTP-Sitzungen.
SMTP-Authentifizierung mit Office 365 oder Microsoft 365
Hier wird es noch frustrierender: Microsoft hat die grundlegende SMTP-Authentifizierung für neue Mandanten bereits 2020 deaktiviert. Das bedeutet, dass die direkte Verbindung und Authentifizierung mit dem Office 365-Server über Telnet oder OpenSSL nicht mehr unterstützt wird. Wenn Sie versuchen, die SMTP-Verbindung zu Office 365 mit Telnet zu testen, werden Sie wahrscheinlich scheitern, da dies nur mit der Microsoft-API oder Microsoft-Clients möglich ist. Für Office 365 empfiehlt Microsoft stattdessen die Verwendung des PowerShell-Cmdlets `Send-MailMessage` mit einem App-Passwort oder OAuth-Tokens. Hier ein kurzer Codeausschnitt: `powershell $cred = Get-Credential Send-MailMessage -To [email protected] -From [email protected] -Subject „Test“ -Body „This is a test“ -SmtpServer smtp.office365.com -Port 587 -UseSsl -Credential $cred`.Damit dies funktioniert, muss die SMTP-Authentifizierung in den Sicherheitseinstellungen Ihres Tenants aktiviert sein (was aufgrund der Standardeinstellungen möglicherweise deaktiviert ist).Beachten Sie, dass Microsofts Umstellung von der Basisauthentifizierung dazu führt, dass herkömmliche Telnet-Tests in Office 365 größtenteils überflüssig geworden sind.
Behebung von Verbindungs- oder Authentifizierungsfehlern
– Überprüfen Sie, ob Ihr Server „AUTH LOGIN“ oder „AUTH PLAIN“ unterstützt. Achten Sie dabei auf die entsprechende Information in Ihrer EHLO-Antwort.- Stellen Sie sicher, dass Ihre Anmeldeinformationen korrekt kodiert sind – keine Tippfehler, keine überflüssigen Leerzeichen.- Vergewissern Sie sich, dass Sie gegebenenfalls eine TLS-Verbindung herstellen, insbesondere bei modernen Servern.- Wenn Sie dies in einer sicheren Umgebung tun, sollten Sie *OpenSSL* verwenden, um Ihren Datenverkehr zu verschlüsseln.- Verwenden Sie für Office 365 anstelle von Telnet zugelassene Tools oder PowerShell-Skripte, da die meisten Klartext-Übertragungsmethoden deaktiviert sind.
Alles in allem ist Telnet heutzutage etwas ungenau, aber es ist erstaunlich, wie viele Probleme sich mit einer einfachen Verbindung und wenigen Befehlen diagnostizieren lassen. Beachten Sie jedoch die Serverbeschränkungen und Sicherheitsrichtlinien – führen Sie diese Tests nicht in ungeschützten Netzwerken oder in Netzwerken mit sensiblen Daten durch, wenn Sie die Verbindung verschlüsseln.
Zusammenfassung
- Verwenden Sie Telnet oder OpenSSL, um eine Verbindung herzustellen und SMTP-Sitzungen zu simulieren.
- Konvertieren Sie die Anmeldeinformationen vor dem Senden in Base64.
- Überprüfen Sie stets die vom Server unterstützten Authentifizierungsmethoden mit EHLO.
- Beachten Sie, dass moderne Anbieter wie Office 365 direkte Telnet-Verbindungen blockieren können.
- Für sichere Tests sollten Sie OpenSSL- und PowerShell-Skripte anstelle von direktem Telnet verwenden.
Zusammenfassung
Diese Art von Test mag angesichts der modernen Sicherheitsvorkehrungen altmodisch wirken, ist aber nach wie vor eine praktische Methode zur Fehlerbehebung, falls Ihr SMTP-Relay Probleme bereitet. Bedenken Sie jedoch, dass Ihre Zugangsdaten auf diese Weise nicht wirklich sicher sind. Bei wichtigen Anwendungen empfiehlt sich daher die Verwendung sichererer Methoden. Hoffentlich bringt dies etwas Klarheit und Ihre Verbindung funktioniert wieder einwandfrei – oder weist Ihnen zumindest den Weg zur Lösung des Problems.