Zeilenumbruch bei quoted-printable [erl.]

seba · Jan 18th 2011

Thunderbird-Version: 3.1.7, IMAP, Ubuntu 10.10

Ich versende immer ausschließlich Textmails mit folgenden Einstellungen:

Code

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Gestern habe ich nun eine Antwortmail mit folgendem Quelltext erhalten:

Code

Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: xxx
Content-Language: de
X-Null-Tag: xxx
X-UniMR-MailScanner-Information: see http://www.uni-xxx
X-UniMR-MailScanner: Found to be clean
X-MailScanner-From: xxx




Sehr geehrter,




vielen Dank f=C3=BCr Ihren Hinweis. Der Problematik, die Fallgruppe der =
Ermessensreduzierung auf Null unter dem Gliederungspunkt "Fallgruppen =
m=C3=B6glicher Ermessensfehler" zu behandeln, bin ich mir seit der 1. =
Auflage bewusst.=20
Zum einen: Die Ermessensreduzierung auf Null als solche ist =
nat=C3=BCrlich kein Ermessensfehler. Gemeint ist offensichtlich, dass =
ein (Ermessens-)Fehler der Beh=C3=B6rde anzunehmen ist, wenn sie =
verkennt, dass ihr Ermessen auf Null reduziert ist und eine andere als =
die im konkreten Fall gebotene Handlung vornimmt.=20
In der n=C3=A4chsten Auflage werde ich Ihrer Anregung folgend die =
=C3=9Cberschrift wie folgt formulieren: "Missachtung einer =
Ermessensreduzierung auf Null". Freilich bleibt dann immer noch der =
Einwand, dass dann eigentlich gar kein Ermessensfehler der Beh=C3=B6rde =
vorliegt, weil ihr gar kein Ermessen zustand. Dennoch halte ich es =
f=C3=BCr gerechtfertigt, diesen m=C3=B6glichen Rechtsversto=C3=9F unter =
der =C3=9Cberschrift Ermessensfehler zu behandeln, weil es sich um einen =
Versto=C3=9F gegen eine Ermessensvorschrift handelt. =C3=9Cbrigens: Auch =
wenn ein Fall von Ermessens=C3=BCberschreitung vorliegt - Beh=C3=B6rde =
verlangt 100 =E2=82=AC, obwohl das Gesetz eine Obergrenze von 90 =
=E2=82=AC nennt -, hatte die Beh=C3=B6rde "ab 90 =E2=82=AC" gar kein =
Ermessen mehr. Dennoch wird selbstverst=C3=A4ndlich ein Ermessensfehler =
angenommen.=20




Mit freundlichen Gr=C3=BC=C3=9Fen

Display More

Das Problem ist nun, dass die Mail ohne Zeilenumbrüche angezeigt wird. Diese sind zwar im Quelltext vorhanden, das wird aber nicht beachtet. Die Zeilen laufen immer bis ans Ende des Fensters, was auf einem großen Monitor nicht gerade optimal ist. Wißt ihr, wo man einstellen kann, dass die Zeilenumbrüche immer so dargestellt werden wie im Quellext? Mit format=flowed hat dies glaube ich nichts zu tun, da die Mail dieses Attribut nicht enthält; format=flowed habe ich aber sowieso deaktiviert:

Code

mailnews.display.disable_format_flowed_support;true
mailnews.send_plaintext_flowed;false

Übrigens: Ich habe soeben auf diese quoted-printable-Mail geantwortet. Mein Antworttext wird zwar korrekt dargestellt, das Fullquote läuft im Quelltext aber ganz nach rechts (man muss also ewig scrollen):

Code

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit




Sehr geehrter Herr xxx,




vielen Dank für Ihre ausführliche Antwort. Mit der klarer gefassten
Überschrift ist nun eindeutig geklärt, wann eine Ermessensreduzierung
auf Null zu einem Ermessensfehler führt.




Mit freundlichen Grüßen
xxx







Am xx, schrieb xxx:
> Sehr geehrter xxx,
> 
> vielen Dank für Ihren Hinweis. Der Problematik, die Fallgruppe der Ermessensreduzierung auf Null unter dem Gliederungspunkt "Fallgruppen möglicher Ermessensfehler" zu behandeln, bin ich mir seit der 1. Auflage bewusst. 
> Zum einen: Die Ermessensreduzierung auf Null als solche ist natürlich kein Ermessensfehler. Gemeint ist offensichtlich, dass ein (Ermessens-)Fehler der Behörde anzunehmen ist, wenn sie verkennt, dass ihr Ermessen auf Null reduziert ist und eine andere als die im konkreten Fall gebotene Handlung vornimmt. 
> In der nächsten Auflage werde ich Ihrer Anregung folgend die Überschrift wie folgt formulieren: "Missachtung einer Ermessensreduzierung auf Null". Freilich bleibt dann immer noch der Einwand, dass dann eigentlich gar kein Ermessensfehler der Behörde vorliegt, weil ihr gar kein Ermessen zustand. Dennoch halte ich es für gerechtfertigt, diesen möglichen Rechtsverstoß unter der Überschrift Ermessensfehler zu behandeln, weil es sich um einen Verstoß gegen eine Ermessensvorschrift handelt. Übrigens: Auch wenn ein Fall von Ermessensüberschreitung vorliegt - Behörde verlangt 100 €, obwohl das Gesetz eine Obergrenze von 90 € nennt -, hatte die Behörde "ab 90 €" gar kein Ermessen mehr. Dennoch wird selbstverständlich ein Ermessensfehler angenommen. 
> 
> Mit freundlichen Grüßen
> xxx

Display More

Kann es sein, dass dies alles mit der Codierung "quoted-printable" zusammenhängt? Danke.

