Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > de.comp.misc > #747

Content-Transfer-Encoding: quoted-printable (was: [TB 91.12] noch einmal CTE)

Cross-posted to 2 groups.

Followups directed to: de.comp.misc

Show all headers | View raw

Thomas Barghahn <Th.Barghahn@t-online.de>:
>*Helmut Waitzmann* meinte:
>>Thomas Barghahn <Th.Barghahn@t-online.de>:
>
>[...]

Eine Vorbemerkung für Leute, die jetzt neu in die Diskussion 
einsteigen:  Es geht um die Transport‐Kodierung «Quoted-Printable» 
bei E‐Mail‐Nachrichten und das Nachrichtenvorspann‐Feld 
«Content-Transfer-Encoding» (CTE):

>>>bei der Übertragung von Mail wird A: CTE von 8bit auf qp 
>>>nachweislich geändert, wodurch dann B: der Sig-Trenner zerstört 
>>>wird! *DAS ist /das/ Problem*!
>
>>Nein.  Nicht DAS ist das Problem. 
>>

[…]

>>Der Sig‐Trenner wird nicht erst beim Umkodieren in 
>>Quoted‐Printable‐Transportkodierung zerstört, sondern vorher:
>
>>GMX geht mutmaßlich so vor:  Beim Empfang der Nachricht wirft GMX 
>>erst mal allen Leerraum an allen Zeilenenden weg.
>
>>Dann erst schaut GMX sich an, ob die Nachricht 
>>quoted‐printable‐transportkodiert daherkommt.  Wenn sie bereits 
>>quoted‐printable‐transportkodiert ist, nimmt GMX keine Umkodierung 
>>mehr an ihr vor.
>
>Betrachten wir hier einmal deine beiden letzten Absätze: 
>
>
>Ich denke, dass /zuersz/ geschaut wird, ob eine e-Mail qp-kodiert 
>ist. Dieses lässt sich auch nachvollziehen, denn Leerzeichen am 
>Ende von Zeilen einer qp-kodierten e-Mail, jene bleiben 
>nachweislich erhalten!

In qp‐transportkodierten Nachrichten gibt es (von Haus aus) keine 
Zeilen mit Leerzeichen am Ende.  Das ist eine Eigenschaft der 
QP‐Transportkodierung, beschrieben in 
<https://datatracker.ietf.org/doc/html/rfc2045#section-6.7>.

Sollten doch Leerzeichen an Zeilenenden zu finden sein, sind die auf 
andere Weise nachträglich da hingekommen und müssen vor dem 
QP‐Dekodieren entfernt werden.

Beispiel:

Wenn mein Mailerprogramm eine Nachricht, die einen Signaturtrenner 
(eine Zeile bestehend aus zwei Minuszeichen und einem Leerzeichen 
am Zeilenende) enthält, vor dem Versand qp‐transportkodiert, kodiert 
es den Signaturtrenner so:

   =2D-=20

Dadurch befindet sich am Ende der Zeile kein Leerzeichen mehr 
sondern eine Null. 

(Es mag noch andere Möglichkeiten geben, den Signaturtrenner gemäß 
der QP‐Transportkodierung zu kodieren, beispielsweise ist auch

   =2D=2D=20

korrekt.  Aber allen ist gemeinsam, dass sie keine Leerzeichen am 
Zeilenende stehen lassen.)

=> Selbst wenn GMX versucht, alle Leerzeichen an Zeilenenden zu 
entfernen, richtet es damit bei qp‐transportkodierten Nachrichten 
keinen Schaden an.

>denn Leerzeichen am Ende von Zeilen einer qp-kodierten e-Mail, jene 
>bleiben nachweislich erhalten!

Du hast wirklich eine qp‐transportkodierte Nachricht, die in ihrer 
qp‐transportkodierten Form an Zeilenenden Leerzeichen hat, gesehen?

Es kann in der Tat passieren, dass eine qp‐transportkodierte 
Nachricht im Laufe ihres Wegs vom Sender zum Empfänger an Zeilen 
Leerzeichen angehängt bekommt (beispielsweise dann, wenn sie bei 
Systemen vorbeikommt, die Textdateien – also auch 
E‐Mail‐Nachrichten – mit Leerzeichen an Zeilenenden auffüllen, siehe 
das Wikipedia‐Lemma «Textdatei», 
<https://de.wikipedia.org/wiki/Textdatei#Festlegung_einer_konstanten_Zeilenl%C3%A4nge>).

Weil die QP‐Transportkodierung so entworfen wurde (s. o.), dass 
qp‐transportkodierte Zeilen von Haus aus keine Leerzeichen am 
Zeilenende haben, bedeutet jedes Leerzeichen am Ende einer 
qp‐transportkodierten Zeile, dass es nachträglich dorthin gekommen 
sein muss und da nicht hingehört.  Deshalb ist es für die 
QP‐Dekodierung ausdrücklich vorgeschrieben, dass beim Dekodieren als 
erster Schritt alle Leerzeichen an Zeilenenden entfernt werden 
müssen.

=> Eine qp‐transportkodierte Nachricht ist robust gegenüber 
willkürlichem Anhängen von Leerzeichen an Zeilenenden.

Die genauen Kodier‐ und Dekodierregeln der QP‐Transportkodierung 
sind in RFC 2045 
(<https://datatracker.ietf.org/doc/html/rfc2045#section-6.7>) 
beschrieben.

Wenn wir die Eigenschaften der Quoted‐Printable‐Transportkodierung 
weiterdiskutieren wollen – finde ich –, sollten wir woanders hin 
umziehen.  Mein Vorschlag wäre «de.comp.misc».  Ich mach' mal einen 
entsprechenden Crosspost mit Followup-To.  (Falls eines der 
Mitdiskutierenden anderer Meinung ist, ignoriere es das bitte und 
mache seinerseits gegebenenfalls einen Crosspost mit entsprechendem 
Followup-To.)

Back to de.comp.misc | Previous | Next | Find similar

Thread

Content-Transfer-Encoding: quoted-printable (was: [TB 91.12] noch einmal CTE) Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-08-13 19:49 +0200

csiph-web