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

Antwort per Email an