Da ist sie nun, eine weitere Positiverfahrung über das Produkt mailbox.org – diesmal mit der Firma. Dieser Fall zeigt, warum mailbox.org doch etwas anders ist als der typische Mailanbieter. Bevor die Stimmen laut werden, das hier wäre nicht gekennzeichnete Werbung für unseren Sponsor, den muss ich enttäuschen: Während des gesamten Zeitraums war ich nur der Stefan von $FIRMA, einen Bezug zu linuxnews.de gab es nicht und war zu keinem Zeitpunkt für den Support ersichtlich. Die Firma zahlt auch Geld dafür, dort ist nichts gesponsort. Für die Firma habe ich damals den Silber-Plan ausgewählt, somit den kleinstmöglichen, bei dem man meinen könnte, dass sich dort keiner ein Bein ausreißen wird.
Was war das Problem
Ich wollte endlich Ruhe in dem Mail-Thema, ständig verworfene Mails wegen Blacklisting sind einfach lästig. Das Fass zum Überlaufen brachte der bisherige Anbieter durch einen verpatzen Zertifikatsaustausch, der mich zwang, die Mails auf Port 25 unverschlüsselt an ihn weiterzuleiten. Warum auf dem Transportweg unverschlüsselte Mails keine gute Idee sind, könnt ihr hier nachlesen. Nun gut, ein neuer Anbieter musste her. Durch unser Sponsoring von mailbox.org war mir das Businessprodukt bereits vertraut. “Funktioniert hier gut, geschäftlich bestimmt auch!” – prompt war es gebucht. Parallel hatte ich beim alten Anbieter gekündigt und das falsche Ablaufdatum notiert, das wird später noch wichtig. Über drei Wochen habe ich das sicherlich mal ausprobiert und zum Laufen gebracht, soweit der Gedanke. Wie sollte es auch anders sein, hat in diesen drei Wochen förmlich die Welt gebrannt, es blieb keine Zeit für ein intensives Testing.
Unsere Exchange-Umgebung läuft über eine SmartHostDelivery, der Exchange steht nicht »direkt am Internet«. Dieser Aufbau hat Vor- sowie Nachteile, für mich überwiegen die Vorteile: Soll sich doch der Anbieter um Blacklisting kümmern, warum sollte ich das auch noch tun. Zudem: kein Exchange am Internet = keine Probleme. Für alle nicht-Exchange-Admins gibt es hier mal eine Übersicht über den Aufbau:
Ein User schreibt eine Mail, diese erreicht den Exchange. Der Exchange schaut in seine Sendeconnectoren, welcher für die gewünschte SMTP-Domäne zuständig sind und verschickt über diesen. Für mailbox.org sieht das aus, wie ein normaler Mailclient (abgesehen vom HELO Namen, der offenbart es das hier ein Server kommt). Soweit die Theorie.
Die Praxis: Human Error
Das notierte Kündigungsdatum beim alten Anbieter war der 11.11.2023, so weit, so falsch. Am Mittwoch erreichte mich dann der Anruf: “Stefan! Hier gehen keine Mails raus! Mach was!”. Das fällt bei uns nicht gleich auf, da das eingehende Mailing nach wie vor funktionierte, das war zuvor schon auf mailbox.org umgestellt (mittels Pop-Connector).
Unsere Exchange-Server laufen auf Server 2022 Core, ein Server ohne GUI. Unter Linux habe ich auch keine GUI, bisher hat mich das auch nie gestört. Dennoch vermisse ich die Warteschlangenanzeige aus der Exchange Toolbox. Hier hilft dann ein Get-Queue -Identity NAME, nicht schön, funktioniert aber. In den entsprechenden Fehlermeldungen fand ich dann heraus, dass die Submission voll mit Mails hing. “Ich hab mich doch nicht beim Kündigungsdatum vertan?!” Oh. Doch Stefan, das hast du, wie sich ein Log-in beim alten Anbieter später herausstellen sollte! Mist, jetzt brennt es – eine Lösung muss her.
Die Support-“Sitzung”
Die Ticketeröffnung bei mailbox.org als auch der restliche Kontakt lief klassisch per Mail. Ich erklärte die Systemkonfiguration und was ich vorhabe. Als Antwort kamen die Daten zum IMAP- sowie SMTP-Server. Man könnte sich nun darüber aufregen, hier verstehe ich die Supporter. Kontrolliere die Konfiguration erneut, keiner ist unfehlbar. Tippfehler passieren eben (oder eine tolle Windows-Krankheit, immer ein Leerzeichen am Ende des kopierten Textes mitzunehmen 🤬).
Nachdem meine Konfiguration überprüft war, frage ich mal ganz frei, ob ich nicht einige Logauszüge bekommen könnte. Die Antwort ließ mich zuerst sprachlos dastehen: Es kamen Teile eines Log mit! Egal bei welchem Anbieter ich das bisher angefordert hatte, gab es keine. Meist fordere ich Logauszüge an, wenn der Anbieter »stets bemüht« oder »unkooperativ« ist, hier ging es rein um die Schnelligkeit, mein Support-Superhero Andreas war sehr lösungsorientiert. Das Log brachte mich auf die richtige Spur, die erfolgreiche Spur. Auch einen Anruf vom Support gab es, da war aber schon Feierabend und das Handy aus.
Das IDS von mailbox.org hat mir über den gesamten Zeitraum in die Suppe gespuckt. Zu oft falsch authentifiziert, IP gesperrt und das nicht zu knapp. An sich eine tolle Sache, für ein solches Debugging einfach nur lästig. Auf Zeiträume gehe ich hier nicht ein, hierzu findet sich auch nichts in der mailbox.org Wissensdatenbank. Offenbar ist dies eine Information, die nicht für die Öffentlichkeit bestimmt ist und nur mitgeteilt wurde, da dies für diesen Fall erforderlich war. Durch diesen Umstand zog sich die ganze Sache eine Woche lang.
Dumm, Dümmer, Microsoft Exchange
M$ Exchange versucht es laut Logauszug von mailbox.org zuerst unverschlüsselt:
SSL_accept error from mailserver.domain.com[DIE.FIRMEN.IP.v4]:58886: Connection timed outKleiner Fehler, große Auswirkungen – wie eigentlich immer in der IT. Port 465 ist damit gestorben, das klappt nicht. Auf Port 587 wird er gezwungen, sich auf eine Verschlüsselung zu einigen. Tiefer ergründet habe ich dieses Verhalten nicht, das Thema ist mit einem “Ach Microschrott”-Kopfschütteln ad acta gelegt. Für die Exchange-Admins: Set-SendConnector -Identity mailbox.org -RequireTls $true war aktiviert.
Mailing während der Supportphase
Ein Teil der Mitarbeiter hat den Webmailer genutzt, was auch hervorragend funktionierte. Bei der Nutzerzahl auch umsetzbar, wir sind kein Unternehmen mit 20.000 Mitarbeitern. Die restlichen Mitarbeiter hatten kein Mailing, mal eine ruhige Zeit, den Papierkram zu erledigen.
Was denkst du dir dabei, eine Firma tagelang ohne Mail zu lassen?!
Bevor die Kommentare laut werden, möchte ich hierzu doch einen Absatz verlieren. Manch einer, der diesen Artikel gelesen hat, wird sich nun fragen: Ist der wahnsinnig? Eine Firma tagelang ohne Mail sitzenzulassen, geht nicht! So weit, so richtig, zwei wichtige Faktoren sind bisher nicht erwähnt worden.
Zum einen sind meine Hauptmailnutzer über die Maßen leidensfähig, diese arbeiten nämlich auch mit DATEV und sind Kummer gewohnt. Hier hörte ich über den gesamten Zeitraum eigentlich nur “Wann gehts wieder?” oder auch “Na immer noch nicht fertig?”. Zweites gehört zum guten Ton bei uns, diese kleinen Sticheleien motivieren. Die Retourkutsche kam direkt: Lohn schon fertig? Jeder, der diese Frage vor dem Monats-Vierzehnten stellt, wird normalerweise an Ort und Stelle geschlagen 😇
Der zweite ist der viel wichtigere Punkt: Backupsysteme. Ohne einen Plan B arbeite ich selten, so auch hier. Ein Umstellen des Versands auf Amazon SES wäre zu jedem Zeitpunkt möglich gewesen, ein Drop in Replacement. Der Versand über SES ist bereits getestet gewesen, der Sendeconnector schlummerte im deaktivierten Zustand.
Im Grunde war es nur ein abwägen, wie weit die Geduld der Nutzer reicht und wie lange der Support/Stefan benötigt, um das zu beheben.
Fazit
Im geschäftlichen Umfeld ist mailbox.org empfehlenswert. Hier gibt es sogar Hilfe für nicht offiziell unterstütze Konfigurationen. Es wird sich sogar die Mühe gemacht, in Log-Files zu graben – auch nicht üblich. Von mir eine klare Empfehlung.
Eine Anleitung wie man eine Exchange hinter mailbox.org setzt, wird in der Artikelserie Host it yourself folgen. Diese Anleitung darf gerne von Mailbox.org für die eigene Wissensdatenbank kopiert werden.
