T-Mobile (Update: und Vodafone) manipuliert offensichtlich die Inhalte von Websites während der Übertragung, wenn diese via UMTS stattfindet. Zum Nachteil des Kunden werden mit jeder Anfrage viel mehr Daten übertragen, als dies notwendig wäre, und zwar zwischen 2x und 3x so viel als nötig (gemessen anhand von HTML, CSS und Javascript, bewußt ohne Bilder) ! Update: Inzwischen habe ich Seiten ausfindig gemacht, wo eine versechsfachung stattfindet!

(Update: bitte beachtet die neuen Updates, einfach nach fett geschriebenem Update suchen)

Nachfolgend zeige ich Beispiele für populäre Websites wie heise.de und spiegel.de (weiter unten). Ein Kommentator analysierte die vorliegenden Kenntnisse anhand von der Online-Ausgabe der  Welt (welt.de, siehe Kommentare). Auf eine Kundenanfrage vom 26.12.2010 mit Verweis auf diesen Block hat T-Mobile übrigens bis heute nicht reagiert. Update: seit dem 17.01.2010 besteht Kontakt, darüber mehr in den kommenden Tagen.

Dabei sollte man doch eigentlich eher vom Gegenteil ausgehen? Wer mobil surft, mag schlanke Websites, bei denen nur wenige Daten übertragen werden müssen, um in den Genuß der Information zu kommen. T-Mobile zerstört damit sogar die Mühe von verantwortungsbewußten Webmastern und Entwicklern, die Menge der übertragenen Daten zu reduzieren, um das Surf-Feeling gerade für schmalbrüstige Anbindungen wie UMTS smarter zu gestalten.

Was passiert bei T-Mobile UMTS? Statische Inhalte, die normalerweise im Cache landen, werden bei jedem Aufruf erneut übertragen. Caching-Systeme von Browsern werden somit umgangen. Beschleunigungs-Techniken wie der Einsatz von Amazon CloudFront und Content Delivery Networks (CDN) werden umgangen.

Einige Entwickler berichten über Darstellungsfehler und Anzeigefehler, die durch diese Umstrukturierung des Seiten-Quellcodes zustande kommen.

Alle deutschen Mobilfunker setzen für UMTS die Technologie von ByteMobile ein. Diese schalten einen sog. Proxy dazwischen, um Inhalte auf dem Endgerät komprimiert zu empfangen. Das dies in den vorliegenden populären Beispielen gründlich in die Hose geht, zeigt dieser Artikel.

Konkret: detaillierte Beschreibung

Ich habe herausgefunden, das Inhalte von CSS-Dateien und JavaScript-Dateien bei der Übertragung via UMTS von T-Mobile direkt in den HTML-Code der abgerufenen Website integriert werden und somit bei jedem (!) Request der Seite erneut übertragen werden. Statische Inhalte wie CSS-Code und Javascript können somit nicht mehr im Browser-Cache zwischengespeichert werden, um die Übertragung beim nächsten Seitenaufruf zu sparen. Es ist ein altbewährtes Mittel, Design-Informationen von Websites in eine separate, statische Datei auszulagern, um schlanke Übertragungswege zu gewährleisten. T-Mobile torpediert diese Vorgehensweise geradezu dramatisch! Außerdem werden – gemäss den Design-Guidelines von Yahoo – solche Inhalte gerne auf Content Delivery Networks ausgelagert (CDN), die darauf spezialisiert sind, derartige Inhalte schnellst möglich auszuliefern, möglicherweise auch unter Berücksichtigung des kürzesten Weges (sog. Edge Locations).

Tatsächlich klammert T-Mobile die Verwendung von CDN’s in meinen Untersuchungen (siehe unten) fast komplett aus! Ich habe nur wenige externe StyleSheet-Anbindungen und JavaScript-Files-Includes gefunden, die nicht im HTML-Body eingebettet wurden, sondern als externe Einbindung belassen wurden (was ja auch im Sinne der Entwicklers wäre).

