Michael Heydekamp <[EMAIL PROTECTED]> wrote on 18.06.05: > Martin Wodrich <[EMAIL PROTECTED]> wrote on 09.06.05:
> [...] >> Das von Michael angekündigte Tool findet sich jetzt auf dem FreeXP- >> Server. > Dazu gibt es noch einige Dinge nachzutragen. Speziell dazu, was das > Patchtool eigentlich genau bewirkt: [...] Von diesem Patchtool wird es aus aktuellem Anlaß (s.u.) demnächst ein Update geben, und zwar zeitgleich mit einer neuen Testversion des Enhanced UUZ/II (die sich durch die gestern neu entdeckten Fakten bzgl. UKAW nun leider etwas verzögern wird). Es hat sich durch die Arbeiten am und Tests mit dem neuen E-UUZ/II (hier speziell den neuen "User-Agent:"-Header betreffend) herausgestellt, daß UKAW v3.50 in ungepatchtem Zustand nicht nur Header verändert, entfernt und neue hinzufügt, sondern sie unter Umständen auch so unbrauchbar macht, daß der UUZ die Nachricht z.B. nicht mehr korrekt decodiert. War schon das bisherige Verhalten von UKAW hart an der Grenze zum Erträglichen (was aber mit dem oben erwähnten Patchtool behoben werden konnte), ist hier nun ein Punkt erreicht, an dem es definitiv nicht mehr lustig ist. Speziell, wenn man um die Hintergründe des Verhaltens von UKAW weiß. Da der Autor von UKAW auf Mails in der Vergangenheit zu diesem und anderen Themen nicht reagiert hat (wie erst kürzlich noch zum Thema Öffnen der XP.EXE im Schreibmodus, aber auch schon vorher eben in Sachen Headerpantschereien), wird uns nichts anderes übrig bleiben, als selbst geeignete Maßnahmen zu ergreifen. Das Patchtool ist nur die erste und eine davon, Details zu weiteren folgen zum gegebenen Zeitpunkt. Wer nicht auf eine neue Version des Patchtools sowie des E-UUZ/II warten will, sollte das bisherige Patchtool herunterladen und unbedingt mit dem Schalter "/x-xp" starten. Das Tool kann heruntergeladen werden unter: ftp://ftp.freexp.de/freexp/clients/ukawp.zip Wer es bisher noch gar nicht verwendet hat und gleichzeitig UKAW v3.50 einsetzt, sollte es sich ganz unabhängig von dem hier besprochen Bug und ohnehin bald beschaffen, alleine schon im Interesse der Vermeidung des ungefragten Veränderns, Hinzufügens und Entfernens von Headern generell (denn dokumentiert ist das alles "natürlich" nicht). Mit dem Schalter "/x-xp" wird im Unterschied zum bisherigen Default- verhalten zusätzlich verhindert, daß UKAW mit "X-XP-" beginnende Header löscht. Das Patchtool hat dies per Default bisher nicht getan, weil durch die übrigen Patches gewährleistet war, daß Software-Header nicht mehr von UKAW verändert wurden und es daher für den vom bisherigen E-UUZ/II erzeugten Header "X-XP-Version:" keinen zwingenden Grund mehr gab. Auf das Entfernen dieses Headers zielte UKAW nämlich ab, und in gepatchtem Zustand war das dann -- aber auch nur dann! -- im Sinne der Vermeidung redundanter Header sogar ganz praktisch... Das Entfernen der "X-XP"-Header ist aber nun genau die Ursache für den gestern entdeckten Bug in UKAW, und daher wird die nächste Version des Patchtools neben den übrigen Maßnahmen per Default auch dafür sorgen, daß "X-XP"-Header nicht mehr entfernt werden. Die erst gestern (noch vor der Entdeckung des Bugs) erstellte Kurzdoku zu dem Tool ist in diesem Punkt also als nicht mehr aktuell zu betrachten. Wer es jetzt noch genauer wissen will, worum es im Detail geht und was passieren kann, möge weiterlesen: Angefangen hat es damit, daß eine qp-codierte Mail hier nicht decodiert wurde. Natürlich denkt man bei aktuellen Arbeiten am UUZ zuallererst an einen eigenen Bug und ich war auch schon im Debugger unterwegs, als mir plötzlich folgender seltsamer gefoldete CTE-Header in der noch im Spool- Verzeichnis liegenden RFC-Nachricht auffiel (Ziffernfolge händisch genullt): ----------8<---------- > Content-Transfer-Encoding: quoted-printable > 0000000000) ----------8<---------- Das hat der UUZ zu ... ----------8<---------- > Content-Transfer-Encoding: quoted-printable 0000000000) ----------8<---------- ... entfaltet und anschließend gesagt "Codierung 'quoted-printable 0000000000)' kenne ich nicht, also decodiere ich auch nix und behandle die Nachricht per Default als 8bit". Folge: eine undecodierte und damit in großen Teilen unlesbare Nachricht. Nur wie kommt dieser Header zustande? Wie sich bei weiteren Tests herausstellte, hatte der Absender folgendes gesendet: ----------8<---------- > Content-Transfer-Encoding: quoted-printable > X-XP-Version: FreeXP (CrossPoint)/3.40-RC3 (R/Cxxxx; DOS16/WinNT [EMS]; > 0000000000) ----------8<---------- Der mitdenkende Leser ahnt es vielleicht schon: UKAW v3.50 entfernt mit "X-XP" beginnende Header nicht nur ausgehend, sondern sogar auch eingehend (das ist neue Erkenntnis #1). Dabei berücksichtigt UKAW in seinem blindwütigen Eifer, den Header "X-XP-Version:" zu eliminieren, aber nicht, daß er selbstverständlich gefolded sein kann (in diesem Fall, weil die für Mails empfohlene Länge von 78 Zeichen überschritten war). Es entfernt nur die erste Zeile und läßt die restliche(n) Zeile(n) stehen. Das ist neue Erkenntnis #2. Diese gefoldeten Zeilen werden jetzt logischerweise dem Header zugerech- net, der vor "X-XP-Version:" steht, in diesem Fall zufälligerweise "Content-Transfer-Encoding:" (hätte der User in XP z.B. eine Homepage angegeben, wäre der Header "X-Homepage:" betroffen gewesen, mit weit weniger fatalen Folgen). Abgesehen davon, daß das Hinzufügen, Verändern und vor allem das Entfernen von Headerzeilen schon für sich ein absolutes Unding ist und das ansonsten sehr gute Programm UKAW im Grunde disqualifiziert, muß man angesichts solcher Folgen ja sogar schon fordern: Wenn schon, dann aber bitte richtig. :-( Daß es sich bei "X-XP-Version:" um einen ausschließlich wegen UKAW im März 2002 implementierten Workaround handelte, um den originalen XP- Software-Header zu retten (denn bei dem von UKAW veränderten gingen bisweilen sämtliche Informationen wie Versionsnummer etc. verloren), ist nur ein Treppenwitz am Rande. Mir/uns fehlt jedenfalls jedes Verständnis für solche Maßnahmen. Eine Weiterleitung dieses Postings geht per Mail an den Autor von UKAW, aber es sollte mich wundern, wenn jetzt plötzlich eine Reaktion käme, denn es ist nicht das erste Mal, daß dieses Thema angesprochen wird. Bisher konnte mal vielleicht noch sagen, daß es nur um Header-"Kosmetik" ging, jetzt aber geht es um einen durch UKAW verursachten Verlust an technischer Funktionalität. Michael ------------------------------------------------------------------------ FreeXP Support-Mailingliste Support-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/support-list