Exchange 2013 - SMTP Test per Telnet wird nicht abgesendet

[jensw_2000 10]

Moin,

 

 

ich habe beim Exchange Server eines Kunden das Problem, dass einige SMTP Clients beim Senden von Emails 'hängen' und die Mails nie versendet werden. Bei einigen Kopierern klappt es tadellos, andere versenden keine Mails. Auch die eingesetzte Backup Software kann keine Statusmails über diesen Exchange SMTP versenden und hängt 5 Minuten beim Versenden einer Testmail.

 

Um den Fehler einzugrenzen habe ich versucht, eine Testmail über Telnet zu versenden.

Der Protokollablauf vom HELO bis zum DATA klappt problemlos.

Nach dem DATA kommt wie erwartet die Antwort:

"354 Start mail input; end with <CRLF>.<CRLF>"

Jedoch wird das RETURN . RETURN nicht angenommen. Normalerweise kommt danach "OK. Message queued for delivery".

Bei diesem Server kann ich RETURN . RETURN eingeben bis ich grün werde. Es werden lediglich Punkte in den Messagetext eingefügt (mit Zeilenumbruch). RETURN . RETURN führt aber nicht zum Versenden der Mail.

 

Ich denke, dass die hängenden SMTP Clients ihre Mails auf die gleiche Art versenden und ebenfalls vor dem Problem stehen, dass nach dem RETURN . RETURN nicht das erwartete Statuscode "200 OK. Message queued for delivery" zurückkommt. 

 

Was hat dieser Exchange Server für ein Problem? So einen Effekt hatte ich bisher noch nie. Der Fehler ist direkt auf dem Exchange Server mit deaktiviertem Antivirus reproduzierbar. Es hängt dann nichts mehr dazwischen. Bei den Exchange 2013 Servern anderen Kunden funktioniert das tadellos. Da kann ich dieses Problem nicht reproduzieren. 

 

Gruß

Jens

 

 

[NorbertFe 2.035]

Läuft da ne AV Software drauf?

[jensw_2000 10]

Ja, der Trend Micro Worry Free Business Security Client. Der Problem tritt aber auch auf, wenn ich temporär alle Funktionen des AV Clients deaktiviere. 

Trend Micro WFBS haben wir auch bei vielen anderen Kunden im Einsatz. Dort kann ich Mails per Telnet versenden und es gibt keine vergleichbaren Probleme.

 

 

Läuft da ne AV Software drauf?

[NorbertFe 2.035]

Eventlog? Wieviel Platz ist auf c: noch frei von wieviel?

[jensw_2000 10]

21 von 80 GB sind auf C: frei.

Im Eventlog wird nichts geloggt, wenn ich die Mail per Telnet tippe und return.return tippe.

Im SMTP log steht das komplette Protokoll vom HELO bis zum DATA. Das "Message queued for delivery" wird auch nicht geloggt. Stattdessen kommt irgendwann ein Timeout oder Cancel, je nachdem ob ich auf den Abbruch warte oder das Telnet Fenster hart beende.

Hoops! Sorry. Falscher Server ;)

Auf C: sind 196 von 280 GB frei

 

Um das mal konkret zu zeigen hängt noch ein Screenshot dran.

 

 

 

bearbeitet 19. April 2016 von jensw_2000

[jensw_2000 10]

Ich würde da gerne nochmal nachfragen ....  ;)

 

Hat vielleicht jemand noch eine Idee, warum das <Return>.<Return> nicht angenommen wird? 

Ist das vielleicht ein Spracheinstellungsproblem auf dem Server? Vielleicht erwartet der einen anderen Zeilenumbruch als CRLF...

[testperson 1.680]

Hi,

 

es ist auch keine AV Software auf dem PC von dem du testest? Nicht das da noch irgendeine "Portüberwachung" für Mails mitläuft.

Verbindest du dich direkt mit dem Exchange oder steht da noch eine Firewall- / Routinginstanz zwischen, die evtl. noch im Traffic rumschnuppert?

 

Welche Prozesse hören denn Port 25 ab: netstat -ano | findstr ":25" und dann im Taskmanager nach der PID suchen.

 

Der Exchange ist auf aktuellem CU12?

 

Gruß

Jan

[jensw_2000 10]