Außerdem werden URLs für Bild-Dateien von “http://static.domain.de/bild.jpg” als “http://1.2.3.11/bmi/static.domain.de/bild.jpg” im HTML-Quellcode geliefert. Aber darauf konzentrieren wir uns erst später.

Oben drein sei gesagt, das sich der eine oder andere Web-Entwickler darüber wundert, das der UMTS-Proxy auch noch eine Javascript-Datei namens “bmi.js” einschleust! Aber das ist ein anderes, und mittlerweise auch bekanntes Thema.

Die Auswirkung in Zahlen

Folgendes konnte ich aber soeben feststellen:

Beispiel heise.de

Wenn heise.de aufgerufen wird via DSL oder von meinem Webserver aus über eine direkte Rechenzentrum-Anbindung, umfängt die reine HTML-Datei 69.362 Bytes. Dazu kommen zwar noch CSS-Files, aber die werden nur beim ersten Aufruf geladen und landen unmittelbar im Cache, sie werden also zwischengespeichert. Folglich müssen beim kommenden Aufruf normalerweise lediglich knappe 70 KBytes Daten übertragen werden.

Der gleiche Aufruf via T-Mobile UMTS liefert eine HTML-Datei mit einem Umfang von 171.702 Bytes! Und zwar kontinuierlich! Da der seitens heise.de ausgelagerte CSS-Code von T-Mobile jedesmal im HTML-Code erneut eingebettet wird, werden folglich bei jedem weiteren Seitenaufruf immer noch diese 170 KB übertragen (Abweichungen pro Artikelfülle), während via DSL nur 70 KB geliefert worden wären. Das ist eine knappe Verzweieinhalbfachung(!) der übertragenen Daten. Bei Volumentarifen kann somit das Limit viel schneller erreicht werden. Da selbst Flatrates oftmals bei 5 GB zumindest gedrosselt werden, betrifft dieser Umstand auch solche Kunden mit einer UMTS-Flatrate.

Interessant ist, das ein Aufruf via “wget” über UMTS den Original-Quellcode liefert. Lediglich der Aufruf via WebBrowser wird also von T-Mobile verändert. Dies werte ich als Hinweis darauf, das die Browser-Kennung (UserAgent) abgefragt wird.

Anbei zeige ich Screenshots vom Quelltext von heise.de einmal via WGET und einmal via Safari “geholt”:

In der Original-Version werden alle CSS- und JS-Dateien separat eingebunden und auch ausgeliefert:

Und jetzt der Original-Quelltext von heise.de, der die separaten Dateien auch als “externe” einbindet:

Dieses Bild ändert sich dramatisch, wenn der Seitenabruf via Safari oder Firefox von der gleichen Maschine via UMTS stattfindet.

Anbei der Quellcode von heise.de via UMTS:

Ein Unding aus technologischer und ökonomischer Sicht zugleich, und vor allem eine Backpfeife für die UMTS-Kunden: der gesamte CSS-Code wird direkt in die HTML-Seite eingebettet.

Es geht aber noch weiter: der Javascript-Code von Heise wird ebenfalls eingebettet. Allerdings ist T-Mobile hier geringfügig gnädig: die jQuery-Bibliothek wird weiterhin extern eingebettet und somit aus dem Cache bedient. Aber jeglicher Javascript-Code darüber hinaus wird schön sauber in den HTML-Code eingebettet:

Beispiel spiegel.de:

Viel interessanter wird es beim ehemaligen Nachrichten-Magazin:

Der Spiegel überträgt via DSL eine index.html in der Größe von aktuell 148.076 Bytes, zzgl. einer CCS-Datei mit einem Umfang von 171.454 Bytes und einer Javascript-Datei von 58.103 Bytes.  Letztere werden im Cache des Browsers abgelegt und beim zweiten Aufruf nicht erneut übertragen.

