SPIEGEL-Online ist im Urlaub.

Zumindest teilweise, wie mir scheint. Nicht, weil SPIEGEL Online gerade übermäßig langweilig wäre, sondern weil ich gestern einen (harmlosen) Leserbrief auf einen Artikel geschrieben und ich nun als Souvenir von zwei Redakteuren eine Abwesenheitsnachricht erhalten habe, zusätzlich zur obligatorischen Hinweisnachricht, dass mein Leserbrief angekommen sei und man so viele bekommen würde, dass man nicht jede einzelne beantworten könne. Na denn.

Die benutzen Lotus Notes… die armen Hunde. 😉

Sicher oder nicht sicher?

Zu den Phänomenen, die man im EDV-Support ständig erlebt, gehört es, dass EDV-Probleme grundsätzlich ganz plötzlich kommen und selbstverständlich niemals der Nutzer Schuld hat, Betonung auf „niemals“. Gerade im Hinblick auf diese Phänomene mache ich wirklich gern hin und wieder auch mal Privatkundensupport, der bei uns, da wir einen Schwerpunkt auf Geschäftskunden haben, relativ selten vorkommt.

Ruft also ein Kunde an, der Probleme mit dem Versenden von E-Mails hat. Gut, da habe ich so viel Erfahrung, dass ich hier problemlos den Problemablauf und die Lösungssuche aus dem Gedächtnis fahre, also gemütlich zurückgelehnt, den Hörer mit der gegenüberliegenden Hand über den Kopf am Ohr fixiert und los geht es. Er schickte noch voran, dass er eine E-Mail erhalten habe, angeblich von uns, in der stehen würde, dass sein E-Mail-Zugang gesperrt würde. Ah ja, das ist schon mal ein Signal, da war doch ein Trojaner im Umlauf, der das sagte. Nun gut, gehen wir die Sache von vorn an:

  • „Was sagt der Kollege Computer beim Sendeversuch?“
    • „Er sagt, dass er den Server nicht finden kann.“
  • „Gut, haben Sie zu diesem Zeitpunkt eine Internet-Verbindung?“
    • „Keine Ahnung, kann ich nicht sagen.“
  • „Okay, dann probieren Sie das bitte aus und achten Sie explizit, dass Sie online sind. Haben Sie Modem oder ISDN?“
    • „Modem.“
  • „Gut, dann können wir das nicht während diesem Gespräch ausprobieren. Bitte auflegen, ausprobieren und nochmal anrufen.“
    • „Ja, mache ich.“

Tatsächlich meldet sich der Kunde nach einer Minute, es funktioniert. Da würde ihm schon ein Stein vom Herzen fallen.

  • „Okay, wunderbar, dann funktioniert Ihr E-Mail-Zugang offenbar. Kommen wir nochmal kurz auf diese Mail zurück. In dieser Mail war ein Anhang, haben Sie den angeklickt?“
    • „Nein.“
  • „Sind Sie sich sicher? Dieser Anhang enthält höchstwahrscheinlich einen Computervirus, es wäre deshalb wichtig, wenn Sie das rekapitulieren können.“
    • „Hm, wo Sie mich so fragen, bin ich mir eigentlich gar nicht so sicher. Es könnte schon sein, dass ich da draufgeklickt habe.“

Meine jahrelang gepflegte EDV-Supportintuition lässt bei sowas grundsätzlich sofort alle Alarmlichter schrillen. Wenn jemand am Telefon initial beim Gesprächsanfang sagt, es würde irgendetwas nicht mehr gehen und er habe ausdrücklich nichts verändert, dann stimmt das meist fast, wenn auch die Reihenfolge nicht ganz stimmt. Ursprünglich hat er vermutlich tatsächlich nichts gemacht, irgendwie ging es nicht, dann hat er an allen Schaltern rumgespielt und jetzt bekommt er es gar nicht mehr auf die Reihe.

Meinen Tipp zu AntiVir, dass er als Privatkunde kostenlos installieren darf, nahm er jedenfalls in dem für mich sehr bekannten, sehr erleichterten Ton an. Jahaa, ich kenne das. 😉

Größe von Attachements in E-Mails.

Immer wieder ein beliebtes Diskussionsthema im Support und gelegentlich auch ein richtiges Reizthema, mit dem ich mit mindestens einem Kunden auch einmal richtig Zoff hatte: Die Größe von Attachements in E-Mails in Verbindung mit Versand- oder Empfangseinstellungen auf Mailservern.

Grundsätzlich ist es keine falsche Vorgehensweise, die Größe von abgehenden E-Mails zu beschränken, allein schon aus dem Grund, damit Mitarbeiter nicht ihr gesamtes Witzfilmarchiv per E-Mail um den Globus schicken. Den Empfang ebenfalls mit einer Größenbeschränkung zu versehen, ist in meinen Augen schon eher weniger sinnvoll, aber grundsätzlich ist das auch jedem Administrator eines Mailservers seine Sache.

Das Problem bei Größenbeschränkungen auf Mailservern ist jedoch, die Größe richtig einzuschätzen und da hapert es regelmäßig: Es gilt nämlich das Phänomen, dass der normalerweise 8-bittige ASCII-Code beim Versand in 7-bittigen ASCII-Code umgewandelt wird. Sonderzeichen werden auf diese Weise in 7-Bit-ASCII-Code codiert, so dass die so kodierten E-Mails kompatibler um die Welt reisen können.

Diese Codierung gilt auch für Attachements, weshalb es schon mal eine ganz Weile dauert, bis E-Mails mit größeren Attachements überhaupt einmal sendefertig sind. Und diese Codierung hat noch eine andere Seite: E-Mails werden rund um ein Drittel größer. Eine Datei, die beispielsweise 9 Megabyte groß ist, erzeugt also eine E-Mail, die rund 12 Megabyte groß ist. Das mag schon noch durchgehen, allerdings erreicht das in noch höheren Dimensionen fast schon dramatische Züge: Aus 30 Megabyte werden 40 Megabyte, aus 60 dann 80.

Hübsch ist wenigstens, dass gut konfigurierte Mailserver, die eine Empfangsbeschränkung für größere E-Mails haben, auch entsprechende Fehlermeldungen an den Absender schicken, in der Regel mit dem SMTP-Statuscode 5.2.3. Klarer Fall für zu dicke Brummer. Und dann oft das nächste Problem: Dem Administrator eines empfangenden Mailservers die gleiche Erklärung nochmal zu liefern und zu hoffen, dass da jemand versteht.