Behebung des Problems mit dem verzögerten ausgehenden E-Mail-Versand durch Zimbra: „Zeitüberschreitung der Verbindung an Port 25“

Wenn Zimbra dies meldet connect to mx.example.net[203.0.113.25]:25: Connection timed out, hat die Nachricht normalerweise die Zimbra-Mailwarteschlange erreicht, aber der Server konnte keine TCP-Verbindung zum Mailserver der Empfängerdomäne herstellen. Überprüfen Sie zunächst die Warteschlange, den DNS-Server und den ausgehenden Netzwerkpfad. Ändern Sie die Postfix-Timeouts nicht und leeren Sie die Warteschlange nicht wiederholt, bis Sie den blockierenden Serverknoten identifiziert haben.

Ein Timeout ist etwas anderes als eine SMTP-Ablehnung. Eine Ablehnung wie „550“ bedeutet, dass ein Remote-Server geantwortet und die Nachricht abgelehnt hat; „Verbindungstimeout“ bedeutet, dass der Verbindungsversuch keine rechtzeitige Antwort erhalten hat. Die Ursache kann eine lokale Firewall, die Richtlinie für ausgehende E-Mails eines Cloud- oder Hosting-Anbieters, das Routing, ein nicht erreichbares Ziel oder seltener ein DNS-/Adressfamilienproblem sein.

Was bedeutet „Verbindungstimeout an Port 25“ in Zimbra?

Zimbra verwendet seinen Mailserver (MTA) zum Weiterleiten ausgehender Nachrichten. Befindet sich der Empfänger außerhalb Ihrer Organisation, ermittelt der MTA den Mailserver der entsprechenden Domain und stellt über SMTP eine Verbindung her. Im aktuellen Daffodil-Administratorhandbuch von Zimbra wird beschrieben, dass nicht zustellbare Nachrichten in die Warteschlange für verzögerte Zustellung gelangen, wo die Zustellung erneut versucht wird. Der Eintrag in der Warteschlange und das E-Mail-Protokoll geben Auskunft über das Ziel und den Fehler und sind daher die beste erste Informationsquelle.

Im typischen E-Mail-Verkehr kommunizieren öffentliche Mailserver über TCP-Port 25. Port 587 wird üblicherweise von authentifizierten Mailclients verwendet, um Nachrichten an einen ausgehenden Relay-Server zu senden. Die Umstellung des Relay-Pfads von Zimbra auf Port 587 ist nur dann möglich, wenn ein autorisierter Relay-Dienst für diesen Zweck konfiguriert ist; sie stellt keinen allgemeinen Ersatz für den Empfang von Internet-E-Mails über Port 25 dar.

1. Betrifft das Problem alle Empfänger oder nur eine Domain?

Prüfen Sie die Warteschlange für verzögerte Anfragen, bevor Sie Änderungen vornehmen. Führen Sie auf dem Zimbra MTA-Host administrative Befehle als folgendes zimbraKonto aus:

su - zimbra
postqueue -p

Achten Sie auf wiederholte Timeout-Meldungen und notieren Sie sich die Empfängerdomäne, den Ziel-MX-Hostnamen und die aufgelöste IP-Adresse. Öffnen Sie in der Zimbra-Administrationskonsole „ Überwachung“ → „E-Mail-Warteschlangen“ und prüfen Sie die Warteschlange „Verzögert“ nach Fehlertyp und Empfängerdomäne. Die genaue Menübezeichnung kann je nach Zimbra-Version und -Edition variieren.

Wenn Fehler gehäuft bei einer Empfängerdomäne oder einer MX-Adresse auftreten, ist das Ziel möglicherweise vorübergehend nicht erreichbar oder filtert Verbindungen von Ihrem Server. Falls viele unabhängige Domänen mit demselben Port-25-Timeout fehlschlagen, überprüfen Sie zunächst den ausgehenden Pfad des Zimbra-Hosts, die Provider-Richtlinien oder die Firewall. Notieren Sie sich Zeitstempel und einige repräsentative Ziele; veröffentlichen Sie keine Nachrichtentexte oder Zugangsdaten, wenn Sie Hilfe benötigen.

2. Löst DNS die Empfängerdomäne zu erreichbaren Mailservern auf?

Fragen Sie die MX-Einträge der Empfängerdomäne auf dem Zimbra-Server ab. Ersetzen Sie „Domäne“ example.netdurch die Domäne, bei der der Fehler auftritt:

dig MX example.net +short

Verwenden Sie den zurückgegebenen MX-Hostnamen, um dessen Adressen nachzuschlagen:

dig A mx.example.net +short
dig AAAA mx.example.net +short