Dumm für den UMTS-Nutzer: dieser bekommt sowohl die CSS-Datei als auch die Javascript-Datei stets in der index.html eingebettet mitgeliefert, mit jedem Aufruf! Folglich werden auch beim zweiten und dritten Aufruf 293.000 Bytes übertragen, während der DSL-User mit 148 KB beliefert wird. Die ca. 140 KB große CSS-Datei wird bei jedem weiteren Seitenaufruf auf den Seiten von spiegel.de stets eingebettet mitgeliefert und kann somit nicht aus dem Browsercache bedient werden! Gleiches betrifft die Javascript-Datei! Dies bedeutet ein doppelt so hohes Volumenaufkommen beim Surfen auf spiegel.de via UMTS! Da wird eine komplette jQuery-Bibliothek mal eben in den HTML-Code eingebettet und jedesmal übertragen!

Anbei die Screenshots:

Dies ist der Original-Quellcode von Spiegel-Online (Startseite). CSS- und Javascript-Seiten gemäß alter Schule als separate Dateien includiert. Dadurch können Sie aus dem Browser-Cache bedient werden. Dies spart Übertragungsvolumen!

Nun die Variante, wie sie von T-Mobile über eine UMTS-Verbindung gesendet werden (Auszug):

Das obige Bild zeigt den Quelltext von Spiegel-Online, wenn dieser über eine UMTS-Leitung von T-Mobile übertragen wird! Der rot markierte Code wurde via T-Mobile in die HTML-Seite eingebettet. Normalerweise würde dieser Code über einen kleinen Verweis aus dem Browser-Cache bedient werden (siehe vorheriges Bild).

Opulentes Beispiel: jegliche Optimierung dank UMTS-Proxy zunichte gemacht

Wirklich sehr dramatisch wird es bei hinsichtlich der Übertragungsrate hochoptimierten Seiten! Ein sehr eindrucksvolles Beispiel ist qnopr.com.

Bei der Entwicklung habe ich darauf geachtet, die Seite so schlank wie  nur möglich zu machen.

Die eigentliche HTML-Seite für die Startseite benötigt nur 7 KB! Das (zugebenermasse sehr umfangreiche CSS) liegt auf einem CDN in Amazon CloudFront als eine ebenfalls 7.4 KB große gezippte CSS-Datei vor. Der Browser lädt also beim ersten Mal nur 14.4 KB, bei jedem weiteren Aufruf 7 KB.

Und bei UMTS via T-Mobile? 46 KB! Jedesmal! Der gezippte CSS-Code wird stets zum Nachteil aller Beteiligten in die HTML-Datei eingepackt, mit seinen gesamten unkomprimierten 36 KB!

Die von mir gewählte Variante, das CSS gezippt auf den Server zu laden, wird spätestens seit den Jahren mit dem Internet Explorer 5.5 bzw 6.0 von ausnahmslos allen verbreiteten Browsern inklusive Linux und Max bedient. Durch die Ummodellierung von T-Mobile werden die Style Sheets von qnopr.com  aber nicht mehr im stromsparenden gezippten Modus übertragen, sondern entkomprimiert in voller Länge! Das ist ein Skandal!

Jeder Aufruf von Qnopr oder ähnlich optimierter Seiten erfährt via UMTS eine verSECHSfachung der zu übertragenden Daten!

Eklatante Fehler bei UTF-8-Inhalten mit Byte Order Mark

Ein zusätzliches Problem konnte ich vor einiger Zeit mit CSS-Dateien feststellen, die auf Windows-7-Rechnern mit neuwertigen Editoren (lt. Angaben des Designers handelte es sich hierbei um Microsoft Expression Web) erstellt wurden. Diese schreiben das sogenannte BOM, das Byte Order Mark, an den Beginn der CSS-Datei, um den Zeichensatz “UTF-8″ bzw. UTF-16 anzukündigen. Der Proxy von T-Mobile (bzw. ByteMobile), der die CSS-Dateien in den Quelltext einfügen möchte, hörte zumindest noch in den Sommermonaten 2010 an dieser Stelle auf und lieferte die CSS-Inhalte gar nicht mehr aus! Ein technologisches Unding, das der Webmaster nicht verifizieren kann, solange er via DSL/LAN sonstwas ans Netz angebunden ist. Dumm, wenn dann ein Kunde anruft, sich über den schlechten Zustand seiner Website erkundigt, und dies nicht nachempfungen werden kann, solange man nicht selbst via UMTS prüft. Beweise hierfür liegen sowohl dem Autor als auch einem weiteren Web-Entwickler aus jeweils eigener Forschung vor und können auf Nachfrage ausgehändigt werden.

