Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.newsreader > #13747 > unrolled thread

[tin] Interpretation von falschem CTE (was: welche browser?)

Back to article view | Back to de.comm.software.newsreader

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [tin] Interpretation von falschem CTE (was: welche browser?) Marcel Logen <333200007110-0201@ybtra.de> - 2026-04-25 18:55 +0200
    Re: [tin] Interpretation von falschem CTE Ralph Aichinger <ra@h5.or.at> - 2026-04-25 17:20 +0000
      Re: [tin] Interpretation von falschem CTE Ralph Aichinger <ra@h5.or.at> - 2026-04-25 17:30 +0000
      Re: [tin] Interpretation von falschem CTE Marcel Logen <333200007110-0201@ybtra.de> - 2026-04-25 19:55 +0200
        Re: [tin] Interpretation von falschem CTE Marcel Logen <333200007110-0201@ybtra.de> - 2026-04-25 20:46 +0200
          Re: [tin] Interpretation von falschem CTE Urs Janßen <urs@oxycon.tin.org> - 2026-04-25 19:09 +0000
    Ersetzen von Header-Zeilen durch Server (was: [tin] Interpretation von falschem CTE) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-04-25 19:54 +0200
    Re: [tin] Interpretation von falschem CTE Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-04-25 19:55 +0200
    Re: [tin] Interpretation von falschem CTE Urs Janßen <urs@oxycon.tin.org> - 2026-04-25 19:05 +0000
      Unfolding (was: [tin] Interpretation von falschem CTE) Marcel Logen <333200007110-0201@ybtra.de> - 2026-04-25 23:39 +0200
        Re: Unfolding Urs Janßen <urs@oxycon.tin.org> - 2026-04-25 23:21 +0000
        Re: Unfolding Urs Janßen <urs@oxycon.tin.org> - 2026-04-25 23:21 +0000
          Re: Unfolding Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-04-26 12:04 +0200
            Re: Unfolding "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-04-26 12:44 +0200
            Re: Unfolding Urs Janßen <urs@oxycon.tin.org> - 2026-04-26 10:54 +0000
    Re: [tin] Interpretation von falschem CTE Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-04-25 20:17 +0000
      Re: [tin] Interpretation von falschem CTE Urs Janßen <urs@oxycon.tin.org> - 2026-04-25 22:46 +0000
        Re: [tin] Interpretation von falschem CTE Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-04-26 19:22 +0000

#13747 — [tin] Interpretation von falschem CTE (was: welche browser?)

Ralph Aichinger in de.comp.os.unix.linux.misc:

>Friedhelm Mehnert <honk@friedhelms.net> wrote:

>> [-- "Content-Type: application/octet-stream" forced --]
>> [-- "Content-Type-Encodig: binary" forced --]
                          ^^
                          Fehler in Deinem tin?
>> [-- application/octet-stream, size 0.0K, charset ISO-8859-15, 23 lines, encoding binary --]
>
>Bitte hier keine Binaries posten.

Das sieht IMHO nur so aus.

Hinter der Zeile "Content-Transfer-Encoding: 8bit"
folgte leider eine Faltung, vermutlich weil eine
Zeile "Injection-Info: ..." gelöscht wurde, ohne daß
die dazugehörige zweite Zeile "logging-data=..."
mit entfernt wurde.

Dadurch konnte tin das "8bit ..." nicht richtig als
"8bit" erkennen.

Marcel                                                       (Lines: 31)

fup2 de.comm.software.newsreader
-- 
╮ ╭──╮                 ╭──────╮ ╭──╮  ╭──────╮        ╭────╮    ..65..╭─
╰─╯  ╰─╮               ╰──╮   ╰─╯  │  ╰─╮    │   ╭────╯  ╭─╯  ..63..╭─╯ 
    ╭──╯  ╭──╮ ╭─────╮ ╭──╯        ╰──╮ │    ╰─╮ │  ╭────╯ ╭─╮..63..╰─╮ 
    ╰─────╯  ╰─╯     ╰─╯              ╰─╯..42..╰─╯  ╰──────╯ ╰────────╯ 

