Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Off topic - "Quelltext" eines Usenet-Postings, Message-ID und Header (Was: Ja, Datenschutz)

0 views
Skip to first unread message

Peter J. Holzer

unread,
Jan 3, 2024, 7:25:22 AM1/3/24
to
On 2024-01-03 11:02, Helmut Richter <hr.u...@email.de> wrote:
> [ Followup-To: poster
> bei Weiterführung der Diskussion bitte geeignete Newsgruppe wählen ]

[Ich nehme de.comm.software.newsreader. Ist zwar nicht ganz passend, aber
die Alternative wäre IMHO de.comm.protocols.misc und das erscheint mir
zu allgemein.]


> On Wed, 3 Jan 2024, Stefan Schmitz wrote:
>
> [ hier die Header dieses Beitrags ]
>
>> Path:
>> uni-berlin.de!fu-berlin.de!eternal-september.org!feeder3.eternal-september
>> .org!news.eternal-september.org!ss32.dont-email.me!.POSTED!not-for-mail
[...]
>> Message-ID: <un3ccl$35mg5$1...@ss32.dont-email.me>
>> References: <6560B851...@hrz.tu-chemnitz.de>
>> <uk2orh$3slp3$3...@dont-email.me> <ukas5n$1gn0p$1...@dont-email.me>
>> <ukvbjf$1pgl6$2...@dont-email.me> <ul98n5$3js51$1...@dont-email.me>
>> <ula9k4$3ot03$2...@dont-email.me> <kgtm4k-...@nntp.haselbeck-net.de>
>> <um4meq$1m7c3$1...@dont-email.me> <lhch5k-...@nntp.haselbeck-net.de>
>> <umf7d8$3iuia$1...@dont-email.me>
>> <slrnuomclu.3s...@trintignant.hjp.at>
>> <kv0s1q...@mid.individual.net>
>> <slrnuomft1.48...@trintignant.hjp.at>
>> <kv11kc...@mid.individual.net> <umk14l$dh0l$2...@dont-email.me>
>> <un249o$ntk0$1...@solani.org>
[...]
>> User-Agent: Mozilla Thunderbird
>> Cancel-Lock: sha1:JwH4juz6uetNASrt+ZRCoHLmXaM=
>> In-Reply-To: <un249o$ntk0$1...@solani.org>
>
> Und der Inhalt:
>
>> Am 02.01.2024 um 23:57 schrieb Ulrich D i e z:
>> > Der "Path:", die "Verschickungskette" eines Postings, wird also
>> > von den Peering-Servern von vorne her ergänzt.
>> >
>> > Die "References:", also die "Beantwortungskette" eines Postings,
>> > werden von den zum Postingschreiben verwendeten Clients durch
>> > hinten Anfügen verlängert.
>
> Die Preisfrage ist, ob man beim Anfügen zwingend das Ende nehmen *muss*
> oder ob die Liste als (ungeordnete) Menge definiert ist, so dass jede
> Umordnung erlaubt *wäre*, bin ich zu faul zum Raussuchen.

RFC 5537, s. 3.4.4:

| The content of the new article's References header field MUST be
| formed from the content of the parent's References header field if
| present, followed by the content of the Message-ID header field of
| the parent. If the parent had a References header, FWS as defined in
| [RFC5536] MUST be added between its content and the Message-ID header
| field content.

Also ja, man muss hinten anfügen. Man darf/muss Referenzen rauslöschen, wenn
der Inhalt zu lang würde:

| If the resulting References header field would, after unfolding,
| exceed 998 characters in length (including its field name but not the
| final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
| Trimming means removing any number of message identifiers from its
| content, except that the first message identifier and the last two
| MUST NOT be removed.

Aber die Reihenfolge muss erhalten bleiben:

| An essential property of the References header field, guaranteed by
| the above procedure and REQUIRED to be maintained by any extensions
| to this protocol, is that an article MUST NOT precede one of its
| parents.


>> Warum ist das eigentlich so?
>
> Jetzt ist es so, und wenn man das ändern würde, müsste man nicht nur alle
> auf Servern und privaten Dateien weltweit rumgeisternden Newsbeiträge
> ändern, sondern auch alle Software, die von der Reihenfolge dieser
> Einträge – zu Recht oder in unberechtigtem Vertrauen auf die
> Gepflogenheiten – Gebrauch macht.

ACK.


>> Umgekehrt fände ich es aus Nutzersicht sinnvoller. Dann würde man direkt
>> am Anfang der jeweiligen Kette sehen, von welchem Server das Posting
>> stammt bzw. welches die unmittelbar vorausgehenden Beiträge waren.
>
> Der unmittelbar vorausgehende Beitrag steht ja unter "In-Reply-To:". Es
> geht also nur um ältere Beiträge aus dem Thread.

In-Reply-To ist aber kein Usenet-Header, sondern ein E-Mail-Header.
Thunderbird fügt den ein, weil es ein kombinierter MUA/NUA ist, aber
andere Newsreader müssen den weder erzeugen noch verstehen.

hp
0 new messages