Update: an die mitlesenden Ingenieure der Deutschen Telekom: dieses Phänomen lässt sich auch heute noch nachweisen. Es folgen heute noch die Screenshots von einem Beispielprojekt. Korrektur: dank DSL-Problemen kann ich das erst in den kommenden Tagen nachreichen

Einer der Techniker, der mit mir zu dieser Thematik telefonierte und sich interessiert über die Bloginhalte erkundigte, reagierte auf dieses Beispiel (BOM im CSS-File) mit folgendem Satz: “Wenn man schon kaputte Dateien hochlädt, muss man sich nicht wundern, das da dann was schief geht.” Prinzipiell hat er Recht und ich stimme zu! Aber es handelte sich hierbei nicht um kaputte Dateien. Es ist scheinbar heutzutage nun einmal so, das die Windows-Welt gerne ein BOM an den Anfang der Datei packt. Dies habe ich ihm auch erklärt. Und tue dies hiermit auf schriftlichem Wege erneut.

Bilder

Bilder werden für UMTS-Anwender ebenfalls als gespiegelte Kopie aus dem Netzwerk von T-Online ausgeliefert. Hierzu wird der Quelltext entsprechend angepasst:

Beispiel auf spiegel.de:

Original-Code für die Einbettung eines Bildes:

<img width=”520″ height=”250″ border=”0″ align=”center” title=”Wachstum 2011: Ökonomen machen Deutschland Mut” alt=”Wachstum 2011: Ökonomen machen Deutschland Mut” src=”/images/image-141047-panoV9free-ymsi.jpg”>

Quellcode via UMTS:

<img width=”520″ height=”250″ border=”0″ align=”center” title=”Wachstum 2011: Ökonomen machen Deutschland Mut” alt=”Wachstum 2011: Ökonomen machen Deutschland Mut” src=”http://1.2.3.13/bmi/www.spiegel.de/images/image-141047-panoV9free-ymsi.jpg“>

Ich habe beide Bilddateien untersucht und konnte keine Unterschiede feststellen. Möglichweise liefert T-Online Bilddateien aus dem eigenen Netzwerk deutlich schneller an das Gerät als der herkömmliche Weg. Sinn würde es jetzt noch machen, die Bilddateien für das Web zu optimieren, wie es Yahoo mittels SmushIt! möglich macht. Bzgl. von Bilddaten konnte ich bisher weder eine Verbesserung noch eine Verschlechterung ausfindig machen. Zwar gibt es Hinweise aus der Community darauf, das der ursprüngliche Zweck des Proxies wohl tatsächlich die Verkleinerung von Bilddaten war. Möglicherweise liefert Spiegel die Bilder aber schon selbst optimiert genug aus. Diesen Faktor “Umbiegen von Bild-URLs” können wir also geflissentlich ausblenden. Aber der Schaden für CSS- und JS-Code ist in meinen Augen bereits enorm.

Update: nach Telefonaten mit Technikern der Deutschen Telekom weiß ich jetzt, das man das einstellen kann. Im Speedmanager von T-Mobile lässt sich u.a. die Bildkomprimierung ein- und ausschalten. Für meine SIM-Karte war die Komprimierung voreingestellt deaktiviert. Daher behielten die Bilddateien auch die gleiche Größe wie bei DSL. Aber um Bilddateien geht es hier auch nicht, sondern darum, wie mit externen CSS- und JS-Dateien umgegangen wird. Auf den Speedmanager komme ich innerhalb der kommenden Tage zurück.

