Es begann banal.
Ein E-Mail, das angeblich von mir selbst kam. Mit einem Manuskript im Anhang. Einer alten Version.
Ich hatte dieses Mail nicht geschrieben. Nicht verschickt. Und doch war es da.
Kurz darauf fiel mir auf: Ein anderes Mail, das ich sehr wohl versendet hatte, war im Ordner „Gesendet“ nicht auffindbar. Gleichzeitig lag eine Empfangsbestätigung vor. Das Mail war also real verschickt worden – nur meine Software wusste nichts mehr davon.
Was zunächst wie ein individueller Bedienfehler aussah, entpuppte sich schnell als etwas anderes. Im Webmail war alles korrekt. Nur in Outlook „Neu“ war die Realität verzerrt: Phantom-Mails, verschwundene Mails, alte Entwürfe, die plötzlich wieder auftauchten.
Kein Datenverlust. Kein Sicherheitsvorfall.
Aber etwas war beschädigt: die Möglichkeit, sicher zu wissen, was tatsächlich passiert war.
Der erste Riss: Wenn der Client nicht mehr autoritativ ist
Früher war die Sache einfach. Der Mailclient war ein Werkzeug.
Er zeigte an, was auf dem Server lag. Fehler ließen sich lokalisieren, reparieren, zumindest erklären.
Outlook „Neu“ ist kein solcher Client mehr. Es ist eine Oberfläche über einer Cloud-vermittelten Synchronisationslogik. Entscheidungen werden serverseitig rekonstruiert, Zustände interpretiert, nicht mehr abgebildet.
Der Client ist nicht mehr Quelle der Wahrheit.
Er ist eine Ansicht unter Vorbehalt.
Für Laien ist das kaum erkennbar. Für sensible Arbeitskontexte – Texte, Verträge, Verantwortung – ist es fatal. Denn Vertrauen ersetzt Überprüfbarkeit.
Recherche statt Beruhigung
Meine erste Reaktion war nicht Empörung, sondern Recherche.
Ist das ein Einzelfall? Ein Bug? Ein Konfigurationsproblem?
Nein.
Die Probleme mit IMAP in Outlook „Neu“ sind dokumentiert, bekannt, wiederkehrend. Ordner werden nicht korrekt synchronisiert. Gesendete Mails verschwinden lokal. Alte Entwürfe tauchen wieder auf. Konfigurationsmöglichkeiten wurden entfernt. Reparaturmechanismen existieren nicht mehr.
Wichtig dabei: Das IMAP-Protokoll selbst funktioniert.
Der Fehler liegt nicht im offenen Standard, sondern in seiner Behandlung durch moderne Plattform-Clients.
Damit verschob sich die Frage.
IMAP ist nicht tot – aber unerwünscht
IMAP wird weiterhin gepflegt. Langsam, konservativ, stabil.
Es ist kein Innovationsfeld, aber eine robuste Infrastruktur. Weltweit im Einsatz, gerade bei kleinen Anbietern, eigenen Domains, unabhängigen Mailservern.
Was fehlt, ist nicht Technik – sondern Aufmerksamkeit.
IMAP passt nicht zur strategischen Logik großer Plattformen.
Es erzeugt keinen Lock-in, keine Datenhoheit, keine KI-Pipeline. Es ist transparent, clientautonom, austauschbar.
Deshalb wird es nicht abgeschaltet.
Es wird marginalisiert.
Weg vom Client, hin zum Service
An diesem Punkt wird das Muster sichtbar.
Microsoft, Google und andere wollen E-Mail nicht abschaffen. Sie wollen es entprotokollieren.
E-Mail wird vom überprüfbaren Kommunikationsakt zum Service-Event. Nicht mehr: Ich habe gesendet.
Sondern: Das System hat etwas verarbeitet.
Kommunikation bleibt transportfähig (SMTP), aber der Zustandsraum – Ordner, Flags, Entwürfe, Metadaten – wird proprietär. Zugänglich nur über APIs. Interpretierbar nur innerhalb des Ökosystems.
Interoperabilität existiert noch – aber nur als Mindestbrücke.
Komfort, Transparenz und Kontrolle bleiben intern.
Der systemische Effekt: Aushungern ohne Abschalten
Niemand muss offene Standards verbieten.
Es reicht, sie unbequem zu machen.
Wenn IMAP in modernen Clients unzuverlässig wirkt, trifft der Frust nicht den Client, sondern den Anbieter. Kleine Mailprovider erscheinen „kompliziert“. Offene Systeme wirken „instabil“.
Die Entscheidung der Nutzer ist dann keine bewusste Abkehr von Offenheit – sondern Erschöpfung.
Ein Wechsel aus Müdigkeit.
So entsteht Aushungerung ohne Aggression.
Marktmacht ohne Verbot.
Monopolisierung ohne Ankündigung.
Warum das kein Fortschritt ist
Marktmonopole sind gut untersucht. Sie führen nicht zu besseren Systemen, sondern zu:
- Intransparenz
- steigender innerer Komplexität
- externalisierten Kosten
- sinkender Fehlertoleranz
- erhöhtem systemischem Risiko
Genau das zeigt sich hier im Kleinen: Ein System, das sich nicht erklären lässt, lässt sich auch nicht korrigieren. Ein System, das Vertrauen verlangt, ohne Überprüfbarkeit zu bieten, verschiebt Verantwortung auf den Nutzer.
Effizienz wird simuliert, nicht realisiert.
Das mulmige Gefühl
Mein mulmiges Gefühl rührt nicht von einem Bug.
Es rührt von der Erkenntnis, dass wir uns an Systeme gewöhnen sollen, die sagen: „Vertrau mir.“
Nicht: „Hier ist, was passiert ist.“
Der Weg vom Client zum Service ist legitim.
Aber ohne Transparenz, Austauschbarkeit und offene Referenzen führt er nicht zu Vereinfachung, sondern zu Abhängigkeit.
Der eigentliche Unfall ist nicht die Monopolisierung selbst.
Der Unfall ist die schleichende Normalisierung von Intransparenz.
Und dieser Unfall ist – so fürchte ich – tatsächlich unaufhaltsam.
Update:
Im Zuge der weiteren Prüfung stellte sich heraus, dass Outlook im selben Moment nicht nur eine, sondern mehrere bereits früher korrekt versendete E-Mails erneut verschickt hatte.
Der Vorgang wurde von mir überhaupt nur deshalb bemerkt, weil zufälligerweise eine dieser E-Mails an mich selbst adressiert war; ohne diesen Umstand wäre die erneute Versendung unbemerkt geblieben.
Entscheidend ist damit nicht die Häufigkeit oder Dauer des Fehlers, sondern die Tatsache, dass ein singulärer, gleichzeitiger Systemvorgang ausreichen kann, um formell wirksame Kommunikation auszulösen, ohne dass der Absender davon Kenntnis hat oder dies im Nachhinein eindeutig belegen könnte.
Weiterführende Texte:
Implizite Obsoleszenz durch Firmware- und Sicherheitsanforderungen
KI-Modelle und der vertraute Abbruch von Kohärenz