seba · Jan 18th 2011

Das Problem hat sich, glaube ich, geklärt. Ich hab den quoted-printable Quelltext falsch interpretiert. Das Gleichheitszeichen am Ende jeder Zeile (im Quelltext) markiert offensichtlich keinen harten Zeilenumbruch, sondern nur einen weichen.

Wenn ich das richtig verstehe, hat der Client des Absenders gar keine harten Zeilenumbrüche nach ca. 72 Zeichen eingefügt. Somit ist auch klar, dass die Zeilen immer erst am Ende meines Fensters umbrechen. Der "Fehler" liegt hier also offensichtlich beim Absender, oder?

mrb · Jan 18th 2011

Hallo,
wir hatten das Problem mit "weich" und "hart" schon mal, diesmal in Bezug auf Word.
Schwer einen Schuldigen auszumachen.

Quote

Der "Fehler" liegt hier also offensichtlich beim Absender, oder?

Sagen wir so: TB hadert mit MS.
Und da es keinen Standard für HTML in Mails gibt - falls dein Fall eine HTML-Mail ist, denn leider fehlen ein paar Deklarierungen im Quelltext - steht es unentschieden, mit einem kleinem Plus für TB, da MS schon immer auf Standards keine Rücksicht nimmt und für mich meistens die Ursache allen Übels ist - man denke nur an das erbärmliche RTF-Format, welches nicht einmal Outlook Express verstand.

So wie du die Umbrüche im Quelltext siehst, so wurden sie auch vom Versender gesetzt.
"Soft"-Umbrüche von TB würdest du gar nicht sehen, weil er kein Zeichen dafür verwendet. Braucht man auch nicht, denn der bricht nach 72 Zeichen um.
Wird im Quelltext nicht umgebrochen, entsteht dort sofort ein horizontaler Scrollbalken, der kann Kilometer lang sein
Hard-Umbrüche werden in HTML als

Code

<br>

gekennzeichnet.
In ReintextMails verzichtet TB auf jegwegliche Zeichen. Hardumbrüche erkennt man einfach daran, dass eine neue Zeile beginnt, ohne dass die Zeile davor 72 Zeichen erreicht hat.
Gruß

seba · Jan 18th 2011

Hallo,

bei der Mail des Absenders handelt es sich offenbar um eine Textmail (siehe Quelltext: text/plain).

Quote

So wie du die Umbrüche im Quelltext siehst, so wurden sie auch vom Versender gesetzt.

Aber wenn Wikipedia keinen Unsinn verzapft ;-), markiert das Gleichheitszeichen keinen harten Zeilenumbruch. Das = am Ende einer Zeile wird beim Decodieren ignoriert. Es ähnelt offenbar format=flowed und die entsprechende Zeile passt sich dem Fenster an. Einen harten (manuellen) Zeilenumbruch stellt das Zeichen =20 dar und dies wird von TB auch beachtet; nach diesem Zeichen wird also immer die Zeile umgebrochen.

Offenbar hat der Absender in seinem Outlook nicht eingestellt (ob das dort überhaupt möglich ist, weiß ich nicht), dass nach einer bestimmten Anzahl von Zeichen die Zeile automatisch (hart) umgebrochen werden soll.

muellerpaul · Jan 18th 2011

Hallo,

Quote from "seba"

Einen harten (manuellen) Zeilenumbruch stellt das Zeichen =20 dar und dies wird von TB auch beachtet

ich sehe das ähnlich - aber dorch irgendwie anders
TB setzt beim Verfassen mit quoted-printable und format=flowed beim weichen Umbrechen ein "=20" ans Zeilenende im Quelltext,
und ich hoffe das ist der Standard.
In der Mail des Outlook-Users ist zu sehen, dass Outlook sich nicht so recht entscheiden kann, ob nun format=flowed - oder auch
nicht - deklariert werden soll. Dies hat dann beim Antworten zu Verwirrungen seitens TB geführt, wenn die Zeilen des zitierten
Textes erst an dieser Stelle [=20] im Quelltext umbrechen.

Gruß
muellerpaul

seba · Jan 18th 2011

Danke. Wie schön wäre die E-Mail-Welt ohne MS

mrb · Jan 18th 2011

seba,
ich habe nie eines dieser Umbruchzeichen gesehen, aber ich empfange und sende nicht in flowed und so gut wie nie in quoted printable.

Quote

bei der Mail des Absenders handelt es sich offenbar um eine Textmail (siehe Quelltext: text/plain).

Man kann in einem Mailklienten wie TB auch einstellen, dass beide Formate gleichzeitig im Quelltext stehen "(Reintext und HTML"). Dann erscheinen die Deklarierungen getrennt.
Also

Code

Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
[Text in Reintext]

und

Code

Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
[HTML-Code mit dem gleichen Text]

Es hätte jetzt also sein können, dass trotzdem die Mail in HTML verfasst wurde.
Das war für mich nicht klar ersichtlich.
Ist aber auch egal, da - wie ich gerade sehe - TB sowieso nicht in quoted printable sendet und seit 3.0 das Menü zur Änderung fehlt (möglich ist es aber trotzdem).
Gruß

seba · Jan 18th 2011

mrb

Irgendwie reden wir aneinander vorbei. Wie ich in meinem ersten Post schrieb, sende ich ausschließlich Textmails mit utf-8. Darum geht es aber gar nicht :). Es geht darum, dass ich eine Mail empfangen habe, die mit Outlook 12 erstellt und mit quoted-printable kodiert worden ist. Dabei habe ich mich gewundert, warum die Zeilenumbrüche nicht richtig dargestellt werden. Es hat sich dann aber herausgestellt, dass das Problem beim Absender bzw. Outlook liegt ...