Hi,

 

nein, da hängt ganz sicher keine AV Software oder etwas Vergleichbares zwischen.

Ich kann das Problem direkt in der CMD auf dem Exchange mit aktiviertem und deaktiviertem AV Client nachstellen. Sogar über die Localhost IP.

 

Port 25 hört nur die "MSExchangeFrontendTransport.exe" ab. 

 

KB3108023 ist noch nicht installiert.

Das kann ich übers Wochenende nachholen. Der Exchange läuft noch mit CU11.

 

 

 

 

[Nobbyaushb 1.471]

Antwortet wirklich der Exchange oder was anderes?

 

Der Teil fehlt im Screenshot.

 

;)

[Sunny61 806]

nein, da hängt ganz sicher keine AV Software oder etwas Vergleichbares zwischen.

Ich kann das Problem direkt in der CMD auf dem Exchange mit aktiviertem und deaktiviertem AV Client nachstellen. Sogar über die Localhost IP.

Hmm, keine AV-Software aber du probierst es mit deaktiviertem AV-Client? Das hört sich für mich nicht ganz stimmig an.

[jensw_2000 10]

Moin Norbert, ja, da antwortet wirklich der Exchange, s. Attachment.

 

Sunny, danke dass Du dich mit einbringst. Aber sorry ... zählen wir eventuell ein bisschen Erbsen?  :schreck:  :D

Also : 

Problem 1:1 reproduzierbar mit:

> deaktiviertem AV Client

> deinstalliertem AV Client

> Telnet via Localhost IP

> neu installiertem AV Client

> wieder aktiviertem AV Client

> neben dem AV Client gibt es keine andere Security Software auf dem Host

 

CU12 habe ich gestern installiert.

Das ändert leider auch nichts am Fehlerbild.

 

 

 

 

 

 

 

[Nobbyaushb 1.471]

Moin,

 

ist der auf Blech oder VM?

 

;)

[jensw_2000 10]

Der läuft klassisch auf Blech. 

[Nobbyaushb 1.471]

Tja, dann gehen mir so langsam die Ideen aus.

 

Wenn Hardware-defekte ebenso wie Switche usw. ausgeschlossen werden können, müsste man mal an die Büchse.

 

Wie viele Netzwerkkarten hat der, wie sind die Bindungen?

 

Was läuft außer dem Exchange noch drauf?

 

;)

[jensw_2000 10]

Greifbare Ideen habe ich auch schon länger nicht mehr. Von meinem Bauchgefühl her hat das Problem nichts mit AV, Security oder Netzwerk zu tun. 

Telnet nimmt soweit ja alle SMTP Kommandos an. Nur das <return>.<return> löst bei dieser Exchange Installation eben nicht das Versenden der Message aus. Der Punkt erscheint in der Telnet Commandline. Vielleicht doch eher ein Zeichensatzproblem. Das CRLF ist ja auf "deutsch" ASCII-13 + ASCII-10. Eventuell erwartet dieser Exchange aus irgendwelchen Gründen aber einen weichen Zeilenumbruch (nur ASCII-10) oder einen "Linux Zeilenumbruch" (nur ASCII-13) zum Absenden der Message (<return>.<return>). 

 

Der Server (Fujitsu Primergy RX300 S7) hängt über 2 geteamte Broadcom Karten im LAN (Teaming über das Windows Server 2012 R2 NIC Teaming).

Der Kartentreiber bzw. das NIC Team wird beim Zugriff über 127.0.0.1 aber auch nicht verwendet, wenn ich das von meinen MCSE / MCNE Kursen damals noch richtig in Erinnerung habe. Falls meine grauen Zellen noch ein bisschen funktionieren läuft Loopback nur über OSI Layer 2-LLC. "Netzwerkkarte und -treiber" auf OSI Layer 2-MAC gibt's dort glaube ich nicht. Der MAC Layer wird in diesem Fall im TCP Stack emuliert.

 

Außer dem Exchange Server läuft 'nichts weiter auf der Maschine'. Nur das Nötigste. Windows Server 2012 R2, Backup Agent, AV Client, Exchange 2013 mit CU12, Fujitsu Serverview Agent und Serverview RAID. 

bearbeitet 17. Mai 2016 von jensw_2000