Folgen

Die Folgen sind für den User teilweise dramatisch und erklären mir inzwischen einzelne Phänomene, die von UMTS-Kunden oft berichtet werden, die mit schlechtem Empfang zu tun haben: Seitenabbrüche, Übertragungsabbrüche etc. Dazu gleich mehr.

Viel schlimmer dürfte die Auswirkung auf Kunden mit Volumentarife sein. Die 250 MB bspw. sind somit – je Surfverhalten – viel schneller erreicht, als sie erreicht werden dürften. Auch Flatrate-Kunden tragen Schaden: schließlich sind die meisten (oder gar alle?) UMTS-Flatrates ab einem gewissen Volumen gedeckelt (sehr häufig bei 1 bzw. 5 GB), sprich: sie werden gedrosselt und mit einer Übertragungsrate bedient, die an die 90er Jahre erinnert.

UMTS-Kunden in Gebieten mit schlechtem Empfang werden ebenfalls mit der oben beschriebenen Taktik äußerst benachteiligt!

Wenn jedesmal der CSS- und Javascript-Code als erstes übertragen wird, und erst dann der eigentliche Text, also die Information, der Website, so können keine Inhalte dargestellt werden, wenn “unterwegs” die Übertragung abbricht. CSS und JS wurden zwar geladen, aber keine “Texte”.

Würde T-Mobile die Finger von den Daten lassen und sie neutral, also 1:1 so übertragen, wie es sich die jeweiligen Entwickler von Content Management Systemen und Blogsystemen etc. ausgedacht haben, so würde beim zweiten Seitenaufruf der CSS-Code bereits geladen sein. Folglich würden die eigentlich darzustellenden Inhalte direkt als erstes im Stream geliefert werden. Ein möglicher Erfolg bei schlechter Verbindung besitzt so eine viel höhere Wahrscheinlichkeit, als wenn zu Beginn des Streams immer nur Balast geliefert wird (welcher noch dazu ab 2. Aufruf überflüssig ist).

Außerdem konnte ich feststellen, das Änderungen an den grundlegenden CSS-Dateien nicht nur den Browser-Cache renewen müssen, sondern auch noch den UMTS-Cache von T-Mobile passieren (IP-Adresse via UMTS 1.2.3.X). Somit wirken sich Änderungen laut meiner Erfahrung an diesen Dateien erst verzögert aus. Der einzige Umweg ist hier vermutlich, die CSS-Datei umzubennen oder eine parametrisierte Versionskennung anzuhängen (ungetestet).

Größere Probleme gibt es mit der Byte Order Mark (siehe weiter oben). Hier ergeben plötzlich frühere Anrufe von Kunden einen Sinn, die ein total zerrissenes Abbild der Website erhalten, die der Webdesigner mit seiner DSL-Leitung nicht verifizieren kann.

Update: Kolateralschaden auf breiter Fläche bei modernem Webdesign

Spätestens seit Kalifornien und Web 2.0 hilft folgendes Muster den hochfrequentierten Websites, ihren Traffic zu minimieren: die Style Sheets werden zunächst via CSS-Komprimierer zusammengefasst und gekürzt. Anschließend werden sie, bei jedem Deployment, gezippt und mit dem Encoding-Type “gzip” auf ein CDN geladen. Alle modernen Browser können damit umgehen und CSS sowie Javascript auch als gezippte Datei laden! Damit verringert sich das Übertragungsvolumen nicht selten um den Faktor 6 bis 8!

Um diesen Komfort zu erhalten und an die Kunden weiterzugeben, sind Deployment-Verfahren notwendig, die über das übliche “Datei hochladen” weit hinausgehen.

T-Mobile’s UMTS-Proxy verdirbt diesen Aufwand konsequent und erstklassig! Anstatt nur die 10 KB beispielsweise zu laden, die die Entwickler diverser Sites vorbereitet haben, werden jedesmal 70-80 KB übertragen, unkromprimiert im Klartext. Hier sind bereits zwei Greueltaten benannt: “jedesmal” und “entkomprimiert”.