[toc] | [next] | [standalone]

#13748 — Re: [tin] Interpretation von falschem CTE

In de.comm.software.newsreader Marcel Logen <333200007110-0201@ybtra.de> wrote:
> Ralph Aichinger in de.comp.os.unix.linux.misc:
> 
>>Friedhelm Mehnert <honk@friedhelms.net> wrote:
> 
>>> [-- "Content-Type: application/octet-stream" forced --]
>>> [-- "Content-Type-Encodig: binary" forced --]
>                           ^^
>                           Fehler in Deinem tin?

Bin nicht sicher. Eventuell bloß in meiner Konfiguration? Wie finde
ich das raus?

Ich hab einfach den tin aus Debian 13:

ii  tin                 1:2.6.5~20250409-1 amd64        Full-screen easy to use Usenet newsreader

>>> [-- application/octet-stream, size 0.0K, charset ISO-8859-15, 23 lines, encoding binary --]
>>
>>Bitte hier keine Binaries posten.
> 
> Das sieht IMHO nur so aus.
> 
> Hinter der Zeile "Content-Transfer-Encoding: 8bit"
> folgte leider eine Faltung, vermutlich weil eine
> Zeile "Injection-Info: ..." gelöscht wurde, ohne daß
> die dazugehörige zweite Zeile "logging-data=..."
> mit entfernt wurde.


Interessant finde ich, dass Friedhelm auch tin verwendet.

/ralph 

[toc] | [prev] | [next] | [standalone]

#13749 — Re: [tin] Interpretation von falschem CTE

Ralph Aichinger <ra@h5.or.at> wrote:
>>>> [-- "Content-Type-Encodig: binary" forced --]
>>                           ^^
>>                           Fehler in Deinem tin?
> 
> Bin nicht sicher. Eventuell bloß in meiner Konfiguration? Wie finde
> ich das raus?

The plot thickens:

ralph@pi:~$ strings /usr/bin/tin |grep Encodig
[-- "Content-Type-Encodig: %s" forced --]

Ich werd mal in den Sourcen schauen wie es da steht.

/ralph

[toc] | [prev] | [next] | [standalone]

#13751 — Re: [tin] Interpretation von falschem CTE

Ralph Aichinger in de.comm.software.newsreader:

>In de.comm.software.newsreader Marcel Logen <333200007110-0201@ybtra.de> wrote:
>> Ralph Aichinger in de.comp.os.unix.linux.misc:
>>>Friedhelm Mehnert <honk@friedhelms.net> wrote:

>>>> [-- "Content-Type: application/octet-stream" forced --]
>>>> [-- "Content-Type-Encodig: binary" forced --]
>>                           ^^
>>                           Fehler in Deinem tin?
>
>Bin nicht sicher. Eventuell bloß in meiner Konfiguration? Wie finde
>ich das raus?
>
>Ich hab einfach den tin aus Debian 13:
>
>ii  tin                 1:2.6.5~20250409-1 amd64        Full-screen easy to use Usenet newsreader

Wenn ich nachher etwas Zeit finde, schaue ich auch mal in den
Quellen (des aktuellen snapshots) nach.

>>>Bitte hier keine Binaries posten.
>> 
>> Das sieht IMHO nur so aus.
>> 
>> Hinter der Zeile "Content-Transfer-Encoding: 8bit"
>> folgte leider eine Faltung, vermutlich weil eine
>> Zeile "Injection-Info: ..." gelöscht wurde, ohne daß
>> die dazugehörige zweite Zeile "logging-data=..."
>> mit entfernt wurde.
>
>
>Interessant finde ich, dass Friedhelm auch tin verwendet.

Er benutzt vermutlich zusätzlich einen lokalen INN oder ähn-
liches, wobei dann aber die Zeile "Injection-Info" (genauer:
leider nur die erste Zeile davon) beim Senden an den 'öffent-
lichen' Server wieder entfernt wird (meine Vermutung).

