Exchange Server 2007 und Anlagen

Immer wieder mittwochs…..


Dienstag Abend wurde ich mit einem merkwürdigen Problem konfrontiert: Ein Exchange Server 2007 Edge lehnte scheinbar willkürlich Mails mit unterschiedlichen Anlagen ab – unabhängig von deren Größe. Der Absender bekam stets eine Verzögerungsbenachrichtigung und dann letztendlich eine Unzustellbarkeitsbenachrichtigung. Prima, sowas liebe ich. Keine Regelmäßigkeit, nichts. Der Edge-Server ist an einen 10MBit/s-Glasfaseranschluß angeschlossen und alle MessageSize Limits sind auf 100MB gesetzt.


Also, dutzende Tests machen, um doch eine Regelmäßigkeit zu finden. Mit einem nützlichen SMTP-Test-Tool zuerstmal von intern Mails mit großen Anlagen (50MB) an den Edge gesendet. Ergebnis: problemlos. Dann selbe Mail von extern über einen DSL-Anschluß. Mail wurde abgelehnt mit der Fehlermeldung “10053 Software caused connection abort.” Das Agentlog am Edge schreibt folgendes dazu:


12444 2007-12-04T19:38:49.544Z,08CA04C0B8E6AD63,10.201.1.70:25,82.207.207.134:1261,82.207.207.134,34034708l.43709031l1240852l1l@test.tld,dieter@test.tld,dieter@test.tld;,postmaster@test.tld,1,Content Filter Agent,OnEndOfData,AcceptMessage,,SCL,not available: filter unable to process message. Failure at function ID SmartScreenEvaluate : System.Runtime.InteropServices.COMException (0x800710F0): The message provided exceeds the maximum size allowed for this parameter. (Exception from HRESULT: 0x800)


Sehr aufschlußreich, wie ich finde ;-)


Das SMTPReceive Log enthält (hier am Beispiel eines späteren Versuchs) folgende Einträge:


+ 25173 2007-12-04T22:00:12.480Z,edge\ReceiveConnector,08CA04D820129110,0,10.201.1.70:25,82.207.207.134:49375,+,,
+ 25174 2007-12-04T22:00:12.480Z,edge\ReceiveConnector,08CA04D820129110,1,10.201.1.70:25,82.207.207.134:49375,*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
+ 25175 2007-12-04T22:00:12.480Z,edge\ReceiveConnector,08CA04D820129110,2,10.201.1.70:25,82.207.207.134:49375,>,”220 mail.test.tld Microsoft ESMTP MAIL Service ready at Tue, 4 Dec 2007 23:00:11 +0100″,
+ 25176 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,3,10.201.1.70:25,82.207.207.134:49375,<,EHLO VISTANB02,
+ 25177 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,4,10.201.1.70:25,82.207.207.134:49375,>,250-mail.test.tld Hello [82.207.207.134],
+ 25178 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,5,10.201.1.70:25,82.207.207.134:49375,>,250-SIZE 104857600,
+ 25179 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,6,10.201.1.70:25,82.207.207.134:49375,>,250-PIPELINING,
+ 25180 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,7,10.201.1.70:25,82.207.207.134:49375,>,250-DSN,
+ 25181 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,8,10.201.1.70:25,82.207.207.134:49375,>,250-ENHANCEDSTATUSCODES,
+ 25182 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,9,10.201.1.70:25,82.207.207.134:49375,>,250-AUTH,
+ 25183 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,10,10.201.1.70:25,82.207.207.134:49375,>,250-8BITMIME,
+ 25184 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,11,10.201.1.70:25,82.207.207.134:49375,>,250-BINARYMIME,
+ 25185 2007-12-04T22:00:12.556Z,edge\ReceiveConnector,08CA04D820129110,12,10.201.1.70:25,82.207.207.134:49375,>,250 CHUNKING,
+ 25186 2007-12-04T22:00:12.753Z,edge\ReceiveConnector,08CA04D820129110,13,10.201.1.70:25,82.207.207.134:49375,<,RSET,
+ 25193 2007-12-04T22:00:17.606Z,edge\ReceiveConnector,08CA04D820129110,14,10.201.1.70:25,82.207.207.134:49375,>,250 2.0.0 Resetting,
+ 25194 2007-12-04T22:00:17.651Z,edge\ReceiveConnector,08CA04D820129110,15,10.201.1.70:25,82.207.207.134:49375,<,MAIL FROM: <dieter@test.tld>,
+ 25195 2007-12-04T22:00:17.651Z,edge\ReceiveConnector,08CA04D820129110,16,10.201.1.70:25,82.207.207.134:49375,*,08CA04D820129110;2007-12-04T22:00:12.480Z;1,receiving message
+ 25196 2007-12-04T22:00:17.651Z,edge\ReceiveConnector,08CA04D820129110,17,10.201.1.70:25,82.207.207.134:49375,>,250 2.1.0 Sender OK,
+ 25197 2007-12-04T22:00:17.697Z,edge\ReceiveConnector,08CA04D820129110,18,10.201.1.70:25,82.207.207.134:49375,<,RCPT TO:<postmaster@test.tld>,
+ 25198 2007-12-04T22:00:18.332Z,edge\ReceiveConnector,08CA04D820129110,19,10.201.1.70:25,82.207.207.134:49375,>,250 2.1.5 Recipient OK,
+ 25199 2007-12-04T22:00:18.422Z,edge\ReceiveConnector,08CA04D820129110,20,10.201.1.70:25,82.207.207.134:49375,<,DATA,
+ 25200 2007-12-04T22:00:18.422Z,edge\ReceiveConnector,08CA04D820129110,21,10.201.1.70:25,82.207.207.134:49375,>,354 Start mail input; end with <CRLF>.<CRLF>,
+ 26145 2007-12-04T22:05:13.890Z,edge\ReceiveConnector,08CA04D820129110,22,10.201.1.70:25,82.207.207.134:49375,>,421 4.4.1 Connection timed out,
+ 26146 2007-12-04T22:05:13.890Z,edge\ReceiveConnector,08CA04D820129110,23,10.201.1.70:25,82.207.207.134:49375,-,,Local