Eine Domain kann mehrere MX-Einträge haben. Überprüfen Sie die tatsächlichen Hostnamen, die vom DNS angezeigt werden, anstatt anzunehmen, dass der Webserver des Empfängers E-Mails annimmt. Falls der DNS keinen verwendbaren MX-Eintrag liefert, überprüfen Sie die autoritative DNS-Konfiguration der Empfängerdomain. Fügen Sie auf Ihrem Zimbra-Server keinen fiktiven MX-Eintrag hinzu.

Als Nächstes testen Sie eine TCP-Verbindung. Falls ncinstalliert, verwenden Sie:

nc -vz -w 10 mx.example.net 25

Oder verwenden Sie telnet mx.example.net 25diese Option, falls verfügbar. Eine erfolgreiche TCP-Verbindung erzeugt eine Erfolgsmeldung; ein SMTP-Server zeigt anschließend möglicherweise eine Begrüßung an. Ein Timeout bedeutet, dass der TCP-Handshake nicht abgeschlossen wurde. Anders verhält es sich mit der Meldung „Verbindung abgelehnt“: Der Remote-Host hat zwar geantwortet, die Verbindung an dieser Adresse und diesem Port aber nicht akzeptiert.

Wiederholen Sie den Test für jedes MX-Ziel und testen Sie nach Möglichkeit sowohl IPv4- als auch IPv6-Pfade. Wenn der Hostname zu einer IPv6-Adresse aufgelöst wird, der Server aber keine funktionierende IPv6-Route besitzt, kann ein IPv6-Zugriffsversuch fehlschlagen, während IPv4 funktioniert. Überprüfen Sie die Route und die Protokolle, bevor Sie die Einstellungen der Postfix-Adressfamilie ändern; jede Änderung dieser Art sollte versions- und deploymentspezifisch sein.

3. Blockiert eine Firewall oder ein Hosting-Anbieter ausgehende SMTP-Verbindungen?

Überprüfen Sie zunächst die Firewall-Richtlinie des Servers, ohne sie zu ändern. Auf Systemen mit UFW:

sudo ufw status verbose

UFW kann sowohl ausgehenden als auch eingehenden Datenverkehr verwalten. Ist die Richtlinie für ausgehenden Datenverkehr restriktiv, prüfen Sie die nummerierten Regeln und vergewissern Sie sich, ob TCP-Verbindungen zu Port 25 blockiert sind. Fügen Sie eine eng gefasste Regel zum Zulassen ausgehenden Datenverkehrs nur dann hinzu, wenn diese Ihrer Sicherheitsrichtlinie entspricht und der Server berechtigt ist, E-Mails direkt zu versenden.

Eine Host-Firewall kann die Verbindung zulassen, während eine vorgelagerte Firewall, die Cloud-Sicherheitskontrolle, eine Netzwerk-ACL oder eine Richtlinie des Hosting-Anbieters sie blockiert. Fragen Sie Ihren Anbieter, ob ausgehender TCP/25-Verkehr für diese Instanz zulässig ist, ob eine kontobezogene Einschränkung gilt und ob ein Freigabe- oder Überprüfungsprozess verfügbar ist. Die Richtlinien unterscheiden sich je nach Anbieter, Konto, Region und Produkt. Daher beweist eine erfolgreiche lokale Firewall-Prüfung nicht, dass der Internetpfad offen ist.

Wenn Sie eine Netzwerk-Firewall verwalten, überprüfen Sie deren Ausgangsregeln und Protokolle auf die Quell-IP-Adresse des Zimbra-Servers, die Ziel-MX-IP-Adresse, das Protokoll TCP und den Zielport 25. Eine Paketerfassung kann einem erfahrenen Administrator helfen, unbeantwortete SYN-Pakete von Antworten zu unterscheiden, die auf dem Rückweg blockiert werden. Erfassen Sie dabei nur die relevanten Header und schützen Sie alle Betriebsdaten. Öffnen Sie Port 25 nicht als Lösung für ausgehende Timeouts; es handelt sich um separate Datenverkehrsrichtungen.

4. Was sollten Sie tun, wenn eine direkte Anlieferung über Hafen 25 nicht möglich ist?

Wenn Ihr Provider keine direkten ausgehenden SMTP-Verbindungen zulässt, verwenden Sie einen autorisierten Smarthost oder ein ausgehendes Relay. Erfragen Sie Hostname, Port, TLS-Anforderungen, Authentifizierungsmethode, zulässige Absenderdomänen und etwaige Anforderungen an die IP-Zulassungsliste vom Relay-Betreiber. Konfigurieren Sie das Relay über die für Ihre Version unterstützte Zimbra-Administrationsmethode oder folgen Sie dem Änderungsprozess Ihrer Organisation. Im Zimbra-Administratorhandbuch wird darauf hingewiesen, dass ein Relay-Host konfiguriert werden muss, wenn die DNS-basierte Zustellung deaktiviert ist.

