Exchange 2010: Fehler 503 5.5.1 SMTP Bad sequence of commands (SMTP Error 503)

Heute trat ein interessantes Problem bei einem Kunden auf. Der Kunde beklagte sich das seit längerer Zeit keine Mails mehr versendet werden können. Tatsächlich blieben Mails in der ausgehenden Warteschlange hängen. Der Exchange 2010 Server sollte alle ausgehenden Mails an einen Relay Server schicken, den der Provider des Kunden betreibt. Soweit keine unübliche Konfiguration. Antwort des Relay Servers des E-Mail Providers war der SMTP Fehler 503 bad sequnce of commands (Falsche Befehlsreihenfolge). Es wurde also ein Unzustellbarkeitsbericht an den Client verschickt.

In solchen Fällen ist es immer ratsam sich den NDR genau anzuschauen um einen Ansatzpunkt zu bekommen was gerade schief läuft. Der wichtige Teil des NDRs war in diesem Fall folgender:

Diagnoseinformationen für Administratoren:

Generierender Server: EXSRV.frankysweb.local

frank@frankysweb.de

relay.provider.de #503 5.5.1 Error: Bad sequence ##

Hier gilt zu beachten, das nicht EXSRV.frankysweb.local der Server ist der dem Client mitteilt das SMTP Fehler 503 vorliegt, sondern der Server relay.provider.de. Soweit so gut, was sagt der Fehlercode 503 aber aus? Nach der Fehlercode Definition des SMTP Protokolls steht Fehler 503 für „Falsche Kommando Reihenfolge“. Dazu muss man wissen, wie die Zustellung einer Mail abläuft. Die Befehlsreihenfolge des SMTP Protokolls sieht dabei folgendes vor:

HELO Hostname

MAIL FROM: <absender email addresse>

RCPT TO: <empfänger email adresse>

DATA

QUIT

Diese Darstellung ist etwas vereinfacht, es gibt zum Beispiel noch die Möglichkeit anstelle von HELO, den Befehl EHLO zu senden und ein paar weitere Befehle die zum Beispiel der Authentifizierung dienen. Für Exchange Administratoren ist es also ratsam sich mit dem SMTP-Protokoll zu befassen.

Zurück zum Problem: Fehler 503 sagt aus, dass in der Befehlsreihenfolge des Servers, der die Mail schicken möchte, etwas nicht stimmt. Was genau gibt er leider nicht an. Um das heraus zu finden kann man Beispiel einen Sniffer installieren und den Traffic auf Port 25 protokollieren lassen. Ich bin in diesem Fall genauso vorgegangen um erst einmal herauszufinden welche Befehle in der falschen Reihenfolge, bzw. welcher Befehl nicht übermittelt wird. Hier ist ein Auszug aus dem Capure Log von Microsofts Network Monitor:

Ich habe das Log etwas gekürzt um die Lesbarkeit zu verbessern. Schauen wir uns also an was passiert:

Zeile 141: EHLO

Zeile 144: AUTH LOGIN

Zeile 151: Authentication successful (Antwort vom Relay Server)

Zeile 152: RCPT TO

Zeile 153: SMTP Fehler 503

In dieser Reihenfolge fällt auf das der Befehl MAIL FROM: in der Übermittlung fehlt. Die Befehle haben also in diesem Fall nicht die falsche Reihenfolge sondern ein Befehl fehlt komplett, da dieses Verhalten der Relay Server beim Provider nicht akzeptiert antwortet er mit Fehler 503.

Wir wissen also jetzt wo das Problem liegt und können darüber nachdenken was dieses Problem hervorrufen kann:

Habe ich bei der Anlage des Sende-Konnektors etwas falsch gemacht?

Habe ich die richtigen Zugangsdaten für den Relay Server des Providers eingetragen?

Habe ich den HELO Eintrag für den Sende-Konnektor korrekt eingestellt?

Habe ich den richtigen Hostnamen bzw. die IP für den Relay Server korrekt eingetragen?

Diese Fragen konnte ich in diesem Fall alle mit Ja! Beantworten. Trotzdem hilft es meistens den Weg im Kopf noch einmal nachzugehen. Bei der Konfiguration des Sende-Konnektors hat man keine Möglichkeit das SMTP-Protokoll zu beeinflussen. Warum sollte man auch!?

Die Ursache muss also woanders liegen:

Welche weitere Software ist auf dem Exchange Server installiert?

Wie verläuft die Verbindung des Exchange Servers mit dem Internet? Gibt es Proxys oder Application Layer Firewalls?

Gibt es eine zusätzliche Software die Exchange vor Viren oder SPAM schützt?

In meinem Fall konnte ich alle Fragen mit Nein! Beantworten, bis auf die Letzte: Gibt es eine zusätzliche Software die Exchange vor Viren oder SPAM schützt?

Es war ein Virenscanner auf dem Exchange Server installiert. In meinem Fall GData Antivirus. Der Kunde versicherte mir zwar die Kompatibilität sowie die korrekte Konfiguration des Virenscanners (Ausschlüsse Prozesse und Dateiendungen), trotzdem habe ich die prozesse den Virenscanners zum Testen deaktiviert.

Das Ende vom Lied: Nach dem Abschalten den Virenscanners funktionierte die Mail Zustellung auf Anhieb und auch der SMTP Befehl MAIL FROM: wurde wieder übermittelt. Ursache war hier also der Virenscanner. Der Kunde wird nun die Konfiguration noch einmal genau prüfen.

Warum schreibe ich einen langen Beitrag über ein kleines Virenscanner Problem? Ich hätte auch schreiben können: Wenn Fehler 503, dann Virenscanner abschalten.

Ich habe mir aber gedacht, dass ich lieber einen Lösungsweg für derartige Probleme aufzeige, anstatt einfach nur dazu rate irgendwelche Prozesse zu deaktivieren. Ähnliche Probleme sind mir auch schon mit Application Layer Firewalls untergekommen, die nicht direkt auf dem Exchange Server laufen. In so einem Fall hat es mir viel Ärger erspart da ich nachweisen konnte, dass die Übermittlung der Mail auf der Exchange Server Seite noch OK war, aber eine Firewall die den Traffic gefiltert hat, etwas zu eifrig war.