OT: dotaz na konverzi CRLF behem prenosu mailu

[Dan Lukes]

On 09/27/10 19:00, Jan Pechanec:
> 	narazil jsem na problem, ze z unixu odeslu pres Pine textovy soubor
> a clovek na druhy strane, taky na unixu, s ThunderBirdem, to ulozi a ma tam
> extra LF znaky.
>
> 	RFC 2046 rika: "The canonical form of any MIME "text" subtype MUST
> always represent a line break as a CRLF sequence."
>
> 	zjistil jsem, ze Pine vzdy zkonvertuje text tak, ze CR zmeni na
> CRLF. Vzhledem k vete nahore bych si rekl, ze dela spravnou vec. Tj.
> ThunderBird by to mel ulozit podle systemu, tj. na unixu odebrat LF. A to
> nedela.
>
> 	Pine ale navic vzdy na text pouzije base64, tj. az po prekodovani CR
> ->  CRLF. Ale to mi porad prijde OK. Vysvetleni proc dela encoding i na
> textovy soubory je tady:
>
> 	http://www.washington.edu/pine/faq/attachments.html
>
> 	muj dotaz: chova se podle specifikace spatne ThunderBird, nebo Pine?

Zadna specifikace o ktere tu byla rec nemluvi o tom, v jakem formatu si 
maji postu ukladat konkretni programy. Ty rikaji jak maji vypadat behem 
transportu. Takze at uz si program uklada maily jak chce, pokud je po 
sobe dokaze zase precist, tak je uklada spravne.

Ale to ses asi jen zeptal na neco trochu jinyho nez's chtel. Pro odpoved 
je ale podstatne jakym typem pine oznaci pripojeny soubor - neco jineho 
je text/plain, neco jineho je text/rfc822

Takze jsem si vyrobil textovy soubor obsahujici

CR\n
CRLF\r\n

a poslal jsme si ho jako attachment pomoci Alpine 2.00

Prislo toto:
...
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=a
Content-Transfer-Encoding: BASE64
...
Q1INCkNSTEYNDQo=

Coz je po dekodovani toto:

CR\r\n
CRLF\r\r\n

Soubor tedy byl pri prenosu zmenen - to je skutecnost nezavisla na 
programu, kterym se dosly email bude nasledne zpracovavat. Otazka, ktera 
zbyva je, zda byl zmenen tak, ze ma s ohledemna udany typ odlisny vyznam 
nez text puvodni. Protoze pokud ano, jde o "nedovolenou" zmenu, v 
opacnem pripade jde o zmenu sice mozna zbytecnou, presto vsak korektni.

Ta cast RFC 2046 kterou's citoval ta pojednava o tom, jak musi vypadat 
uz zakodovany attachment - a ten musi navenek splnovat pravidla pro 
puvodni klasicky non-MIME email - proto ta podminka. Pro nasi otazku je 
ale podstatna spis to jak vypada "vnitrek" attachmentu typu text/plain a 
to je tato pasaz:

(1)   text -- textual information.  The subtype "plain" in
       particular indicates plain text containing no
       formatting commands or directives of any sort. Plain
       text is intended to be displayed "as-is".

Klicove tam je to "displayed as-is" ja chapu tak, ze kdyz udelam na obou 
systemech 'cat a' respektive 'copy a con:' respektive jiny ekvivalentni 
prikaz podle konkretniho OS tak na obou uvidim totez. Samozrejme, ze na 
"prave" strane prikazu musi byt "us-ascii textova konzole". Pokud bych 
mel nejakou jinou (treba EBCDIC) musim text pro ucely zobrazeni 
prekodovat tak, aby se ve vysledku zobrazilo to, co se zobrazit ma.

No, zkusil jsem to jen na Windows XP a FreeBSD ale na tech to plati. 
Nakonec - CR (ASCII 0x0D) je ridici znak pozadujici presun kursoru na 
prvni pozici aktualniho radku a u toho by melo byt lhostejne ze ji misto 
jednou pozadujes dvakrat.

S LF (ASCII 0x0A) je to trochu slozitejsi, protoze tam existuji dve 
interpretace, ktere se shodnou, ze pozice se ma posunout o radek niz, 
ale neshodnou se, zda se pri tom soucasne ma kursor vratit na prvni 
pozici radku nebo ne

Pri nas pripad to ale neni podstatne - at pouzijeme jakoukoliv 
interpretaci, pridani libovolneho poctu CR pred LF by nemelo vysledne 
zobrazeni zmenit.

Muj zaver je tedy ten, ze:

a) dela zbytecnou transformaci, s ohledem na zvoleny typ ale prevadi 
jednu formu prilohy na jinou formu vyznamove ekvivalentni

b) thunderbird chybne implementuje "zobrazit "as-is" a to bud' proto, ze

ba) bud' do text zasahne sam a chybne, nebo tak, ze

bb) data zobrazuje na vystupni terminal, ktery neni US-ASCII a on, 
naopak, data pred tim nez je tam posle neupravi ac by mel (analogicky 
viz vyse zmineny EBCDIC priklad)

Thunderbird se z toho muze vyvleknout jen v pripade, ze by byla chyba v 
terminalu, ktery ma k dispozici - mel by byt ASCII, ale ma chybu a neni 
- v takovem pripade by samozrejme byla chyba v tom terminalu.

Mimochodem - ja thunderbird nemam, ale myslel jsem, ze seamonkey pouziva 
stejny renderer a ma jen jine UI - ale asi ne, protoze seamonkey mi 
pine-odeslany textovy dopis zobrazilo "spravnym" zpusobem - zadne divne 
znaky na konci radku videt nebyly.

No, na to, ze je to OT odpoved na OT otazku mi to vyslo neprimerene 
dlouhy ...

Dan