Marcel
-- 
Sat Apr 25 19:55:28 2026 CEST (1777139728)
o15
87 fr4j aq25
Lines: 45

[toc] | [prev] | [next] | [standalone]

#13753 — Re: [tin] Interpretation von falschem CTE

Marcel Logen in de.comm.software.newsreader:

>Ralph Aichinger in de.comm.software.newsreader:
>>In de.comm.software.newsreader Marcel Logen <333200007110-0201@ybtra.de> wrote:
>>> Ralph Aichinger in de.comp.os.unix.linux.misc:

>>>>> [-- "Content-Type: application/octet-stream" forced --]
>>>>> [-- "Content-Type-Encodig: binary" forced --]
>>>                           ^^
>>>                           Fehler in Deinem tin?
>>
>>Bin nicht sicher. Eventuell bloß in meiner Konfiguration? Wie finde
>>ich das raus?
>>
>>Ich hab einfach den tin aus Debian 13:
>>
>>ii  tin                 1:2.6.5~20250409-1 amd64        Full-screen easy to use Usenet newsreader
>
>Wenn ich nachher etwas Zeit finde, schaue ich auch mal in den
>Quellen (des aktuellen snapshots) nach.

| $ grep -e 'Encodig' -r -n /tmp/tin-2.6.6/
| /tmp/tin-2.6.6/src/cook.c:2358:			put_cooked(LEN, wrap_lines, C_ATTACH, "[-- \"Content-Type-Encodig: %s\" forced --]\n", content_encodings[hdr->ext->encoding]);
| /tmp/tin-2.6.6/src/cook.c:2365:				put_cooked(LEN, wrap_lines, C_ATTACH, "[-- \"Content-Type-Encodig: %s\" forced --]\n", content_encodings[hdr->ext->encoding]);

Marcel                                                       (Lines: 31)
-- 
╭───╮ ╭─╮       ╭───────╮                ╭────╮         ..57..╭───╮     
╯   ╰─╯ ╰─╮   ╭─╯       ╰─╮ ╭───╮  ..36..╰─╮  ╰───╮   ╭───────╯   ╰────╮
          │   ╰─╮         │ │   │ ╭──────╮ │   ╭──╯   │          ..66..╰
          ╰─────╯         ╰─╯   ╰─╯      ╰─╯   ╰──────╯           ..67..

[toc] | [prev] | [next] | [standalone]

#13755 — Re: [tin] Interpretation von falschem CTE

Marcel Logen wrote:
> | /tmp/tin-2.6.6/src/cook.c:2358:                       put_cooked(LEN, wrap_lines, C_ATTACH, "[-- \"Content-Type-Encodig: %s\" forced --]\n", content_encodings[hdr->ext->encoding]);
> | /tmp/tin-2.6.6/src/cook.c:2365:                               put_cooked(LEN, wrap_lines, C_ATTACH, "[-- \"Content-Type-Encodig: %s\" forced --]\n", content_encodings[hdr->ext->encoding]);

thnx, typo fixed.

[toc] | [prev] | [next] | [standalone]

#13750 — Ersetzen von Header-Zeilen durch Server (was: [tin] Interpretation von falschem CTE)

[Fup2 de.comm.software.newsserver]

On 2026-04-25 18:55, Marcel Logen <333200007110-0201@ybtra.de> wrote:
> Ralph Aichinger in de.comp.os.unix.linux.misc:
>
>>Friedhelm Mehnert <honk@friedhelms.net> wrote:
>
>>> [-- "Content-Type: application/octet-stream" forced --]
>>> [-- "Content-Type-Encodig: binary" forced --]
>                           ^^
>                           Fehler in Deinem tin?
>>> [-- application/octet-stream, size 0.0K, charset ISO-8859-15, 23 lines, encoding binary --]
>>
>>Bitte hier keine Binaries posten.
>
> Das sieht IMHO nur so aus.
>
> Hinter der Zeile "Content-Transfer-Encoding: 8bit"
> folgte leider eine Faltung, vermutlich weil eine
> Zeile "Injection-Info: ..." gelöscht wurde, ohne daß
> die dazugehörige zweite Zeile "logging-data=..."
> mit entfernt wurde.