Viele Provider bieten authentifizierte Übermittlung über Port 587 mit STARTTLS an, die Dokumentation des Relay-Anbieters ist jedoch maßgebend. Ein Relay kann stattdessen Port 465, eine IP-Whitelist oder einen providerspezifischen Connector benötigen. Gehen Sie nicht davon aus, dass Port 587 offen ist oder dass jeder öffentliche SMTP-Server als Relay verwendet werden kann. Bewahren Sie Ihre Zugangsdaten in der unterstützten geschützten Konfiguration auf, beschränken Sie den Zugriff darauf und geben Sie niemals ein Relay-Passwort in einem Support-Ticket oder im Shell-Verlauf an.

Nach der Konfiguration des Relays senden Sie eine Testnachricht an ein von Ihnen verwaltetes Postfach. Überprüfen Sie im Zimbra-Mail-Protokoll, ob die Verbindung zum Relay-Host und dem erwarteten Port hergestellt wird, die TLS-Authentifizierung (falls erforderlich) erfolgreich ist und das Relay die Nachricht annimmt. Falls ein SMTP-Fehler auftritt, untersuchen Sie diesen als Problem mit der Authentifizierung, der Absenderrichtlinie, TLS oder den Relay-Berechtigungen und nicht als Timeout auf Port 25.

Wann sollten Sie die verzögerte Warteschlange erneut bearbeiten?

Sobald die Ursache behoben ist und ein direkter Test zum Ziel oder Relay erfolgreich war, fordern Sie eine erneute Zustellung in der Warteschlange an. postqueue -fFordern Sie vom Zimbra-Konto aus Postfix auf, die Zustellung der in der Warteschlange befindlichen Nachrichten zu versuchen.

su - zimbra
postqueue -f

Dies kann Zustellversuche für zahlreiche Nachrichten auslösen. Vermeiden Sie daher wiederholte Ausführungen während eines Ausfalls. Nutzen Sie alternativ die Warteschlangensteuerung der Administrationskonsole, sofern verfügbar. Zimbra dokumentiert, dass das Leeren der Warteschlangen Zustellversuche für Nachrichten in den Warteschlangen „Verzögert“, „Eingehend“ und „Aktiv“ auslöst. Überprüfen Sie anschließend einige Nachrichten und vergewissern Sie sich, dass die Anzahl der verzögerten Nachrichten sinkt und die Protokolle eine erfolgreiche Zustellung oder eine neue, verwertbare SMTP-Antwort anzeigen.

Kurzleitfaden zur Entscheidungsfindung

Wie können Sie die Fehlerbehebung bestätigen?

Führen Sie eine kurze Verifizierungssequenz durch: Prüfen Sie, ob der DNS-Server den gewünschten MX-Server oder Relay-Server zurückgibt; prüfen Sie, ob eine TCP-Verbindung zum konfigurierten Host und Port erfolgreich hergestellt wurde; senden Sie eine Testnachricht; prüfen Sie, ob der Remote-Server oder Relay-Server diese akzeptiert hat; und überprüfen Sie anschließend die Warteschlange für verzögerte Nachrichten und die Protokolle auf die ursprünglichen Nachrichten. Ein erfolgreicher Verbindungstest allein beweist nicht, dass der Empfänger die Nachricht akzeptiert hat, und eine erfolgreiche Relay-Übergabe garantiert keine Zustellung in den Posteingang.

Beheben Sie einen Timeout nicht, indem Sie das Verbindungs-Timeout von Postfix erhöhen. Diese smtp_connect_timeoutEinstellung steuert, wie lange der SMTP-Client auf den Aufbau einer TCP-Verbindung wartet. Eine Verlängerung kann eine blockierte Route nicht wiederherstellen und die Zustellungsversuche sogar verlängern. Vermeiden Sie außerdem das Löschen von Nachrichten in der Warteschlange oder das Ändern der Warteschlangenlebensdauer, um das Problem zu verschleiern. Wenn Nachrichten sich der konfigurierten Bounce-Lebensdauer nähern, informieren Sie die betroffenen Benutzer über die verzögerte Zustellung und sichern Sie die Warteschlangeninformationen, während Sie die Route wiederherstellen.

Offizielle Referenzen

• Zimbra Daffodil (v10) Administratorhandbuch: E-Mail-Fluss und Warteschlangen
• Zimbra Daffodil (v10) Installationsanleitung für Einzelserver: Portzuordnung
• Postfix postconf(5): smtp_connect_timeout
• Ubuntu Server-Dokumentation: Firewalls und UFW-Status