Wer längere Zeit im Support mit Kundenwünschen zu tun hat, wird manchmal mit der Situation konfrontiert, dass man etwas einrichten muss, obwohl man genau weiß, dass es Unsinn ist. Wie geht man damit um? Ich finde es sehr schwierig, den schmalen Grat zu finden zwischen blinder Umsetzung von offensichtlichem Schwachsinn und überheblicher Bevormundung. Ich denke, dass man in jedem Einzelfall anders in die Kommunikation gehen muss.
Anfrage: Ein All-in-One-System für Mail und Webdienste
Oft ist es auch so, dass man diese Unterscheidung gar nicht so einfach treffen kann. Wenn man nämlich die Intention der Anfrage nicht kennt. So auch neulich bei der Anfrage, auf einem All-in-One-System für Mail und Webdienste unseren WHS mit Plesk oder auch ein anderes System, wie z. B. Froxlor, einen Webmailclient, zu installieren. Oberflächlich betrachtet eigentlich eine gar nicht so schlechte Idee. Es gibt ja durchaus Gründe, warum man ein Webmail-Interface für den Zugriff auf seine Nachrichten haben möchte. Zum Glück war nicht so ganz klar, welche Software man am besten einsetzen sollte. Es gibt ja da reichlich Auswahl von Horde über Squirrel bis zu Roundcube … und die Liste ist natürlich noch lange nicht komplett. So kam es zu einem Telefonat, in dem ich das klären wollte. Dabei stellte sich heraus, dass der Grund für diesen Auftrag ein wenig ungewöhnlich war. Es gab ein Postfach auf diesem Server, das jeden Tag aufs Neue so voller Spammails war, dass der lokale Mailclient des Benutzers es schlicht nicht mehr abrufen konnte. Die Idee war nun, wenn man ein Mailprogramm auf dem Server installiert, dann sind die Mails ja schon da und müssten ja nicht abgerufen werden. Das Problem wäre also gelöst.
…
So einleuchtend diese Begründung dem Laien erscheinen mag, so abwegig ist sie bei Betrachtung durch den Fachmann. Auch ein webbasierter Mailclient muss die Mails über ein geeignetes Mailprotokoll in seine Verwaltung übertragen und dem Benutzer zur Verwendung und Bearbeitung präsentieren. Er hat also mit der gleichen Problematik zu kämpfen wie der lokale Mailclient namens Thunderbird, Outlook, Applemail oder sonst wie. Darüber hinaus kommen noch die bei Administratoren überaus beliebten Beschränkungen hinzu, die sich aus der Verwendung einer Scriptsprache wie PHP oder Perl ergeben, wie Benutzerrechte, Speicherlimitierungen, Laufzeitbeschränkungen, Variablengrößen und viele mehr. Von den Hürden des HTTP(s)-Protokolls bei der Behandlung von Uploads und der Darstellung im Browser, die der Programmierer ja im Vorfeld nicht festlegen kann und von denen sich freundlicherweise jede ein wenig anders verhält, ganz zu schweigen.
Fazit
Am Ende ist es also bei der aktuellen Problemstellung der denkbar schlechteste Lösungsansatz, auf ein Webmail-Interface umzusteigen. Es hätte bei der Behandlung dieses Postfaches wohl eher noch mehr Probleme geben als mit dem bisher verwendeten Client. Die Lösung muss natürlich lauten, einen geeigneten Mechanismus zu finden, den Spam aus dem Postfach rauszuhalten, aber so weit soll es heute nicht ausgeführt werden. Um es frei nach Theodor Fontane auf den Punkt zu bringen: Das ist ein weites Feld!
Als Essenz bleibt für mich die Erkenntnis, dass des Kunden Wille zwar immer zu respektieren ist, es aber auch mal sehr gesund sein kann, die Beweggründe zu hinterfragen, sonst kann daraus schnell mal seine Hölle werden. Und wer ist’s dann gewesen? Sicher nicht die Schweizer!