Sieht so aus. Es gibt nämlich zwei Zeilen mit diesen Parametern:

| MIME-Version: 1.0
| Content-Type: text/plain; charset=ISO-8859-15
| Content-Transfer-Encoding: 8bit
|         logging-data="25770"; mail-complaints-to="usenet@friedhelms.net"
| Injection-Date: Sat, 25 Apr 2026 13:10:04 +0000 (UTC)
| Injection-Info: dont-email.me; posting-host="57d83bc8c2ec83ae8ca1b10ccd9a2dd5";
|         logging-data="891834"; mail-complaints-to="abuse@eternal-september.org";        posting-account="U2FsdGVkX18IBGISk2ANP+zVXRDFUeLAzPTSIrP5mf8="
| User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-44-amd64 (x86_64))

(direkt aus dem Newsspool kopiert.)

Ich vermute, dass Friedhelm eine Software (lokaler Newsserver,
vielleicht Hamster oder Leafnode?) betreibt, die bereits einen
Injection-Info: Header setzt.

Beim Einliefern hat dann eternal-september.org den Injection-Info:
Header unvollständig entfernt und einen eigenen hinzugefügt.

Das unvollständige Entfernen finde ich dabei insofern bemerkenswert, als
auch der von eternal-september eingefügte Header mehrzeilig ist. Wer
Software schreibt, die selbst mehrzeilige Header einfügt, sollte
eigentlich schon damit rechnen, dass auch die Header, die die Software
entfernen soll, mehrzeilig sind.

        hjp

[toc] | [prev] | [next] | [standalone]

#13752 — Re: [tin] Interpretation von falschem CTE

Marcel Logen wrote:
> Ralph Aichinger in de.comp.os.unix.linux.misc:
> > 
> > [...]
> > Bitte hier keine Binaries posten.
> 
> Das sieht IMHO nur so aus.
> 
> Hinter der Zeile "Content-Transfer-Encoding: 8bit"
> folgte leider eine Faltung, vermutlich weil eine
> Zeile "Injection-Info: ..." gelöscht wurde, ohne daß
> die dazugehörige zweite Zeile "logging-data=..."
> mit entfernt wurde.

Ich sehe in Artikel <news:10sicgv$p59$1@m1.friedhelms.net> das hier:
| 
| MIME-Version: 1.0
| Content-Type: text/plain; charset=ISO-8859-15
| Content-Transfer-Encoding: 8bit
| 	logging-data="25770"; mail-complaints-to="usenet@friedhelms.net"
  ^
Hier ein HT-Steuerzeichen nach der Faltung.
Das entspricht deiner Beschreibung.

Es gibt aber auch ein "Injection-Info" Headerfeld in dem Artikel.
Wenn man sich an der von dir beschriebenen Stelle eines hinzudenkt, dann
wäre es zweimal vorhanden.

> Dadurch konnte tin das "8bit ..." nicht richtig als
> "8bit" erkennen.

flnews sagt:
| 
| flnews: CORE: Header parser: Garbage at end of Content-Transfer-Encoding field ignored

Deswegen war mir das Problem zuerst gar nicht aufgefallen.

[toc] | [prev] | [next] | [standalone]

#13754 — Re: [tin] Interpretation von falschem CTE

Marcel Logen <333200007110-0201@ybtra.de> wrote:
> Ralph Aichinger in de.comp.os.unix.linux.misc:
> 
>>Friedhelm Mehnert <honk@friedhelms.net> wrote:
> 
>>> [-- "Content-Type: application/octet-stream" forced --]
>>> [-- "Content-Type-Encodig: binary" forced --]
>                           ^^
>                           Fehler in Deinem tin?

nein, fehler im artikel.

| Content-Transfer-Encoding: 8bit
|	logging-data="25770";

ist kein gueltiges encoding, tin sagt (PageArticleInfo "'"):

Part 1:
        MIME Version:
                Article:        1.0
                Used:           1.0
        Content Type:
                Article:        text / plain
                Used:           application / octet-stream
        Charset:
                Article:        ISO-8859-15
                Used:           None
        Content Transfer Encoding:
                Article:        Unsupported: 8bitlogging-data="25770";mail-complaints-to="usenet@...
                Used:           binary

was zu RFC 2045 6.4

| Any entity with an unrecognized Content-Transfer-Encoding must be
| treated as if it has a Content-Type of "application/octet-stream",
| regardless of what the Content-Type header field actually says.

passt.

> folgte leider eine Faltung, vermutlich weil eine
> Zeile "Injection-Info: ..." gelöscht wurde, ohne daß
> die dazugehörige zweite Zeile "logging-data=..."
> mit entfernt wurde.
> 
> Dadurch konnte tin das "8bit ..." nicht richtig als
> "8bit" erkennen.

richig, weil da eben nach unfolding 8bitlogging-data=... steht .

[toc] | [prev] | [next] | [standalone]

#13757 — Unfolding (was: [tin] Interpretation von falschem CTE)

Urs Janßen in de.comm.software.newsreader:

>Marcel Logen <333200007110-0201@ybtra.de> wrote:

[...]

>| Content-Transfer-Encoding: 8bit
>|	logging-data="25770";
>
>ist kein gueltiges encoding, tin sagt (PageArticleInfo "'"):
[...]
>        Content Transfer Encoding:
>                Article:        Unsupported: 8bitlogging-data="25770";mail-complaints-to="usenet@...
>                Used:           binary
[...]
>> folgte leider eine Faltung, vermutlich weil eine
>> Zeile "Injection-Info: ..." gelöscht wurde, ohne daß
>> die dazugehörige zweite Zeile "logging-data=..."
>> mit entfernt wurde.
>> 
>> Dadurch konnte tin das "8bit ..." nicht richtig als
>> "8bit" erkennen.
>
>richig, weil da eben nach unfolding 8bitlogging-data=... steht .

Gnus zeigt mir das BTW so an:

| Content-Transfer-Encoding: 8bit logging-data="25770"; mail-complaints-to="usenet@[...]

und bringt dazu die Meldung:

| Unknown encoding 8bitlogging-data25770mail-complaints-tousenet[...].net; defaulting to 8bit

IMHO sollte da nach Unfolding stehen:

| Content-Transfer-Encoding: 8bit       logging-data="25770"; mail-complaints-to="usenet@[...]

(also mit TAB nach "8bit").

Jedenfalls verstehe ich Nr. 2.2.3. und 3.2.2. von RFC5322 so, daß
beim Unfolding nur das CRLF, nicht aber der WSP entfernt werden darf.

Marcel
-- 
Sat Apr 25 23:39:41 2026 CEST (1777153181)
pc-731
87 bjf6 68n5
Lines: 48

[toc] | [prev] | [next] | [standalone]

#13759 — Re: Unfolding

Marcel Logen wrote:
> Jedenfalls verstehe ich Nr. 2.2.3. und 3.2.2. von RFC5322 so, daß
> beim Unfolding nur das CRLF, nicht aber der WSP entfernt werden darf.

nach RFC 2045 Appendix A

  encoding := "Content-Transfer-Encoding" ":" mechanism
  mechanism := "7bit" / "8bit" / "binary" /
               "quoted-printable" / "base64" /
               ietf-token / x-token
  token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
              or tspecials>
  x-token := <The two characters "X-" or "x-" followed, with
              no  intervening white space, by any token>

sind hier eh keine FWS zulaessig. fuer die debug ausgabe
verifach das tin zu

	/* Remove comments and white space */
	remove_cwsp(encoding);

[toc] | [prev] | [next] | [standalone]

#13760 — Re: Unfolding

Marcel Logen wrote:
> Jedenfalls verstehe ich Nr. 2.2.3. und 3.2.2. von RFC5322 so, daß
> beim Unfolding nur das CRLF, nicht aber der WSP entfernt werden darf.

nach RFC 2045 Appendix A

  encoding := "Content-Transfer-Encoding" ":" mechanism
  mechanism := "7bit" / "8bit" / "binary" /
               "quoted-printable" / "base64" /
               ietf-token / x-token
  token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
              or tspecials>
  x-token := <The two characters "X-" or "x-" followed, with
              no  intervening white space, by any token>

sind hier eh keine FWS zulaessig. fuer die debug ausgabe
vereinfacht das tin zu

        /* Remove comments and white space */
        remove_cwsp(encoding);

[toc] | [prev] | [next] | [standalone]

#13761 — Re: Unfolding

Urs Janßen wrote:
> Marcel Logen wrote:
> > 
> > Jedenfalls verstehe ich Nr. 2.2.3. und 3.2.2. von RFC5322 so, daß
> > beim Unfolding nur das CRLF, nicht aber der WSP entfernt werden darf.

Sehe ich genauso.

> nach RFC 2045 Appendix A
> 
>   encoding := "Content-Transfer-Encoding" ":" mechanism
>   mechanism := "7bit" / "8bit" / "binary" /
>                "quoted-printable" / "base64" /
>                ietf-token / x-token
>   token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>               or tspecials>
>   x-token := <The two characters "X-" or "x-" followed, with
>               no  intervening white space, by any token>
> 
> sind hier eh keine FWS zulaessig.

Sehe ich anders (das ändert aber nichts am Ergebnis).

> fuer die debug ausgabe
> vereinfacht das tin zu
> 
>         /* Remove comments and white space */
>         remove_cwsp(encoding);

RFC 2045 basiert noch auf RFC 822:
<https://datatracker.ietf.org/doc/html/rfc822#section-3.4.2> 
| 
|     3.4.2.  WHITE SPACE
|     
|        Note:  In structured field bodies, multiple linear space ASCII
|               characters  (namely  HTABs  and  SPACEs) are treated as
|               single spaces and may freely surround any  symbol.   In
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|               all header fields, the only place in which at least one
|               LWSP-char is REQUIRED is at the beginning of  continua-
|               tion lines in a folded field.
| [...]

HTAB darf demnach vor und hinter "8bit" stehen.
RFC 5322 und RFC 5536 schränken das nicht ein, wenn ich es richtig sehe.

Dass es sich bei "Content-Transfer-Encoding" um ein "structured header
field" handelt dürfte unstrittig sein:
<https://datatracker.ietf.org/doc/html/rfc822#section-3.1.2>
|
| [...]
|        Note:  Any field which has a field-body  that  is  defined  as
|               other  than  simply <text> is to be treated as a struc-
|               tured field.
| [...]

Das ist in RFC 5322 immer noch so, nur heißt es heute <unstructured>:
<https://datatracker.ietf.org/doc/html/rfc5322#section-2.2.1>

Das erste Token sollte demnach korrekt sein. Der Fehler ist, dass
weitere Tokens folgen, was RFC 2045 ausdrücklich nicht erlaubt:
<https://datatracker.ietf.org/doc/html/rfc2045#section-6.1>
| 6.1.  Content-Transfer-Encoding Syntax
| 
|    The Content-Transfer-Encoding field's value is a single token
                                                      ^^^^^^^^^^^^
| [...]

Die Syntax des Headerfeldes ist demnach kaputt, deswegen darf tin hier
den Typ "application/octet-stream" verwenden.

Die Frage ist eher, ob die anderen Newsreader das nicht ebenfalls tun
*müssten* (statt die folgenden Tokens zu ignorieren).

