[X-Post nach de.test und dcsn]

On Fri, 22 Mar 2024 18:13:14 Alfred Peters wrote:
> Es schrieb einmal Stefan Claas:
>> So, noch eine M-ID, auf Deutsch. :-D

> Ich will auch mal... 😈

Grundgütiger.

Man kann sich ja spielen, wenn man lustig ist, aber so ganz
unvorbereitet und ohne Kontext habe ich jetzt eine knappe Stunde
gebraucht, bis mir klar geworden ist, weshalb genau Dein Posting
hier alles zum Absturz gebracht hat. Man darf sich im Header mit
Mime-Encodings spielen, wie man lustig ist, *aber* das, was am Ende
herauskommt, muss immer noch eine gültige Msg-Id sein.

RFC5536 meint dazu:

#v+
message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF

msg-id = "<" msg-id-core ">"
; maximum length is 250 octets

msg-id-core = id-left "@" id-right

id-left = dot-atom-text

dot-atom-text = <see RFC 5322 Section 3.2.3>
#v-

Und in RFC 5322 steht wiederum:

#v+
dot-atom-text = 1*atext *("." 1*atext)

atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
#v-

Die Spielereien in diesem Thread waren also bereits für die Umlaute
in den vorhergehenden Postings nicht zulässig, bloß ist es mir da
noch nicht aufgefallen. Hier jedoch steht:

#v+
Message-ID: <=?UTF-8?b?ZGV2aWNlAA==?=@geekmail.de>
#v-

Und das wiederum ergibt:

#v+
sfroehli:~$ echo ZGV2aWNlAA== | base64 -d | hexdump
0000000 6564 6976 6563 0000
0000007
#v-

....abschließende NULL-Bytes. Nicht gut, gar nicht gut. Sollte
derartiges nicht im Grund genommen bereits beim Posten vom Server
abgelehnt werden?

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - Als ob man dies immer wieder durchkauen müßte!
(Sloganizer)

Stefan Froehlich in de.test,de.comm.software.newsserver:

>#v+
>Message-ID: <=?UTF-8?b?ZGV2aWNlAA==?=@geekmail.de>
>#v-
>
>Und das wiederum ergibt:
>
>#v+
>sfroehli:~$ echo ZGV2aWNlAA== | base64 -d | hexdump
>0000000 6564 6976 6563 0000
>0000007
>#v-
>
>...abschließende NULL-Bytes. Nicht gut, gar nicht gut.

Das liegt aber an der Dekodierung.

Laut RFC2047 dürfen "encoded-words" in der Message-ID nicht
vorkommen, siehe Posting von Michael:

<news:AABl-p6v918AAAuq.A3.flnews@Server4.micha.freeshell.org>

Ich lese das so, daß man in der Headerzeile nicht MIME-
dekodieren darf.

> Sollte
>derartiges nicht im Grund genommen bereits beim Posten vom Server
>abgelehnt werden?

Das ist vermutlich eher eine Sache für den Client.

Marcel

[fup2 gesetzt]
--
│ ╭─────╮ ╭──────────╮ ..35..╭─────╮ ╭─────╮ ╭─╮
╰─╮ │ ╰──╮ ╰────╮ ╭──╯ ..35..╰───╮ │ ╭──╯ ╭──╯ ╭─╯ ╰─╮
╰───╯ ╭─────╯ ╭─────╯ ╰─╮ ╭──╮ ╭──╯ │ ╰─╮ ╰─╮ ╭──╯ ╭──╯
╰─────────╯ ..25..╰───╯ ╰───╯ ╰────╯ ╰─╯ ╰──────

Stefan Froehlich in de.test,de.comm.software.newsserver:

>#v+
>Message-ID: <=?UTF-8?b?ZGV2aWNlAA==?=@geekmail.de>
>#v-
>
>Und das wiederum ergibt:
>
>#v+
>sfroehli:~$ echo ZGV2aWNlAA== | base64 -d | hexdump
>0000000 6564 6976 6563 0000
>0000007
>#v-
>
>...abschließende NULL-Bytes. Nicht gut, gar nicht gut.

Das liegt aber an der Dekodierung.

Laut RFC2047 dürfen "encoded-words" in der Message-ID nicht
vorkommen, siehe Posting von Michael:

<news:AABl-p6v918AAAuq.A3.flnews@Server4.micha.freeshell.org>

Ich lese das so, daß man in der Headerzeile "Message-ID"
nicht MIME-dekodieren darf.

> Sollte
>derartiges nicht im Grund genommen bereits beim Posten vom Server
>abgelehnt werden?

Das ist vermutlich eher eine Sache für den Client.

Marcel

[fup2 gesetzt]
[supersedes]
--
╭───╮ ╭───╮ ╭───╮ ╭───╮ ╭─╮ ╭───╮ ..56..╭─╮ ╭───
╮ │ ╰─╯ ╰──╮ ╭────╯ │ ╭──╯ ╰──╯ │ ╰─╮ ╰──╮ ╭────╯ ╰──╮ │
│ ╰──╮ ..11..╰───╯ ╭───╯ │ ╭────────╯ ╭─╯ ╭─╯ ╰──────╮ ╰─╯
╰─────╯ ╰─────╯ ╰───────────╯ ╰───────────╯ ..67..

Stefan Froehlich <Stefan+Usenet@froehlich.priv.at> wrote:
| User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-13-amd64 (x86_64))
[...]
> hier alles zum Absturz gebracht hat. Man darf sich im Header mit
> Mime-Encodings spielen, wie man lustig ist, *aber* das, was am Ende
> herauskommt, muss immer noch eine gültige Msg-Id sein.
[...]
> #v+
> Message-ID: <=?UTF-8?b?ZGV2aWNlAA==?=@geekmail.de>
> #v-
>
> Und das wiederum ergibt:
>
> #v+
> sfroehli:~$ echo ZGV2aWNlAA== | base64 -d | hexdump
> 0000000 6564 6976 6563 0000
> 0000007
> #v-

tin will das dekodieren? eher nicht (extra nochmal nen 2.6.2er in gebaut).
wenn das wirklich tin war haette ich gern nen backtrace. danke.

In de.comm.software.newsserver Urs Janßen <urs@akk.org> wrote:
> Stefan Froehlich <Stefan+Usenet@froehlich.priv.at> wrote:
> | User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-13-amd64 (x86_64))
> [...]
>> hier alles zum Absturz gebracht hat. [...]

> tin will das dekodieren? eher nicht (extra nochmal nen 2.6.2er in
> gebaut).

Oje, *das* wollte ich mit meinen Posting nicht verursachen
(ansonsten hätte ich es auch nach Newsreader gepostet und den tin
erwähnt), sorry!

Nein, mein Archiv schickt die Postings in eine Postgres-Procedure,
in wiederum ein Perl-Skript aufgerufen wird, das u.a.

#v+
$head = decode('MIME-Header', $part->__head->as_string);
#v-

enthält, und in $head sind dann die NULL-Bytes enthalten (das, und
der eher spartanische Output von Postgres macht die Fehlersuche
nicht einfacher). Angesichts des von Marcel referenzierten Postings
von Michael Bäuerle ist sollte Perl diesen Teilstring im Grund
genommen gar nicht decodieren. Ich hoffe (und erwarte) einmal, dass
diese Marotte nicht um sich greift, sonst müsste ich die Decodierung
am Ende selber implementieren, Encode::MIME::Header wird sich da
vmtl. eher nicht anpassen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so zerrissen wie das Lachen.
(Sloganizer)