Exchange Server 2003 - Mailversand von Dateien groesser 4 MB via Smarthost bricht ab

  • Hier mal unsere Konfiguration :
    *W2K3 Enterprise Editon
    * Exchange Enterprise 2003 SP2, fully patched
    * IPCop 1.4.10 Internet Gateway (Linux-router)
    * Mailversand via Smarthost an einen Exim4 Mailserver (über DSL Line)
    * Übertragung zum Exim 4 wird über TLS/SLL mit SMTP AUTH gemacht.


    Ursprünglich wurde ein NT4.0/Exchange 5.5 eingesetzt. Dieser wurde letztes Jahr auf W2K3 migriert. Derzeit läuft die Domäne im W2K3 Server Modus.


    Ein Exim 4 Mailserver im Internet dient als Gatewayserver für ausgehende Mail. Er nimmt alle ausgehende Mail vom Exchange Server an und leitet diese weiter (halt ein "Smarthost" ;-)). Die ganze Konfiguration wurde vor ca 6 Monaten gemacht. Seitdem wurde auch nichts mehr verändert.
    Bisher lief alles problemlos. Aber seit einiger Zeit (genau kann ich es nicht sagen) gibt es immer mal wieder Probleme mit Mails die nicht korrekt upgeloaded werden. Ich habe mich dann mal auf die Suche begeben und festgestellt, dass es Probleme bei Mails mit Anhängen grösser 4 MB gibt. Alle Mails die kleiner sind gehen problemlos raus. Ist aber ein Anhang dran der grösser 4 MB (Nettogrösse) ist, dann wird diese zwar zum externen Mailserver weitergeleitet, aber nach einiger Zeit stellt der Exchange Server dann die Übertragung ein. Da die Datei dann nicht vollständig übertragen ist, versucht er es dann natürlich immer wieder (nach Ablauf der Wiederholungsintervalle) und blockiert uns damit die (leider nicht gerade grosszügig dimensionierte) Leitung. Da wir hier auch nur DSL 1000 haben, kann sich sicher jeder vorstellen das dann hier Schicht im Schacht ist.


    Ich habe also alle mir bekannten Parameter überprüft. Google habe ich auch schon ausgiebig bemüht, konnte aber auch da nichts brauchbares finden. In meiner Not habe ich dann einfach mal einen anderen Smarthost angegeben (Strato Mailserver). Dieser macht auch kein TLS und damit konnte ich das schon als Fehlerquelle ausschliessen. Hier bekam ich ein paar Byte mehr ohne Fehler durch die Leitung. Allerdings ging eine 10 MB Email auch nicht durch. Es scheint also auch kein TLS/SSL Problem zu sein. Aus irgendeinem Grunde stellt der Exchange das Senden ein.


    Zur Fehleranlayse habe ich dann gestern mal einige Tests mit verschiedenen Dateigrössen gemacht. Hier mal ein Auszug der Logs :


    ############## VERSENDEN EINER Mail von 4,025 MB ############################
    ############## DAS KLAPPT !! ############################
    Command - 0 EHLO - INTERNER.mailserver.de
    Response - 0 - - 250-extern.mailserver.de+Hello+*.dip.t-dialin.net+[externe IP-Adresse]


    Command - 0 STARTTLS -
    Response - 0 - - 220+TLS+go+ahead


    Command - 0 EHLO - INTERNER.mailserver.de
    Response - 0 - - 250-extern.mailserver.de+Hello+*.dip.t-dialin.net+[externe IP-Adresse]


    Command - 0 AUTH -
    Response - 0 - - 334+***********************************
    Response - 0 - - 235+Authentication+succeeded


    Command - 0 MAIL - FROM:bodo@intern.local+SIZE=4599774
    Response - 0 - - 250+OK


    Command - 0 RCPT - TO:bodo@extern.de
    Response - 0 - - 250+Accepted


    Command - 0 DATA -
    Response - 0 - - 354+Enter+message,+ending+with+"."+on+a+line+by+itself
    Response - 0 - - 250+OK+id=1F7Dqj-0007Bj-2K 0 0


    Command - 0 QUIT -
    Response - 0 - - 221+extern.mailserver.de+closing+connection
    Response - 0 - - 220+extern.mailserver.de+ESMTP+Exim+4.50+Thu,+09+Feb+2006+16:47:17++0100



    So, nun mal selbiges log beim Versenden einer Mail die etwas grösser ist :


    ############## VERSENDEN EINER Mail von 4,5 MB ############################
    ############## KLAPPT NICHT !!! ############################


    Command - 0 EHLO - INTERNER.mailserver.de - -
    Response - 0 - - 250-extern.mailserver.de+Hello+*.dip.t-dialin.net+[externe IP-Adresse]


    Command - 0 STARTTLS -
    Response - 0 - - 220+TLS+go+ahead


    Command - 0 EHLO - INTERNER.mailserver.de
    Response - 0 - - 250-extern.mailserver.de+Hello+*.dip.t-dialin.net+[externe IP-Adresse]


    Command - 0 AUTH -
    Response - 0 - - 334+******************************
    Response - 0 - - 235+Authentication+succeeded


    Command - 0 MAIL - FROM:bodo@intern.local+SIZE=5637810
    Response - 0 - - 250+OK


    Command - 0 RCPT - TO:bodo@extern.de
    Response - 0 - - 250+Accepted


    Command - 0 DATA -
    Response - 0 - - 354+Enter+message,+ending+with+"."+on+a+line+by+itself
    Response - 0 - - 220+extern.mailserver.de+ESMTP+Exim+4.50+Thu,+09+Feb+2006+16:53:51++0100



    Man sieht hier am Ende den entscheidenden Unterschied. Beim funktionierenden Versand kommt beim DATA Command ein OK zurück. Damit weiss der Exchange, dass die Datei korrekt übermittelt wurde. Beim fehlerhaften Versand komt nur ein 220 zurück. Das bedeutet "domain Service ready". Hier sendet der empfangende Server nur noch mal ein Ready Kommando da er keine Daten mehr empfängt.


    Ich habe mir das dann mal auf der Gegenseite angeschaut. Da wird folgendes mitprotokolliert :


    ########################################################################
    Log des Mailserver extern (mit TLS) bei Versenden von 4.5 MB:
    ########################################################################
    TLS recv error on connection from [************]: A TLS packet with unexpected length was received.
    SMTP connection from *********************** lost while reading message data
    TLS send error on connection from *******************: The specified session has been invalidated for some reason.


    Jetzt dachte ich, ich hätte das Problem gefunden. Allerdings ist die Fehlermeldung etwas irreführend, ich nehme mal an die Meldung "A TLS packet with unexpected length..." kommt daher, weil der Exim immer noch auf weitere Daten wartet und nicht weil bei der Verschlüsselung was schief läuft. Anders kann ich mir nicht erklären warum es auch ohne TLS nicht funktioniert.


    Hier mal ein Beispielversand über einen Strato Relay Server (OHNE TLS/SSL!!) :


    ########################################################################
    Log Versand via Mailserver Strato (kein TLS):
    ########################################################################
    Response - 25 - - 220+212.227.***.***+(mrelay***)+Welcome+to+Nemesis+ESMTP+server
    Command - 25 EHLO - interner.mailserver.de
    Response - 25 - - 250-mrelay***.kundenserver.de+pleased+to+meet+you
    Response - 25 - - 250-STARTTLS
    Command - 25 AUTH -
    Response - 25 - - 334+***************************************
    Response - 25 - - 235+authentication+finished+successfully
    Command - 25 MAIL - FROM:<bodo@intern.local>+SIZE=6543069
    Response - 25 - - 250+mail+from:+<bodo@intern.local>+ok
    Command - 25 RCPT - TO:<bodo@extern.de>
    Response - 25 - - 250+<bodo@extern.de>+ok
    Command - 25 DATA -
    Response - 25 - - 354+Enter+mail,+end+with+"."+on+a+line+by+itself


    Hier passiert genau das gleiche. Die SMTP Sitzung bricht während des Datenverkehres einfach zusammen. Es kommt kein QUIT und damit meint der Exchange die Datei ist nicht zugestellt und schickt sie immer wieder zum Relayserver.


    Ich bin auch nicht gerade unbedarft was Mailserver und Konfiguration angeht, allerdings muss ich zugestehen nicht der Exchange Experte zu sein. Ich tendiere da eher Richtung Linux ;).
    Nun bin ich ehrlich gesagt mit meinem Latein am Ende. Ich habe schon alle mir bekannten Parameter überprüft. Einer unserer Kunden hat auch einen Exchange 2003 SP2 im Einsatz. Dort habe ich dann ähnliche Tests gefahren und genau dassselbe Problem festgestellt. Allerdings tritt der Fehler erst bei Dateien ~ 20 Mb auf. Jedoch hat unser Kunde auch einen besseren Upload (DSL 6000). Es scheint also eher ein zeitliches Problem und nicht ein Problem der Dateigrösse zu sein.
    So langsam fällt mir auch nicht mehr ein. Ich habe gestern nacht auch nochmal die Datenbank defragmentiert und überprüft. Die Ereignisanzeige gitb auch nichts her. Da scheint alles im Lot zu sein.


    Hat einer on den Exchange Experten vielleicht noch eine Idee ? Bin für alles offen :D


    Vielen Dank!


    gruss
    bodo


    P.S.: Die IP Adressen und Namen hab ich mal abgeändert. Denke es sollte auch so lesbar sein ...

    • Offizieller Beitrag

    Hi Bodo,


    na, das nenn ich doch mal eine ausführliche Beschreibung!


    Nun zum Problem:
    Bei einer DSL1000 hat du ja nur 256Kbit Upload, variiert nach
    Provider. Da kann das natürlich zu Timing-Problemen kommen.
    Ausserdem wird die Verbindung alle 24h gekappt. Ist der Fehler
    zufällig immer im gleichen Zeitfenster?


    Das mit dem Exim kann ich mir erstmal so auch nicht erklären,
    bei Strato hatte ich auch immer Probleme bei Mails >=10MB.
    Bei den Kunden habe ich dann die Max. Mailgrösse im Exchange
    passend eingestellt.


    Geht der DSL nicht schneller? Ist doch heute eigentlich keine
    grosse Kostenfrage mehr...


    Naja, schauen wir mal...
    :-x

    • Offizieller Beitrag

    Hallo,


    ich gehe jetzt einfach mal rhetorisch an die Sache.


    Habe ihr ein Message Limit Size Limit (im ESM unter Globale Einstellungen > Nachrichtenübermittlung > Eigenschaften > Standard)


    oder Sending Restrictions, oder einen Virenscanner der Probleme macht?


    Schalte doch bitte mal das Nachrichtentracking auf dem Exchange Server ein.


    Desweitere stelle mal das Logging auf max +


    in der Registry


    HKLM\System\CCS\Services\msexchangetransport\Diagnostics


    Im Rechten Fenster dann alle Werte auf 7 stellen und das ganze nochmals reproduzieren.

  • Nobby: Ich habe hier 8 ISDN Anschlüsse in der Firma, aber auf keinem einzigen geht mehr als DSL1000. Ärgerlich ist, dass ich zur UNI gegenüber spucken kann. Dort liegen genug fette Leitungen, aber an die kommen wir leider nicht dranne. Da unser Gebiet auch (bis auf die UNI) kein Wohngebiet ist, kriegen wir hier wohl nicht mehr.
    Upload ist 128 Kbit. Ich kann aber über dieselbe Leitung problemlos 30 MB Mails mit einem Email-Client über denselben Server senden. Von daher schliesse ich Leitungsprobleme eigentlich aus.


    Aber da mit Strato ist schon mal ein guter Hinweis. Ich teste das gleich mal mit meinem Email-Client. Dann wäre die Ursache ja eventuell doch im TLS/SSL zu suchen. Werde ich mal verifizieren.


    Jürgen:
    Tracking ist schon an, aber ich habe nun mal das Logging auf max gestellt. Mal sehen was ich dort finde. Dauert aber noch mit den Tests, muss erstmal einiges anderes noch durchtesten (das ist das Nervige: Jeder Test blockiert mir erstmal für 20 min die Leitung).
    Restrictions habe ich schon alles überprüft, sind keine eingestellt. Ich habe testweise auch mal welche eingetragen (um auszuschliessen das irgendein default-wert probs macht) aber das brachte auch nichts.
    Virenscanner ist auf der Maschine derzeit deaktiviert.


    Wenn ich weitere Logs habe melde ich mich wieder. Erstmal schon vielen Dank für eure Tipps.

    • Offizieller Beitrag

    Hallo,


    letzer Post vor dem Wochenende...


    Zum DSl schau mal bei QSC nach, die haben die besten Tarife,
    zumindest bei uns in der Region (bei Business-Kunden)
    http://www.qsc.de/de/qsc-data/q-dslmax/index.html


    Aber das nur am Rande.


    Dem Fehler kommt man schon drauf!


    Bis dahin,
    schönes Wochenede!
    :D

  • So,
    nach einigen Tests bin ich nun auf die Lösung des Problemes gestossen ;) Das Wochenende ist somit gerettet :D


    Nachdem Nobby ja sagte er hätte bei Strato auch schon Probleme mit Mails >10MB gehabt, habe ich mich nochmal genauer mit der TLS/SSL Problematik befasst. Ich hatte gestern schon gelesen, dass wohl die gnuTLS Implementation einen Bug hat. Daher soll man den Exim möglichst mit OPENSSL kompilieren. Unser Mailserver ist allerdings ein Debian Standardpaket und mit gnuTLS kompiliert.


    Und genau da klemmt es. Es scheint als hätte Exchange damit ein Problem. Andere SSL-fähigen Email-Clients (ich habe hier mal ein "The Bat 3.5" getestet) funktionieren mit der fehlerhaften SSL Version. Ich konnte z.B. mit TheBat problemlos 30 MB über den Server schaufeln. Hier scheint der Hersteller wohl einen Workaround implementiert zu haben.
    Lange Rede kurzer Sinn: Ich habe im Exchange Connector und im Linux-Mailserver die Verwendung von TLS deaktiviert und schon konnte ich wunderbar Dateien versenden. Hätte ich schon gestern gewusst das Strato solche Probleme mit grossen Mails macht, dann hätte ich mir 10 Stunden Fehlersuche sparen können ;).


    Für die Suchmaschine wenn jemand ähnliche Probleme hat:


    Fehler im Maillog Exim 4:
    2006-02-10 13:03:48 1 TLS recv error on connection from *****.dip.t-dialin.net (exchange-server.*****.de) [80.131.***.***]: 2006-02-10 13:03:48 TLS recv error on connection from *****.dip.t-dialin.net (exchange-server.*****.de) [80.131.***.***]: A TLS packet with unexpected length was received.
    2006-02-10 13:03:48 SMTP connection from *****.dip.t-dialin.net (exchange-server.*****.de) [80.131.231.33] lost while reading message data
    2006-02-10 13:03:48 TLS send error on connection from *****.dip.t-dialin.net (exchange-server.*****.de) [80.131.***.***]: The specified session has been invalidated for some reason..
    2006-02-10 13:03:48 SMTP connection from *****.dip.t-dialin.net (exchange-server.*****.de) [80.131.***.**] lost while reading message data
    2006-02-10 13:03:48 TLS send error on connection from *****.dip.t-dialin.net (exchange-server.*****.de) [80.131.***.***]: The specified session has been invalidated for some reason.


    Im Exchange-Log wird dann folgendes mitgeloggt:


    #Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes time-taken cs-version cs-host cs(User-Agent) cs(Cookie) cs(Referer)


    2006-2-10 13:01:21 GMT - - - EXCHANGE - bodoATextern.de 1027 827FA1A42DDATEXCHANGE.intern.local 0 0 4791347 1 2006-2-10 13:01:21 GMT 0 - c=DE;a= ;p=FIRMA;l=EXCHANGE- Test 5 MB File EX:********************


    2006-2-10 13:01:22 GMT - - - EXCHANGE - bodoATextern.de 1019 84827FA1A42DDATEXCHANGE.intern.local 0 0 4791347 1 2006-2-10 13:01:21 GMT 0 - - Test 5 MB File - -


    2006-2-10 13:01:22 GMT - - - EXCHANGE - bodoATextern.de 1025 84827FA1A42DDATEXCHANGE.intern.local 0 0 4791347 1 2006-2-10 13:01:21 GMT 0 - - Test 5 MB File - -


    2006-2-10 13:01:22 GMT - - - EXCHANGE - bodoATextern.de 1024 84827FA1A42DDATEXCHANGE.intern.local 0 0 4791347 1 2006-2-10 13:01:21 GMT 0 - - Test 5 MB File - -


    2006-2-10 13:01:22 GMT - - - EXCHANGE - bodoATextern.de 1033 84827FA1A42DDATEXCHANGE.intern.local 0 0 4791347 1 2006-2-10 13:01:21 GMT 0 - - Test 5 MB File -


    2006-2-10 13:01:22 GMT - - - EXCHANGE - bodoATextern.de 1034 827FA1A42DDATEXCHANGE.intern.local 0 0 4791347 1 2006-2-10 13:01:21 GMT 0 - - Test 5 MB File -


    2006-2-10 13:01:25 GMT - - - EXCHANGE - bodoATextern.de 1020 84827FA1A42DDATEXCHANGE.intern.local 0 0 4791347 1 2006-2-10 13:01:21 GMT 0 - - Test 5 MB File -


    Danke nochmal an nobby&jürgen für eure Tipps. Sie haben mich auf die richtige Spur gebracht. Ich werde in den nächsten Tage mal den Exim neu kompilieren und dann OpenSSL einsetzen. Dann sollte es hoffentlich funktionieren.


    Für alle die ein ähnliches Problem haben:


    http://lists.debian.org/debian…man/2004/09/msg03174.html