Fehler gibt’s, die sollte es nicht geben und man muss erstmal darauf kommen. Folgendes Ausgangs-Szenario:

Ein Exchange Server stellt seine E-Mails per SmartHost an eine Securepoint UTM an deren Mailrelay zu.

So weit nichts ungewöhnliches. Eigentlich. Zuvor erfolgte die Zustellung immer direkt per SMTP und DNS und das soweit ohne Probleme. Nun sollte aber etwas mehr Sicherheit her und eben das Mailrelay zusätzlich verwendet werden.

Ein Test mittels SMTPsend, mit dessen Hilfe eine E-Mail direkt an die Securepoint UTM zugestellt wurde förderte folgende Fehlermeldung zutage:

#503 5.0.0 Need MAIL before RCPT ##

Da aber der Kommunikationsverlauf im Log des Tools normal erschien, war zunächst unklar was da los ist. Die erste Vermutung ging Richtung Securepoint nicht zuletzt aus dem Grund, da es dort die letzte Zeit recht viele Updates gab. Diese sind zwar, zumindest bei uns, in der Regel stressfrei, aber irgendwann ist ja immer das erste Mal.

Der Support brachte dann etwas mehr Licht ins Dunkel. Ein Mitschnitt der Kommunikation auf der UTM lieferte den Hinweis, das direkt nach dem EHLO bereits versucht wird, die E-Mail zuzustellen, ohne zunächst mitzuteilen, wer man ist, MAIL FROM wird verschluckt und wohin es gehen soll, RCPT TO wird ebenfalls verschluckt. Damit war klar, das irgendetwas in die Kommunikation eingreift.

Für gewöhnlich sind das nunmal Virenscanner. In diesem Fall von G Data. Bislang hatten wir damit auch keine Probleme, aber wie bereits erwähnt, irgendwann ist immer…

Der Verdacht viel zunächst auf die offentsichtlichen Mail-Komponenten wie “Ausgehende Mails – Mails vor dem Senden prüfen”, dem war aber nicht so. Letztlich ist die Port-überwachung für Port 25 der Übeltäter gewesen:

• G Data Administrator öffnen.
• Zu G Data – (Gruppe -) Client klicken.
• Zur Registerkarte “E-Mail” wechseln.
• Im Abschnitt “Port-Überwachung”  auf die Schaltfläche “Ändern…” klicken.
• Den Haken bei “Ausgehende Mails (SMTP) verarbeiten” entfernen und auf die Schaltfläche “OK” klicken.
• Abschließend auf die Schaltfläche “Übernehmen” klicken.

Es dauert einen Moment bis die Änderung greift, danach funktioniert der E-Mail-Fluss wie gewünscht. Dies entspricht, zumindest für die Einzelplatz-Versionen von G Data, auch der empfohlenen Vorgehensweise. In diesem Fall handelt es sich aber um ein Firmennetzwerk.

Seltsamerweise gab es beim Test mittels telnet keine Probleme, so ist das Problem womöglich Timing-abhängig.

Persönliche Bemerkung

Was ich (noch) nicht verstehe ist der Fakt, das die direkte Zustellung per SMTP zu anderen Mailservern ohne Probleme funktionierte. Ich bin mir auch nicht sicher, ob G Data wirklich der Böse in diesem Fall ist, was im Umkehrschluss nicht bedeuten soll, das Securepoint den schwarzen Peter zugeschoben bekommt. Möglicherweise liegt die Sache irgendwo dazwischen.

Update 18.10.2013

Von Herr Meuer, Produktmanager bei EBERTLANG bekam ich folgende Info, die wiederum von G Data stammt, zu diesem Thema:

“Das beschriebene Problem kann bedingt durch die G Data Port-Überwachung auf Mailservern auftreten – es kann zu Timing-Problemen kommen. Deswegen ist die prinzipielle G Data Empfehlung auch auf Mailservern die Portüberwachung komplett zu deaktivieren. Dies geschieht jetzt schon automatisch, falls bereits die G Data MailSecurity installiert ist. Für weitere Mailserver ist eine vorherige Abfrage während der Clientinstallation geplant.”

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.