Discussion:
Fehlermeldung bei Senden
(zu alt für eine Antwort)
Michael Limburg
2018-12-14 18:01:40 UTC
Permalink
Hallo,

ich versuche, auf einen Artikel in de.comp.os.unix.linux.misc zu
Antworten. Der Post geht nicht raus. Der Newsserver (eternal-september)
gibt die Meldung zurueck: "Please check that you are not trying to post
to a read-only group".

Ich kann sehr wohl in die Gruppe posten, nur nicht auf genau diesen
Artikel antworten. Ich habe den Inhalt/Text auch schon in eine neue
Antwort verpackt. Geht trotzdem nicht. Am Inhalt kann's kaum liegen.
Denn nach de.test geht er raus.

Das einzig für mich auffällig ist, daß die Liste der References in
meinem knode derweil 23 Einträge in einer Zeile hat. In Artikel,
auf den ich antworten wollte, stehen die References jeweils in einer
eigenen Zeile untereinander (Claws-Mail). Prinipiell kann ich dem Autor
schon antworten, nur zu dem Artikel nicht.
Gibt's da vielleicht irgendwelche Beschränkungen? Oder woran liegt's?

MfG
Marcel Logen
2018-12-14 18:10:05 UTC
Permalink
Post by Michael Limburg
Ich kann sehr wohl in die Gruppe posten, nur nicht auf genau diesen
Artikel antworten. Ich habe den Inhalt/Text auch schon in eine neue
Antwort verpackt. Geht trotzdem nicht. Am Inhalt kann's kaum liegen.
Denn nach de.test geht er raus.
Das einzig für mich auffällig ist, daß die Liste der References in
meinem knode derweil 23 Einträge in einer Zeile hat. In Artikel,
[...]

Ich vermute, die References-Zeile ist zu lang (>998 Zeichen).

KNode hatte IIRC lange Zeit ein Problem damit, bis AFAIK Michael
Bäuerle einen Patch dafür geschrieben hat.

Marcel
--
+--+ +-------+ +--+ +--+ +-+ +----+
+ +-+ +--+ +-----+ +----+ +---+ +---+ +--+ +-+ +--+ +--+ +---
+--+ +-+ +----------+ +---+ +-+ +-+ +-------+
+-------------+ +----+
Michael Limburg
2018-12-14 18:15:09 UTC
Permalink
Post by Marcel Logen
Post by Michael Limburg
Ich kann sehr wohl in die Gruppe posten, nur nicht auf genau diesen
Artikel antworten. Ich habe den Inhalt/Text auch schon in eine neue
Antwort verpackt. Geht trotzdem nicht. Am Inhalt kann's kaum liegen.
Denn nach de.test geht er raus.
Das einzig für mich auffällig ist, daß die Liste der References in
meinem knode derweil 23 Einträge in einer Zeile hat. In Artikel,
[...]
Ich vermute, die References-Zeile ist zu lang (>998 Zeichen).
Danke, werde ich mal prüfen. Ich hatte den Header hier nicht gepostet,
weil in der MID der volle Name des Posters vorkommt. Den hätte ich
halt vorher erst mal fragen wollen.
Post by Marcel Logen
KNode hatte IIRC lange Zeit ein Problem damit, bis AFAIK Michael
Bäuerle einen Patch dafür geschrieben hat.
Ah, OK, mal schauen.

MfG
Michael Limburg
2018-12-14 18:22:23 UTC
Permalink
Post by Marcel Logen
Post by Michael Limburg
Das einzig für mich auffällig ist, daß die Liste der References in
meinem knode derweil 23 Einträge in einer Zeile hat. In Artikel,
[...]
Ich vermute, die References-Zeile ist zu lang (>998 Zeichen).
Tatsächlich, ist so. Was macht man da? Mal abgesehen von dem Patch.
Einfach den ältesten Eintrag rauslöschen. Oder reicht schon
umbrechen?

MfG
Michael Bäuerle
2018-12-14 18:47:07 UTC
Permalink
Post by Michael Limburg
Post by Marcel Logen
Post by Michael Limburg
Das einzig für mich auffällig ist, daß die Liste der References in
meinem knode derweil 23 Einträge in einer Zeile hat. In Artikel,
[...]
Ich vermute, die References-Zeile ist zu lang (>998 Zeichen).
Tatsächlich, ist so. Was macht man da? Mal abgesehen von dem Patch.
Einfach den ältesten Eintrag rauslöschen. Oder reicht schon
umbrechen?
Umbrechen reicht nicht, die Längenbeschränkung gilt für den ungefalteten
Zustand.

