Hallo zusammen,
ich hoffe hier im Forum vielleicht der Lösung meines Problems etwas näher zu kommen. Bevor ich hier vielleicht den ganzen Text vom Technet-Forum poste einmal der Link zu meinem Thema.
Allgemein nochmal:
Auf unseren Exchange Servern 2016 (DAG) kommt es mehrmals am Tag dazu, das die E-Mails in der Warteschlange Richtung Mailproxy (der KEMP dazwischen wurde als Fehlerquelle bereits ausgeschlossen) mit dem Status "451 4.7.1 Service unavailable - try again later" festhängen und erst langsam abgearbeitet werden (15 - 30min). Es sind nicht viele E-Mails und in der Zwischenzeit des Staus gehen aber andere (auch meine Testmails bspw.) fehlerfrei durch.
Kurzfristig habe ich auch mal den Fehler "451 4.4.397 Error communication with target host. -> 421 4.2.1 Unable to connect -> SocketConnectionRefused: Socket error code 10061" gesehen aber der war dann schnell wieder weg.
Wir haben schon den KEMP Loadmaster ausgeschlossen weil das Verhalten auch auftritt wenn die Exchange Server direkt an die Mailproxy Systeme ihre Mails senden. Auf den Exchange läuft dazu noch ein SMEX (TrendMicro ScanMail for Exchange) aber laut TrendMicro sollten ausgehende Nachrichten nicht aufgehalten werden (nur eingehende Prüfung). Unser Netzwerkdienstleister hat auch schon das Logging aktiviert und sieht nur das teilweise die Verbindungen zum Mailproxy resetet werden aber welches System das auslöst konnte er noch nicht feststellen.
Alles in allem ist es sehr beunruhigend wenn nicht wirklich erkennbar ist wo die Ursache liegt da es auch mit einmal (letzten Mittwoch gegen 14 Uhr) angefangen hat und das auf allen Exchange Servern. Des weiterem wird jeder Exchange Admin nervös wenn sich an die 100 Mails auf einmal in den Warteschlangen aufstauen ?
Unsere Exchange Server und die Mailproxy Systeme (DMZ) sind alles VM's und ich kann keine Ressourcenengpässe feststellen woran ich auch schon gedacht habe.
Vielleicht kann mir einer von Euch noch einen Tip geben.
Ps.: Wenn ich am Sendeconnector die Protokollierung aktiviere wo liegen dann die richtigen Logs denn ich konnte in den bekannten Pfaden nichts in den Logs finden.
MfG Paul
MfG Paul
Hi...
also das ist jetzt komisch.
Die gleichen Meldungen bekomme ich, wenn ich auf unserem vorgelagerten Trendmicro IMSVA Gateway den "SmartScan" aktiviere, aber nur dann...
Habt ihr auch ein AntiSpam/AntiVIrus Gateway vor dem Kemp im Einsatz ?
Wenn ich den Conventinellen Scan aktiviere ist die Meldung weg...
Rossi
Hallo Rossi,
unser Ablauf sieht wie folgt aus.
Anwender -> Exchange 2016 -> KEMP Loadbalancer (vService SMTP – Port25) -> Mailproxy -> Extern
Auf den Exchange Servern ist der SMEX installiert aber aber die Mailproxy Systeme sind von Clearswift. Dazwischen ist nur der Loadbalancer und de konnten wir ausschließen aber weiter nichts. Klar haben wir in unserem Netzwerk noch eine Firewall zwischen dem RZ und DMZ Netz.
MfG Paul
Auf den Exchange Servern ist der SMEX installiert aber aber die Mailproxy Systeme sind von Clearswift. Dazwischen ist nur der Loadbalancer und de konnten wir ausschließen aber weiter nichts. Klar haben wir in unserem Netzwerk noch eine Firewall zwischen dem RZ und DMZ Netz.
Also die Meldung (NDR) kommt auf den internen Exchangeservern? Dann muss es wohl noch intern bei euch zwischen Exchange und Clearswift haken. Was steht denn zum selben Zeitpunkt bei Clearswift im Logfile? Dazwischen steht dann noch eine Firewall? Falls ja, fasst die SMTP an? Cisco wär da so ein klassischer Kandidat mit ihrem SMTP Fixup bzw. SMTP Security.
Hallo Norbert,
ja die Meldung kommt auf den Exchange Servern direkt und unser Serververantwortlicher für die Mailproxysysteme hatte bei der ersten Kontrolle keine Auffälligkeiten entdeckt. Ich habe unserem Netzwerkdienstleister den Hinweis weitergegeben und hoffentlich werden wir bald fündig.
MfG Paul
MfG Paul
Connection refused ist ja ein "aktiver" Vorgang des Empfängers. Also wie gesagt, entweder fummelt da wer am Protokoll rum, oder euer Exchange erreicht irgendwelche Grenzwerte, die Clearswift dann aktiv zurückweist.
An den Mailproxy Systemen wurden nun die Verbindungsgrenzen höher gesetzt (von 25 auf 250) aber es werden weiterhin Mails temporär nicht zum Mailproxy zugestellt.
MfG Paul
Ich kenne die Clearswifts nicht, aber ich würde auf der Seite anfangen zu suchen. Ausnahme, wenn dazwischen die Firewall rumwerkelt. ;)
Unser Netzwerker hat mittels einem Netzwerkcapture festgestellt, das es immer wieder zu einem Reset vom Kemp kommt. Die Motivation dazu kann Er leider nicht erklären. Das kommt relativ häufig vor aber wie gesagt den KEMP hatten wir ja bereits ausgeschlossen.
MfG Paul
Wie ist denn eure Kemp Konfiguration? 1-Arm oder 2-Arm?
wir haben eine 2-Arm Konfiguration und bei SMTP den Transparent Modus was bisher auch immer klappte und wie gesagt der Fehler trat auch auf wenn die Exchange Server direkt ihre Mails an die Mailproxy Systeme gesendet haben
RZ-Netz <-> KEMP <-> Exchange Netz
Gestern wurde noch etwas vom Clearswift Support gemacht und auch an den VM`s (Mailproxy) die CPU und der RAM erhöht. Bis jetzt konnte ich noch keine weiteren E-Mails feststellen die festhingen aber der Tag ist noch lang.
MfG Paul
Gestern wurde noch etwas vom Clearswift Support gemacht
Wenns dann geht, frag mal, was "gemacht" wurde. ;)
So der Fehler ist wieder aufgetaucht ?
Werde jetzt zum Test nochmal die Exchange Server ihre Mails direkt an einem Mailproxy direkt weiterleiten lassen und nochmal den KEMP rausnehmen.
MfG Paul
Wenn ich am Sendeconnector die Protokollierung aktiviere wo werden dann die Logs abgelegt und kann man da vielleicht etwas erkennen?
MfG Paul
Habe jetzt den richtige Log Pfad gefunden denn es werden weiterhin Mails in der Warteschlange gestaut.
\\ExSvr\c$\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend
2020-11-19T12:02:34.707Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,2,172.31.xx.xxx:6835,192.168.242.1:25,+,,
2020-11-19T12:02:34.709Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,3,172.31.xx.xxx:6835,192.168.242.1:25,<,220 SMTP ESMTP Relay,
2020-11-19T12:02:34.709Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,4,172.31.xx.xxx:6835,192.168.242.1:25,>,EHLO EX04.firma.local,
2020-11-19T12:02:34.710Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,5,172.31.xx.xxx:6835,192.168.242.1:25,<,250 mail.firma.de PIPELINING SIZE ETRN STARTTLS ENHANCEDSTATUSCODES 8BITMIME DSN CHUNKING,
2020-11-19T12:02:34.710Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,6,172.31.xx.xxx:6835,192.168.242.1:25,>,STARTTLS,
2020-11-19T12:02:34.710Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,7,172.31.xx.xxx:6835,192.168.242.1:25,<,454 4.3.0 Try again later,
2020-11-19T12:02:34.711Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,8,172.31.xx.xxx:6835,192.168.242.1:25,*,,sending message with RecordId 50006304228629 and InternetMessageId <541a2ff27a4e441eab40ed96ee1cdf0e@firma.de>
2020-11-19T12:02:34.711Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,9,172.31.xx.xxx:6835,192.168.242.1:25,>,MAIL FROM:<InternUser@firma.de> SIZE=3203428,
2020-11-19T12:02:34.711Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,10,172.31.xx.xxx:6835,192.168.242.1:25,>,"RCPT TO:<ExternUser@gmail.com> NOTIFY=SUCCESS,FAILURE,DELAY",
2020-11-19T12:02:34.712Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,11,172.31.xx.xxx:6835,192.168.242.1:25,<,451 4.7.1 Service unavailable - try again later,
2020-11-19T12:02:34.713Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,12,172.31.xx.xxx:6835,192.168.242.1:25,<,503 5.5.1 Error: need MAIL command,
2020-11-19T12:02:34.713Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,13,172.31.xx.xxx:6835,192.168.242.1:25,>,QUIT,
2020-11-19T12:02:34.714Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,14,172.31.xx.xxx:6835,192.168.242.1:25,<,221 2.0.0 Bye,
2020-11-19T12:02:34.715Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,15,172.31.xx.xxx:6835,192.168.242.1:25,-,,Local
2020-11-19T12:02:38.705Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA2,0,,192.168.242.1:25,*,SendRoutingHeaders,Set Session Permissions
MfG Paul
<,503 5.5.1 Error: need MAIL command,
Und ihr seid euch sicher, dass da die Firewall nicht rumpopelt?
Hallo zusammen,
wir haben den vermeintlichen Fehler bzw. die Ursache lokalisieren können.
Es handelt sich wohl bei uns um ein Bug am Mailproxy (Clearswift) der zu Stande kommt, weil wir unsere Mailproxy Systeme per Implace Upgrade von 4.2 auf 5 hochgezogen haben. Das ist wohl nicht ganz sauber oder vollständig vonstattengegangen oder seitens Clearswift etwas unsauber gewesen.
Wir haben ein System komplett mit der aktuellen Version (5) neu aufgesetzt und die Konfiguration übertragen und auch STARTTLS aktiviert.
Bisher gab es keine Vorfälle mehr und daher stelle ich das Thema auf Gelöst.
Vielen Dank an alle Kommentatoren für eure Ansätze/Tipps und wünsche ein erholsames Wochenende.
MfG Paul
MfG Paul
Danke für die Rückmeldung.