[toc] | [prev] | [next] | [standalone]

#13762 — Re: Unfolding

On 2026-04-26 12:04, Michael Bäuerle <michael.baeuerle@gmx.net> wrote:
> Urs Janßen wrote:
>> nach RFC 2045 Appendix A
>> 
>>   encoding := "Content-Transfer-Encoding" ":" mechanism
>>   mechanism := "7bit" / "8bit" / "binary" /
>>                "quoted-printable" / "base64" /
>>                ietf-token / x-token
>>   token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>>               or tspecials>
>>   x-token := <The two characters "X-" or "x-" followed, with
>>               no  intervening white space, by any token>
>> 
>> sind hier eh keine FWS zulaessig.
>
> Sehe ich anders (das ändert aber nichts am Ergebnis).
>
>> fuer die debug ausgabe
>> vereinfacht das tin zu
>> 
>>         /* Remove comments and white space */
>>         remove_cwsp(encoding);
>
> RFC 2045 basiert noch auf RFC 822:
><https://datatracker.ietf.org/doc/html/rfc822#section-3.4.2> 
>| 
>|     3.4.2.  WHITE SPACE
>|     
>|        Note:  In structured field bodies, multiple linear space ASCII
>|               characters  (namely  HTABs  and  SPACEs) are treated as
>|               single spaces and may freely surround any  symbol.   In
>                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>|               all header fields, the only place in which at least one
>|               LWSP-char is REQUIRED is at the beginning of  continua-
>|               tion lines in a folded field.
>| [...]
>
> HTAB darf demnach vor und hinter "8bit" stehen.

HTAB schon, aber nicht CRLF.

In Abschnitt 3.1.1 steht:

| The general rule is that wherever  there may  be  linear-white-space
| (NOT  simply  LWSP-chars), a CRLF immediately followed by AT LEAST one
  ^^^^^^^^^^^^^^^^^^^^^^^^^
| LWSP-char may instead  be inserted.

Man darf also nicht überall, wo HTAB und SPACE erlaubt sind, auch ein
CRLF einfügen, sondern nur dort, wo laut Grammatik linear-white-space
erlaubt ist.

Laut 3.1.4:

| To aid in the creation and reading of structured  fields,  the
| free  insertion   of linear-white-space (which permits folding
| by inclusion of CRLFs)  is  allowed  between  lexical  tokens.
                                       ^^^^^^^

Der Content-Transfer-Encoding Header enthält nur ein einziges Token, man
kann da also keinen linear-white-space zwischen zwei Tokens einfügen.

Allerdings ist es müßig, sich darüber zu streiten, ob der Header
syntaktisch falsch ist, weil da ein linear-white-space steht oder weil
nach dem linear-white-space noch ein Token kommt. In jedem Fall es das
syntaktisch falsch. In der Praxis würde mich wundern, wenn ein Parser
tatsächlich über den linear-white-space stolpert.

        hjp

[toc] | [prev] | [next] | [standalone]

#13763 — Re: Unfolding

Michael Bäuerle wrote:
>>         remove_cwsp(encoding);
> 
> RFC 2045 basiert noch auf RFC 822:
> <https://datatracker.ietf.org/doc/html/rfc822#section-3.4.2> 
> | 
> |     3.4.2.  WHITE SPACE
> |     
> |        Note:  In structured field bodies, multiple linear space ASCII
> |               characters  (namely  HTABs  and  SPACEs) are treated as
> |               single spaces and may freely surround any  symbol.   In
>                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |               all header fields, the only place in which at least one
> |               LWSP-char is REQUIRED is at the beginning of  continua-
> |               tion lines in a folded field.
> | [...]
> 
> HTAB darf demnach vor und hinter "8bit" stehen.

und _hier_ entsorgt werden (da kein weiters symbol folgen darf).

