Verzögerte / Gestör...
 
Notifications
Clear all

Verzögerte / Gestörte Mailzustellung

3 Posts
2 Users
0 Reactions
4,764 Views
(@olistu)
New Member
Joined: 4 years ago
Posts: 4
Topic starter  

Hallo zusammen,

 

derzeit bin ich bei einem Kunden dabei einen Exchange Server zu ersetzen, der nicht mehr richtig läuft. Dazu habe ich einfach einen zweiten Exchange installiert, eine DAG aufgebaut und mittels Failover die Datenbanken auf dem neuen Exchange aktiviert. Im Anschluss haben wir die IP getauscht, damit weiterhin alle Firewall-Regeln gelten, und ggf. Third-Party Applikationen ihr Ziel finden. Die DAG haben wir auch schon wieder entfernt.

 

Hier haben wir jetzt allerdings die Krux: E-Mails werden von einem externen SMTP-Relay (der die Mails entgegen nimmt und auf SPAM, etc. prüft) an die öffentliche IP des Kunden weitergeleitet. Hier greift dann ein SNAT auf den Exchange Server. Wenn wir den E-Mail Verkehr nun auf den neuen Exchange leiten, dann kommen Mails sehr verzögert ein und hängen teilweise 10 Minuten in der Warteschlange beim externen SMTP-Relay. Stellen wir das SNAT wieder auf den alten Exchange um, dann geht alles sofort durch. Tauschen wir die IPs wieder zurück, dann ist es identisch. Es hat also mit dem Exchange zu tun und nicht mit der IP die angesprochen wird.

Ich denke es wird nur irgendeine Kleinigkeit sein, ggf. irgendein Registry-Key oder eine Einstellung an den Empfangsconnectoren, die mir nicht auffällt.

Vielleicht hat ja irgendjemand eine Idee oder schonmal selber erlebt, dass ein  Exchange Mails nicht richtig entgegen zu nehmen scheint. Bei Bedarf kann ich gerne Konfiguration posten.

 

Vielen Dank schon mal vorab für etwaige Vorschläge  :) 

Liebe Grüße

Oliver


   
Quote
(@geloeschter-benutzer)
Reputable Member
Joined: 2 years ago
Posts: 263
 

hi,

 

wieso greift SNAT auf dem Exchange Server? So wie du es beschreibst, kommen eingehende Mails verzögert an... dann greift doch auf der Firewall DNAT, da du ja ein Empfangs und kein Sendeproblem hast.

Du hast ja außerdem geschrieben, dass du nach Entfernen der DAG und des alten Servers die alte IP dem neuen Server zugewiesen hast. Wenn du also keinen speziellen Empfangsconnector auf dem alten Exchange hattest, der nur von bestimmten (externen?) Hosts annimmt, sollte sich nichts geändert haben. Du kannst ja auf dem neuen Exchange den Default Frontent Connector auf ausführliche Protokollierung stellen und schaust dir mit bspw Baretail das entsprechend aktuelle Log quasi live an. Dann siehst du ja, ob und wie der ExchangeServer die Mails von dem vorgeschalteten Relay annimmt. Kann es sein, dass du noch irgendwo vorher Greylisting machst und die Mails erstmal temporär abgelehnt werden? Hast du den alten Server sauber entfernt oder hängt der noch irgendwo in der Org Konfig drin und der neue versucht diesen permanent zu erreichen? (prüfen mit ADSIEdit). Auch beim Sendeconnector (orgwide) musst du dann prüfen, ob nur der neue Server fürs versenden nach extern drin steht.

 

Gruß,
Ralf


   
ReplyQuote

(@olistu)
New Member
Joined: 4 years ago
Posts: 4
Topic starter  

Hi Ralf,

 

entschuldige, wenn ich mich unklar ausgedrückt habe. Es ist nur der E-Mail-Empfang betroffen gewesen. Also die Weiterleitung von SMTP von der Public IP  an den Exchange (nennt sich an der WatchGuard Firewall Static NAT).

 

Danke für die Tipps! Ich habe das Problem beheben können. Beim Vergleich der Receive Logs vom Default Frontend Connector der beiden Server ist mir aufgefallen, dass der alte Exchange im Authentifizierungsprozess jeweils ein Zertifikat übermittelt, der neue aber nicht. Beim erneuten Aktivieren des Wildcard-Zertifikats via Enable-ExchangeCertificate, kam die Warnung, dass ein anderes Zertifikat den Vorrang übernimmt. Das war das automatisch erstellte Computer-Zertifikat der internen CA.

Nachdem ich das Zertifikat manuell entfernt und das Wildcard-Zertifikat aktiviert habe, gehen die Mails auch ohne Verzögerung direkt ein!

 

Liebe Grüße

Oliver


   
ReplyQuote
Share: