Am Freitag gab es wieder einen Klassiker im Support, der nicht ganz so oft vorkommt, dafür jedoch Nerven kostet und Zeit raubt. Und da ich zum wiederholten Male mir den Weg mangels Dokumentation mühsam suchen musste, dokumentiere ich mal hier.
Problem: Ein Mitarbeiter sendet einen Newsletter an eine ganze Reihe von Empfängern und hängt fatalerweise einen größeren Anhang an. Dass sich das alles fatal addiert, machen wir mal an einer kleinen Beispielrechnung auf. Gegeben seien 300 Empfänger, an die ein 9 Megabyte großer Anhang versendet wird. Mit gängiger Kodierung vergrößert sich im Versand zuerst einmal ein zu versendender Anhang um rund ein Drittel, so dass wir schon mal bei 12 Megabyte Datenmenge pro Mail sind. Das dann mal 300 und wir sind netto bei etwa 3,6 Gigabyte. Damit ist eine mittlere Anbindung schon mal gut beschäftigt, wenn der hauseigene Mailserver loslegt.
Der Begriff “netto” hat aber eine entscheidende Fußfalle: Viele empfangende Mailserver bocken bei größeren Anhängen oder deklarieren eine Nachricht gleich als Spam. Mit dem Ergebnis, dass man in der Gewichtsklasse damit rechnen kann, dass etwa nur zwei Drittel dieser Brummer sofort durchgehen und der absendende Mailserver mit dem letzten Drittel noch richtig schön lange zu tun hat und ständige Neuversuche unternimmt.
Das kann man als Sysadmin aussitzen, sollte man aber nicht, denn wenn bei einer Anbindung der Upstream ins Internet für Stunden lahmgelegt wird, zeichnen sich dank TCP auch beim Downstream unweigerlich Probleme. Sprich: Man muss den Exchange bremsen und die Warteschlange mit den ausgehenden Mails löschen.
In der fast schon vorzeitlichen Exchange-Welt gab es für solche Ernstfälle einen verglasten Notschalter: Exchange-Dienste beenden und in einem Exchange-Verzeichnis, in dem die Warteschlange in Form von einzelnen Mails und Dateien lag, den Inhalt leeren. Exchange-Dienste wieder hoch und Ruhe war.
Mit neueren Exchange-Versionen funktioniert das so nicht mehr, da auch die Mailqueues aus Gründen der Performance als Datenbank vorliegen. Man muss also im laufenden Betrieb die Warteschlange leeren. Und das wird spätestens dann zu einem Problem, wenn man remote auf den Exchange muss, eben aber dank der Versendungsaktion keine Bandbreite mehr vorhanden ist.
Lösung: Den SMTP-Dienst auf dem Exchange-Server nicht beenden, sondern bei einer vor dem Exchange-Server liegenden Firewall oder einem Router den Standart-TCP-Port 25 temporär ein- und ausgehend blockieren.
Dann gibt es zwar so lange keine neuen E-Mails, dafür kann man aber nun in Ruhe auch remote an die Ursachen gehen und die Warteschlangen leeren. Und das ist gerade bei den älteren Exchange-Versionen 2000 und 2003 leider durchaus langwierig und zeitraubend, da hier die Warteschlangen nach Zieldomains sortiert sind und man bei jeder einzelnen Zieldomain zunächst wartende Nachrichten suchen und dann löschen muss. Bei 100 wartenden Mails darf man für diesen Praktikantenjob gern mal eine Arbeitsstunde einkalkulieren.
Beim Exchange 2007 hat man bei Microsoft übrigens das Problem erkannt und unter anderem einen erheblich schnelleren Zugriff auf die Warteschlangen eingebaut.
Schreibe einen Kommentar