info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [flnews] Unkonventionelle Date-Headerzeile
0 views
Skip to first unread message
Michael Bäuerle
Nov 10, 2023, 11:08:05 AM11/10/23
to
Urs Janßen wrote:
> Michael Bäuerle wrote:
> >
Mehr Kontext wegen Xpost: Es ging um folgenden Artikel:
<news:f43c64a6446b0325...@maerchenland.de>
(Message-ID: <f43c64a6446b0325...@maerchenland.de>)
flnews konnte das Datum aus diesem Artikel nicht korrekt extrahieren
(wegen der Faltung am Ende).
> > und in Kapitel 3.3:
> > <https://datatracker.ietf.org/doc/html/rfc5322#section-3.3>
> > |
> > | date-time = [ day-of-week "," ] date time [CFWS]
> > ^^^^
> > Für Mail wäre das demnach auch zulässig.
>
> https://www.rfc-editor.org/errata/eid3088
> hast du gesehen?
Nein, dieses Erratum hatte ich übersehen. Danke für den Hinweis.
Beim Erratum 3088 steht allerdings dabei:
|
| Status: Rejected
Die von mir zitierte Syntax sollte also noch gültig sein.
Der zitierte Text im Erratum 3088 aus Kapitel 3.2.2:
<https://www.rfc-editor.org/rfc/rfc5322#section-3.2.2>
|
| [...]
| However, where CFWS occurs in this specification, it MUST NOT
| be inserted in such a way that any line of a folded header field is
| made up entirely of WSP characters and nothing else.
besagt aber, dass man so etwas nicht erstellen (versenden) darf, auch
wenn die Syntax passen würde.
Außerdem ist auch noch die "obsolete syntax" zu beachten, die man
nicht mehr versenden darf, die ein Parser aber verstehen muss:
<https://www.rfc-editor.org/rfc/rfc5322#section-4.2>
|
| In the obsolete syntax, any amount of folding white space MAY be
| inserted where the obs-FWS rule is allowed. This creates the
| possibility of having two consecutive "folds" in a line, and
| therefore the possibility that a line which makes up a folded header
| field could be composed entirely of white space.
|
| obs-FWS = 1*WSP *(CRLF 1*WSP)
Die wird in Kapitel 3.2.2 verwendet:
<https://www.rfc-editor.org/rfc/rfc5322#section-3.2.2>
|
| FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
| [...]
| CFWS = (1*([FWS] comment) [FWS]) / FWS
Für ein Mailprogramm müsste das also in Empfangsrichtung funktionieren,
selbst für FWS (nicht nur für CFWS).
Daran sollte auch Erratum 1908 nichts ändern:
<https://www.rfc-editor.org/errata/eid1908>
Das ist komplizierter als ich vermutet hatte, daher Xpost und Fup2 nach
<news:de.comm.software.newsreader>.
> Michael Bäuerle wrote:
> >
Mehr Kontext wegen Xpost: Es ging um folgenden Artikel:
<news:f43c64a6446b0325...@maerchenland.de>
(Message-ID: <f43c64a6446b0325...@maerchenland.de>)
flnews konnte das Datum aus diesem Artikel nicht korrekt extrahieren
(wegen der Faltung am Ende).
> > und in Kapitel 3.3:
> > <https://datatracker.ietf.org/doc/html/rfc5322#section-3.3>
> > |
> > | date-time = [ day-of-week "," ] date time [CFWS]
> > ^^^^
> > Für Mail wäre das demnach auch zulässig.
>
> https://www.rfc-editor.org/errata/eid3088
> hast du gesehen?
Nein, dieses Erratum hatte ich übersehen. Danke für den Hinweis.
Beim Erratum 3088 steht allerdings dabei:
|
| Status: Rejected
Die von mir zitierte Syntax sollte also noch gültig sein.
Der zitierte Text im Erratum 3088 aus Kapitel 3.2.2:
<https://www.rfc-editor.org/rfc/rfc5322#section-3.2.2>
|
| [...]
| However, where CFWS occurs in this specification, it MUST NOT
| be inserted in such a way that any line of a folded header field is
| made up entirely of WSP characters and nothing else.
besagt aber, dass man so etwas nicht erstellen (versenden) darf, auch
wenn die Syntax passen würde.
Außerdem ist auch noch die "obsolete syntax" zu beachten, die man
nicht mehr versenden darf, die ein Parser aber verstehen muss:
<https://www.rfc-editor.org/rfc/rfc5322#section-4.2>
|
| In the obsolete syntax, any amount of folding white space MAY be
| inserted where the obs-FWS rule is allowed. This creates the
| possibility of having two consecutive "folds" in a line, and
| therefore the possibility that a line which makes up a folded header
| field could be composed entirely of white space.
|
| obs-FWS = 1*WSP *(CRLF 1*WSP)
Die wird in Kapitel 3.2.2 verwendet:
<https://www.rfc-editor.org/rfc/rfc5322#section-3.2.2>
|
| FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
| [...]
| CFWS = (1*([FWS] comment) [FWS]) / FWS
Für ein Mailprogramm müsste das also in Empfangsrichtung funktionieren,
selbst für FWS (nicht nur für CFWS).
Daran sollte auch Erratum 1908 nichts ändern:
<https://www.rfc-editor.org/errata/eid1908>
Das ist komplizierter als ich vermutet hatte, daher Xpost und Fup2 nach
<news:de.comm.software.newsreader>.
Michael Bäuerle
Nov 11, 2023, 6:12:14 AM11/11/23
to
Urs Janßen wrote:
> Michael Bäuerle <michael....@stz-e.de> wrote:
> auch gelesen?
Ja.
> | CFWS allows there to be multiple comments, including comments that go on
> | to the second line, which is perfectly OK.
Du meinst Kapitel 3.2.2, nicht 3.2.3, nehme ich an.
> entweder hat Resnick das problem "uebersehen" (eher nicht) oder aber geht
> davon aus das die einschraenkung in RFC5322 3.2.3 ausreicht und man daher
> keine genauere grammatik braucht (unschoen).
Letzteres. Die geänderte Grammatik wäre sonst auch an diversen anderen
Stellen nötig (z.B. <address-list> darf auch mit CFWS enden).
> > Das ist komplizierter als ich vermutet hatte, daher Xpost und Fup2 nach
> > <news:de.comm.software.newsreader>.
>
> notfalls zieht man sich auf RFC5536 2.2 zurueck ,-)
> | Every line of a header field body (including the first and any
> | that are subsequently folded) MUST contain at least one non-
> | whitespace character
Das hatte ich ja bereits getan. Was flnews macht ist für einen
Newsreader kein Bug.
Der neue Parser, an dem ich gerade arbeite, soll aber RFC 5322 Syntax
akzeptieren. Und so wie es aussieht wäre das aktuelle Verhalten dafür
nicht konform (mal davon abgesehen, dass man in diesem Punkt auch
Fehlertoleranz haben möchte).
> Michael Bäuerle <michael....@stz-e.de> wrote:
> > Urs Janßen wrote:
> > >
> > > https://www.rfc-editor.org/errata/eid3088
> > > hast du gesehen?
> >
> > Nein, dieses Erratum hatte ich übersehen. Danke für den Hinweis.
> > Beim Erratum 3088 steht allerdings dabei:
> > |
> > | Status: Rejected
> >
> > Die von mir zitierte Syntax sollte also noch gültig sein.
>
> die begruendung (der ich nur halb folgen kann, eben wegen 3.2.3) hast du
> > >
> > > https://www.rfc-editor.org/errata/eid3088
> > > hast du gesehen?
> >
> > Nein, dieses Erratum hatte ich übersehen. Danke für den Hinweis.
> > Beim Erratum 3088 steht allerdings dabei:
> > |
> > | Status: Rejected
> >
> > Die von mir zitierte Syntax sollte also noch gültig sein.
>
> auch gelesen?
Ja.
> | CFWS allows there to be multiple comments, including comments that go on
> | to the second line, which is perfectly OK.
Du meinst Kapitel 3.2.2, nicht 3.2.3, nehme ich an.
> entweder hat Resnick das problem "uebersehen" (eher nicht) oder aber geht
> davon aus das die einschraenkung in RFC5322 3.2.3 ausreicht und man daher
> keine genauere grammatik braucht (unschoen).
Letzteres. Die geänderte Grammatik wäre sonst auch an diversen anderen
Stellen nötig (z.B. <address-list> darf auch mit CFWS enden).
> > Das ist komplizierter als ich vermutet hatte, daher Xpost und Fup2 nach
> > <news:de.comm.software.newsreader>.
>
> | Every line of a header field body (including the first and any
> | that are subsequently folded) MUST contain at least one non-
> | whitespace character
Das hatte ich ja bereits getan. Was flnews macht ist für einen
Newsreader kein Bug.
Der neue Parser, an dem ich gerade arbeite, soll aber RFC 5322 Syntax
akzeptieren. Und so wie es aussieht wäre das aktuelle Verhalten dafür
nicht konform (mal davon abgesehen, dass man in diesem Punkt auch
Fehlertoleranz haben möchte).
Michael Bäuerle
Nov 11, 2023, 9:36:19 AM11/11/23
to
Urs Janßen wrote:
es Konsens sein, dass man das im Sinne der Fehlertoleranz ignorieren
sollte.
> auch gegen sowas
> | Date: Wed, 12 Aug 2015 08:13:33 -0453.75
Bei diesem Beispiel könnte man genauso verfahren wie am Ende von
Kapitel 4.3 für unbekannte "multi-character alphabetic time zones"
empfohlen: Die kaputte Zeitzone als "-0000" interpretieren.
Deswegen das ganze Headerfeld ablehnen ist sicher nicht sinnvoll.
> Michael Bäuerle wrote:
> >
> > nicht konform (mal davon abgesehen, dass man in diesem Punkt auch
> > Fehlertoleranz haben möchte).
Mein Kommentar bezog sich auf leere Headerzeilen durch CFWS, hier dürfte
> >
> > nicht konform (mal davon abgesehen, dass man in diesem Punkt auch
> > Fehlertoleranz haben möchte).
es Konsens sein, dass man das im Sinne der Fehlertoleranz ignorieren
sollte.
> auch gegen sowas
> | Date: Wed, 12 Aug 2015 08:13:33 -0453.75
Bei diesem Beispiel könnte man genauso verfahren wie am Ende von
Kapitel 4.3 für unbekannte "multi-character alphabetic time zones"
empfohlen: Die kaputte Zeitzone als "-0000" interpretieren.
Deswegen das ganze Headerfeld ablehnen ist sicher nicht sinnvoll.
0 new messages