Je weiter sich aber diese Technologien verbreiten – und das wachsende Web hat keine andere Möglichkeit zur Zeit – umso dramatischer wird es sich hier auswirken, wie T-Mobiles UMTS dem Fortschritt entgegen wirkt!

Für die mitlesenden Techniker der Deutschen Telekom möchte ich folgende Beispiel-Seite benennen: http://www.qnopr.com

Update: der User Agent entscheidet tatsächlich!

Wer UMTS-Bandbreite sparen will, sollte via Firefox surfen und sich das Plugin “User-Agent Switcher” installieren. Wenn man dort dann z.B. einen User-Agent einstellt, den T-Mobile nicht kennt (Googlebot genügt, oder WGET), der erhällt die Daten 1:1 so übertragen, wie der Webserver die Inhalte normalerweise auch ausliefert.

Wichtig ist dies für Webdesigner, die via UMTS mit Firebug nach Styles schauen wollen, um diese ggf. zu editieren. Da T-Mobile den CSS-Code komplett neu arrangiert in die HTML-Datei einbettet, gibt es natürlich keine genauen Angaben mehr, welcher Style aktuell pro Element wirkt und aus welcher Ursprungs-Datei dieser kommt.

Das Ändern des User-Agents hat natürlich unter Umständen eine Nebenwirkung: der Webserver als solcher könnte entsprechend konfiguriert worden sein, das er dann selbstätig andere Inhalte liefert. Außerdem gibt es Konfigurationen, die “ungültige” Browser-Kennungen – also solche, die nicht bekannt sind – abgewiesen werden. Daher ist dieser Vorschlag aktuell nur eine Notlösung, die nicht allumfassend gilt!

Abhilfe

Twitterer “Rokory” weisst darauf hin, das sich der o.g. Proxy mittels APN “noproxy” deaktivieren lässt. Genauere Hilfen hierzu findet man auf dieser Seite.

Update: unter der Adresse speedmanager.t-mobile.de lässt sich einstellen, ob eine Optimierung stattfinden soll oder nicht, und wenn ja, welche. Ich werde darauf genauer eingehen während der nächsten Tage

Frohe Weihnachten wünscht Hagen

Update:

Ich verweise auf diesen Artikel, wo vor allem Content Management Systeme davon betroffen sind: http://blog.sky-bizz.com/2011/01/14/der-umts-wahnsinn-hat-noch-schlimmere-auswirkungen/

Update:

Techniker der Deutschen Telekom haben mich auf den Speedmanager von T-Mobile aufmerksam gemacht: T-Mobile Speedmanager.

Dort kann man als Kunde einstellen, ob man mit dieser “Optimierung” seitens der Provider arbeiten möchte oder nicht. Da es sich laut meinen Experimenten aber um keine Optimierung handelt, habe ich sie deaktiviert. Dann werden Websites auch wieder nativ übertragen, wie es sich die Webseitenbetreiber gedacht haben.

Schade nur, das niemand den Speedmanager kennt. Alle Mitwirkenden an dieser Artikelreihe waren ganz verblüfft, als wir vom Speedmanager seitens Telekom erfuhren. Diese Information wurde mir übrigens nicht an der Hotline zu teil, sondern mit einem Telefonat mit “richtigen” Technikern der Telekom.

Reaktionen

Als erster UMTS-Anbieter reagierte Vodafone über deren Facebook-Seite. Ehrlich gesagt, überraschte es mich auch nicht. Wer so öffentlich gefragt wird, muss reagieren. Bei T-Mobile bzw. Telekom durchläuft man da erstmal alle Instanzen des Kundensupports.

Siehe hier:

Das kam heute von der Telekom:

> vielen Dank für Ihre E-Mail.
>
> Wir möchten schnell für Sie tätig werden, brauchen hierfür
> allerdings noch einige Informationen. Bitte ergänzen Sie in
> dieser E-Mail folgende Angaben und senden diese an uns
> zurück.
>
> Vorname Name (Anschlussinhaber/in):
> Telefonnummer mit Vorwahl:
> Kundennummer:

Anschließend wurden noch Hinweise aufgeführt, wo ich die Kundennummer finden würde.

Danke Telekom! Ihr habt den Text also gelesen. Ganz bestimmt!

Vodafone reagierte wie folgt:

Hallo Hagen,

vielen Dank für diesen wirklich aufschlussreichen Artikel. Wir werden das beschriebene Problem genau prüfen lassen. Letztlich würden wir ja unser Netz dadurch mit viel unnötigem Traffic blockieren, was defintiv nicht gewollt ist….

Dein Vodafone Deutschland Team

Das nenne ich mal Support! Um das einmal klarzustellen: ich bin weder Vodafone-Kunde, -Aktionär, -Mitarbeiter etc. Ich war mal lange Vodafone-Kunde und wollte keiner mehr sein, und brauchte leider auch etliche Jahre, um keiner mehr zu sein (das ist eine andere Geschichte). Aber als Telekom-Kunde muss ich sagen: bei Vodafone arbeiten entweder schlauere Leute an der Stelle, wo man Kundenbeschwerden aufnimmt, oder hat modernere Strukturen. So ein Rückläufer wie von der Telekom “Bitte nennen Sie uns ihre Kundennummer” ist ja wohl in solchen globalen Angelegenheiten absoluter Nonsens!

Meine Antwort lautet:

Sehr geehrte Damen und Herren

ich habe sehr viel Zeit und Mühe aufgebracht, um ein “globales” Problem bei der von Ihnen eingesetzten UMTS-Proxy-Software zu analysieren. Hin und wieder kamen mir Zweifel darüber auf, warum nicht Ihre Ingenieure bereits hinter dieses Problem gestiegen sind!

Viel schlimmer aber ist: Sie haben sich entweder nicht die Mühe gemacht, mein Anliegen sorgfälltig zu lesen bzw. an adäquate Stelle weiterzuleiten, oder haben den Sachverhalt nicht verstanden.

Es handelt sich hierbei NICHT um ein lokales Kundenproblem, das von der Kundenhotline bearbeitet werden kann. Demzufolge benötigen Sie weder eine Kundennummer noch meinen Namen (der übrigens in der Email stand und weltweit eindeutig ist). Es betrifft JEDEN Telekom-Kunden, der UMTS nutzt! Und es betrifft auch jeden Vodafone-Kunden. Dies ist in meinem Artikel ausführlich belegt.

Ihr Konkurrent Vodafone hat auf der hauseigenen Facebook-Seite angekündigt, dem Problem auf die Spur zu gehen, ohne nach Kundennummer etc. zu fragen. Dort hat man meinen Text gelesen und ihn entsprechend zur Kenntnis genommen. Und zwar wie folgt:
“Vielen Dank für diesen wirklich aufschlussreichen Artikel. Wir werden das beschriebene Problem genau prüfen lassen.”

Also: leiten Sie meine untenstehende Anfrage bitte an Ihre Ingenieure weiter.

Ihre Ingenieure dürfen mich für Fragen gerne telefonisch kontaktieren:****-******** .

Mit freundlichen Grüßen

Mal schauen, was draus wird. Vielleicht kann sich ein Callcenter-Mitarbeiter bei der Telekom doch dazu überwinden, meine Email direkt nach intern weiterzuleiten ohne erstmal die üblichen 20 Callcenter-Fragebögen auszufüllen….

Update

Mit dem Speedmanager kann man das Verhalten zumindest bei T-Mobile einstellen. Schade, das es nicht explizit kommuniziert wird.

http://www.t-mobile.de/speedmanager/0,20641,24080-_,00.html

Der Speedmanager muss laut T-Mobile über die UMTS-Verbindung aufgerufen werden, dann kann man aus 3 verschiedenen Optionen auswählen.