Den ältesten Eintrag löschen ist auch verboten. Zitat aus RFC 5537:
|
| 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.

Du darfst beliebig viele Einträge in der Mitte entfernen. Stehenbleiben
müssen der älteste und die neuesten zwei Einträge.


_____________
[1] <https://tools.ietf.org/html/rfc5537#section-3.4.4>
Sven Hartge
2018-12-14 18:55:44 UTC
Permalink
Post by Michael Bäuerle
Post by Michael Limburg
Post by Marcel Logen
Ich vermute, die References-Zeile ist zu lang (>998 Zeichen).
Tatsächlich, ist so. Was macht man da? Mal abgesehen von dem Patch.
Einfach den ältesten Eintrag rauslöschen. Oder reicht schon
umbrechen?
Umbrechen reicht nicht, die Längenbeschränkung gilt für den
ungefalteten Zustand.
Sicher? In RFC5536 2.2 steht explizit:

,----
| Compliant software MUST NOT generate (but MAY accept) header field
| lines of more than 998 octets. This is the only limit on the
| length of a header field line prescribed by this standard.
`----

Wichtig ist hier die Betonung von "header field lines", denn:

,----
| NOTE: As stated in [RFC5322], there is NO restriction on the
| number of lines into which a header field may be split, and
| hence there is NO restriction on the total length of a header
| field (in particular it may, by suitable folding, be made to
| exceed the 998-octet restriction pertaining to a single header
| field line).
`----

Durch line splitting kann man praktisch ein unbegrenzte Länge von
Headern erreichen.

S!
--
Sigmentation fault. Core dumped.
Marcel Logen
2018-12-14 20:46:27 UTC
Permalink
[References-Zeile zu lang]
Post by Sven Hartge
Post by Michael Bäuerle
Umbrechen reicht nicht, die Längenbeschränkung gilt für den
ungefalteten Zustand.
,----
| Compliant software MUST NOT generate (but MAY accept) header field
| lines of more than 998 octets. This is the only limit on the
| length of a header field line prescribed by this standard.
`----
,----
| NOTE: As stated in [RFC5322], there is NO restriction on the
| number of lines into which a header field may be split, and
| hence there is NO restriction on the total length of a header
| field (in particular it may, by suitable folding, be made to
| exceed the 998-octet restriction pertaining to a single header
| field line).
`----
Durch line splitting kann man praktisch ein unbegrenzte Länge von
Headern erreichen.
Hätte ich jetzt auch gedacht, aber RFC5537 sagt in 3.4.4.
"Construction of the References Header Field":

| 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).

Da scheint es wohl eine Ausnahme für die References zu geben.

Marcel
--
+------+ +---------+ +---+ +-+
+----+ +-+ +---+ +-----+ +--+ +-+ +-------+
+ +-+ +--+ +-+ +-+ +--+ +---+ +-----+ +-----+ +------------+ +--+
+-+ +--+ +----+ +-+ +-+ +--------+ +--------------+ +
Sven Hartge
2018-12-14 20:54:54 UTC
Permalink
Post by Marcel Logen
[References-Zeile zu lang]
Post by Sven Hartge
Post by Michael Bäuerle
Umbrechen reicht nicht, die Längenbeschränkung gilt für den
ungefalteten Zustand.
,----
| Compliant software MUST NOT generate (but MAY accept) header field
| lines of more than 998 octets. This is the only limit on the
| length of a header field line prescribed by this standard.
`----
,----
| NOTE: As stated in [RFC5322], there is NO restriction on the
| number of lines into which a header field may be split, and
| hence there is NO restriction on the total length of a header
| field (in particular it may, by suitable folding, be made to
| exceed the 998-octet restriction pertaining to a single header
| field line).
`----
Durch line splitting kann man praktisch ein unbegrenzte Länge von
Headern erreichen.
Hätte ich jetzt auch gedacht, aber RFC5537 sagt in 3.4.4.
| 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).
Da scheint es wohl eine Ausnahme für die References zu geben.
Ja, definitiv. Interessant, dass dies in 5537 und nicht auch schon in
5536 steht.