Dann das Notebook zwischen Internet Router und ISA Server gehängt und selbe Testmail verschickt – problemlos. Damit wollte ich überprüfen, dass der ISA Server ordnungsgemäß arbeitet.


Mit Christians Hilfe haben wir dann Testmails von einem weiteren Internetzugang mit 4MBit/s verschickt. Auch abgelehnt.


Nach mehrfachen Tests und Auswerten der Logfiles kamen wir darauf, dass immer genau nach 5 Minuten folgender Eintrag auftaucht: 4.1.1 Connection timed out. Auch ein Netzwerkmonitor-Trace bestätigt dies, obwohl der Sender nicht fertig ist mit dem Übertragen der E-Mail.


Das brachte Christian dann auf die beiden Parameter ConnectionTimeout und ConnectionInactivityTimeout, die man an einem ReceiveConnector konfigurieren kann – Danke Christian, das nächste Bier geht auf mich!


-ConnectionTimeout:
This parameter specifies the maximum time that a connection can remain open, even if the connection is actively transmitting data. The default value for a Receive connector that is configured on a Hub Transport server is 10 minutes The default value for a Receive connector that is configured on an Edge Transport server is 5 minutes. To specify a value, enter the value as a time span: dd.hh:mm:ss, where d = days, h = hours, m = minutes, and s = seconds. The value specified by the ConnectionTimeout parameter must be greater than the value specified by the ConnectionInactivityTimeout parameter. The valid input range for either parameter is 00:00:01 to 1.00:00:00.


-ConnectionInactivityTimeout:
This parameter specifies the maximum amount of idle time before a connection to a Receive connector is closed. The default value for a Receive connector that is configured on a Hub Transport server is 5 minutes. The default value for a Receive connector that is configured on an Edge Transport server is 1 minute. To specify a value, enter the value as a time span: dd.hh:mm:ss, where d = days, h = hours, m = minutes, and s = seconds. The value specified by the ConnectionTimeout parameter must be greater than the value specified by the ConnectionInactivityTimeout parameter. The valid input range for either parameter is 00:00:01 to 1.00:00:00.


Aha! Die Verbindung wird also IMMER nach 5 Minuten getrennt, even if the connection is actively transmitting data. Also unabhängig davon, ob noch Daten übertragen werden. Geile Sache. Da dachte wohl jemand, alle Welt wäre mit 10 Gigabit/s-Internetzugängen ausgestattet….


Also den ConnectionTimeout auf 30 Minuten gesetzt und erneut getestet – siehe da, die Mails konnten zugestellt werden und das Problem ist damit gelöst. Jetzt darf die Übertragung einer Mail maximal 30 Minuten betragen – was auch für größere Mails nun ausreichen sollte.


Aus Sicherheitsgründen sollte jedoch das ConnectionInactivityTimeout auf einem niedrigen Wert bleiben, da sonst zu leicht Verbindungen mutwillig offengehalten werden können.


Viele Grüße
Dieter



Dieter Rauscher
MVP ISA Server