🚀 go-pugleaf

Osoba podpisana jako Arivald <arivald@nowhere.interia.pl>
w artykule <news:rhtul3$1qqd$1@gioia.aioe.org> pisze:

> W dniu 23.08.2020 o 14:19, Andrzej P. Wozniak pisze:
>
> To że dzieli w środku wyrazu to nie problem, klient złoży to sobie do
> kupy. A dzieli bo linia razem z kodowaniem i zakończeniem nie powinna
> być dłuższa niż 78 znaków, razem z nazwą nagłówka.

Cross+FUT: pl.news.czytniki

Czyli nie czytasz nowych standardów.
Nagłówek to jest cały kawałek wiadomości przed treścią, nazwy mają
poszczególne pola nagłówka.
Zgodnie ze standardem linia _może_ mieć do 998 znaków, dzielić linie
nagłówka należy tylko przed spacjami, nie ma żadnego ograniczenia na
liczbę linii kontynuacji.
Zgodne z MIME kodowanie pól nagłówka jest opisane w RFC 2047, ale ten w
wielu miejscach odsyła do RFC 822. Tylko że teraz obowiązuje RFC 5322, a
tam widnieje taki punkt:

RFC 5322 (October 2008)
/----
2.2.3.  Long Header Fields

Each header field is logically a single line of characters comprising
the field name, the colon, and the field body.  For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a
multiple-line representation; this is called "folding".  The general
rule is that wherever this specification allows for folding white
space (not simply WSP characters), a CRLF may be inserted before any
WSP.
For example, the header field:

Subject: This is a test

can be represented as:

Subject: This
 is a test

  Note: Though structured field bodies are defined in such a way
  that folding can take place between many of the lexical tokens
  (and even within some of the lexical tokens), folding SHOULD be
  limited to placing the CRLF at higher-level syntactic breaks.  For
  instance, if a field body is defined as comma-separated values, it
  is recommended that folding occur after the comma separating the
  structured items in preference to other places where the field
  could be folded, even if it is allowed elsewhere.

The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
"unfolding".  Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP.  Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation.  An unfolded header field has no length restriction and
therefore may be indeterminately long.
\----

Wystarczająco wyraźnie zapisane? Niestety, to zalecenie ignoruje większość
czytników (OE oczywiście też), które pozostają tu nadal w zeszłym wieku,
choć w standardzie wyraźnie jest zapisane istnienie FWS (Folding White
Space) i CFWS (Comment or Folding White Space). Nie ma innych miejsc
dozwolonych do zwijania i rozwijania linii w nagłówku[1].

Mało tego, jak wynika z cytatu, dla pól strukturalnych występowanie
zwijalnych spacji (FWS) może być nawet bardziej ograniczone, co może
czynić ograniczenie do 78 znaków niewykonalnym – przecież nie podzielisz
Message-ID[2].

> I każda linia
> dostaje swój nagłówek kodowania (=?utf-8?Q?), przy czym kodowanie
> pozostałej części linii jest wybierane jak najlepsze, dlatego w
> oryginalnym tytule od Frei pierwsza linia jest w base64
> (=?UTF-8?B?UXVpeiAxMzkvMjAyMCAtIGN6xJnFm2Npb3dvIHplcsW8bmnEmXR5IG9k?=)
> a druga w quoted printable (=?UTF-8?Q?_Rados=c5=82awaF?=)

To nie jest nigdzie wymagane, to tylko nadgorliwa oszczędność. Żeby było
ciekawiej, Base64 jest nadużywane przez spamerów, bo najprostsze filtry
nie dekodują tekstu. A teraz do rzeczy:

Po pierwsze, to nie są oddzielne pola ani niezależne linie, tylko to jest
pierwsza linia i linia _kontynuacji_ - czy mam tłumaczyć podkreślone
słowo? Czy w podobny sposób kodowałbyś oddzielne akapity treści, gdybyś
musiał wysłać ją jako 7-bitową (czego np. wymagają niektóre podpisy
cyfrowe)[3]?

Po drugie, takie kodowanie ignoruje podstawową zasadę KISS[4]: jedno
pole - jedno kodowanie, jedna wiadomość - jeden zestaw znaków.

[1] Zwijanie i rozwijanie linii treści definiuje format=flowed, RFC 3676.

[2] Wszystkie aktualizacje lub nowe standardy opisujące pola nagłówka też
używają terminu FWS, zob. np. aktualizację DKIM w RFC 5672. Niektóre
poprawki są dostępne tylko jako errata:
ftp://ietf.org/rfc/pending-errata/pending-errata.msgs

[3]Swego czasu ktoś używał kaleki, która tekst z treści wiadomości
wysyłała jako multipart, gdzie w oddzielnych częściach był tekst bez
ogonków i bez deklaracji, a w oddzielnych tekst z ogonkami i deklaracją
zestawu znaków.

[4] W netykiecie KISS jest zapisana inaczej: "Be conservative in what you
send and liberal in what you receive".

Cross+FUT: pl.news.czytniki

-- 
Andrzej P. Woźniak uszer@pochta.onet.pl (zamień miejscami z<->h w adresie)
Grand Inquisitor  pl.internet.pomoc   Trust No.1   http://evil.pl/pip/