S!
--
Sigmentation fault. Core dumped.
Michael Bäuerle
2018-12-15 12:51:38 UTC
Permalink
Post by Sven Hartge
Post by Marcel Logen
[References-Zeile zu lang]
Post by Sven Hartge
Post by Michael Bäuerle
Umbrechen reicht nicht, die Längenbeschränkung gilt für den
ungefalteten Zustand.
,----
| Compliant software MUST NOT generate (but MAY accept) header field
| lines of more than 998 octets. This is the only limit on the
| length of a header field line prescribed by this standard.
`----
,----
| NOTE: As stated in [RFC5322], there is NO restriction on the
| number of lines into which a header field may be split, and
| hence there is NO restriction on the total length of a header
| field (in particular it may, by suitable folding, be made to
| exceed the 998-octet restriction pertaining to a single header
| field line).
`----
Durch line splitting kann man praktisch ein unbegrenzte Länge von
Headern erreichen.
Hätte ich jetzt auch gedacht, aber RFC5537 sagt in 3.4.4.
| 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).
Da scheint es wohl eine Ausnahme für die References zu geben.
Es war offenbar ausdrücklich gewünscht, dass die References immer auch
einzeilig darstellbar sind (obwohl sie gefaltet werden dürfen).
Post by Sven Hartge
Ja, definitiv. Interessant, dass dies in 5537 und nicht auch schon in
5536 steht.
Da beide RFCs gleich alt sind, hätte man in RFC 5536 zumindest eine
Referenz auf RFC 5537 Kapitel 3.4.4 einfügen können.

Juergen Ilse
2018-12-15 08:04:57 UTC
Permalink
Hallo,
Post by Michael Limburg
Post by Marcel Logen
Post by Michael Limburg
Das einzig für mich auffällig ist, daß die Liste der References in
meinem knode derweil 23 Einträge in einer Zeile hat. In Artikel,
[...]
Ich vermute, die References-Zeile ist zu lang (>998 Zeichen).
Tatsächlich, ist so. Was macht man da? Mal abgesehen von dem Patch.
Einfach den ältesten Eintrag rauslöschen. Oder reicht schon
umbrechen?
Den aeltesten Eintrag (der ja normalerweise den Threadanfang markiert)
drin lassen und einen anderen aelteren Eintrag entfernen waere AFAIK
die korrekte Vorgehensweise ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Michael Bäuerle
2018-12-14 18:21:02 UTC
Permalink
Post by Michael Limburg
ich versuche, auf einen Artikel in de.comp.os.unix.linux.misc zu
Antworten. Der Post geht nicht raus. Der Newsserver (eternal-september)
gibt die Meldung zurueck: "Please check that you are not trying to post
to a read-only group".
Ich kann sehr wohl in die Gruppe posten, nur nicht auf genau diesen
Artikel antworten. Ich habe den Inhalt/Text auch schon in eine neue
Antwort verpackt. Geht trotzdem nicht. Am Inhalt kann's kaum liegen.
Denn nach de.test geht er raus.
Das einzig für mich auffällig ist, daß die Liste der References in
meinem knode derweil 23 Einträge in einer Zeile hat. In Artikel,
auf den ich antworten wollte, stehen die References jeweils in einer
eigenen Zeile untereinander (Claws-Mail). Prinipiell kann ich dem Autor
schon antworten, nur zu dem Artikel nicht.
Gibt's da vielleicht irgendwelche Beschränkungen? Oder woran liegt's?
Das References Feld hat eine Längenbeschränkung und zwar so, dass es
als eine Zeile darstellbar sein muss (1000 Zeichen bzw. 998 plus CRLF).
Das ist in RFC 5537 [1] definiert.

KNode trimmt die References nicht korrekt, wenn sie zu lang werden.
Das ist ein bekannter Bug. Ich habe vor ein paar Jahren mal einen Patch
dafür geschrieben [2], außer SuSE hat den aber IIRC niemand mehr auf-
genommen (da war die Entwicklung von KNode bereits eingestellt).


____________
[1] <https://tools.ietf.org/html/rfc5537#section-3.4.4>
[2] <http://micha.freeshell.org/tmp/knode-4.14.10_RefTrim.patch>
Michael Limburg
2018-12-14 18:31:03 UTC
Permalink
Michael Bäuerle wrote:

Hallo
Post by Michael Bäuerle
KNode trimmt die References nicht korrekt, wenn sie zu lang werden.
Das ist ein bekannter Bug. Ich habe vor ein paar Jahren mal einen Patch
dafür geschrieben [2], außer SuSE hat den aber IIRC niemand mehr auf-
genommen (da war die Entwicklung von KNode bereits eingestellt).
Danke, werde ich mir alles mal anschauen.

MfG
Loading...