> Das erste Token sollte demnach korrekt sein. Der Fehler ist, dass
> weitere Tokens folgen, was RFC 2045 ausdrücklich nicht erlaubt:
> <https://datatracker.ietf.org/doc/html/rfc2045#section-6.1>
> | 6.1.  Content-Transfer-Encoding Syntax
> | 
> |    The Content-Transfer-Encoding field's value is a single token

bei single token tut remove_cwsp() nicht weh und sonst ist das
ergebniss halt CTE ist ungueltig.

> Die Frage ist eher, ob die anderen Newsreader das nicht ebenfalls tun
> *müssten* (statt die folgenden Tokens zu ignorieren).

man koennte den Postel ausgraben... die frage ist halt _wie_
liberal man sein will.

[toc] | [prev] | [next] | [standalone]

#13756 — Re: [tin] Interpretation von falschem CTE

In de.comp.os.unix.linux.misc Marcel Logen <333200007110-0201@ybtra.de> wrote:
> Ralph Aichinger in de.comp.os.unix.linux.misc:
>>Friedhelm Mehnert <honk@friedhelms.net> wrote:
> 
>>> [-- "Content-Type: application/octet-stream" forced --]
>>> [-- "Content-Type-Encodig: binary" forced --]
>                           ^^
>                           Fehler in Deinem tin?
>>> [-- application/octet-stream, size 0.0K, charset ISO-8859-15, 23 lines, encoding binary --]
>>
>>Bitte hier keine Binaries posten.
> 
> Das sieht IMHO nur so aus.
> 
> Hinter der Zeile "Content-Transfer-Encoding: 8bit"
> folgte leider eine Faltung, vermutlich weil eine
> Zeile "Injection-Info: ..." gelöscht wurde, ohne daß
> die dazugehörige zweite Zeile "logging-data=..."
> mit entfernt wurde.
> 
> Dadurch konnte tin das "8bit ..." nicht richtig als
> "8bit" erkennen.

Weiss nicht. Mein tin sagt mir zwar, wenn ich die Header anzeigen
lasse:

#v+
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
\011logging-data="25770"; mail-complaints-to="usenet@friedhelms.net"
Injection-Date: Sat, 25 Apr 2026 13:10:04 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="57d83bc8c2ec83ae8ca1b10ccd9a2dd5";
#v-

Aber weder mit noch ohne Header wird mir das Posting als
"application/octet-stream" angezeigt.

Servus,
   Stefan

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

Wild und doch wild?! Stefan - damit alles gelingt.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#13758 — Re: [tin] Interpretation von falschem CTE

Stefan Froehlich wrote:
> Aber weder mit noch ohne Header wird mir das Posting als
> "application/octet-stream" angezeigt.

dein tin/2.6.2-20221225 ist hat etwas angestaubt.
akw% bzr diff -r913..1990 src | diffstat  | tail -n -1
 73 files changed, 23428 insertions(+), 12214 deletions(-)

[toc] | [prev] | [next] | [standalone]

#13764 — Re: [tin] Interpretation von falschem CTE

On Sun, 26 Apr 2026 00:46:00 Urs Janßen wrote:
> Stefan Froehlich wrote:
>> Aber weder mit noch ohne Header wird mir das Posting als
>> "application/octet-stream" angezeigt.

> dein tin/2.6.2-20221225 ist hat etwas angestaubt.

Weshalb ich das Posting auch rasch wieder gelöscht hatte.

Das ist das Problem mit Follow-Ups: Ich hatte auf ein einzelnes
Posting geantwortet und erst hinterher bemerkt, dass da bereits
ein Rattenschwanz deutlich kompetenterer Antworten vorhanden war.

> akw% bzr diff -r913..1990 src | diffstat  | tail -n -1
>  73 files changed, 23428 insertions(+), 12214 deletions(-)

Der Druch zum Aktualisieren ist halt nicht wirklich groß...

Servus,
   Stefan

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

Stefan. Für intelligente Acker in wütenden Gewittern!
(Sloganizer)

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.newsreader

csiph-web