[INN] Aufbau der Message-ID

[Stefan+ (Stefan Froehlich)]

[X-Post nach de.test und dcsn]

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

[Marcel Logen]

Post by Stefan+ (Stefan Froehlich)
#v+
#v-
#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-***@Server4.micha.freeshell.org>

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

Post by Stefan+ (Stefan Froehlich)
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]

[Marcel Logen]

Post by Stefan+ (Stefan Froehlich)
#v+
#v-
#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-***@Server4.micha.freeshell.org>

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

Post by Stefan+ (Stefan Froehlich)
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]

[Urs Janßen]

Stefan Froehlich <Stefan+***@froehlich.priv.at> wrote:
| User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-13-amd64 (x86_64))
[...]

Post by Stefan+ (Stefan Froehlich)
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.

[...]

Post by Stefan+ (Stefan Froehlich)
#v+
#v-
#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.

[Stefan+ (Stefan Froehlich)]

Post by Urs Janßen
| 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