OT: MIME parameter continuations a take to wekovske nadavanie na dobu

[Jan Waclawek]

Dostal som mail s prilohou s touto hlavickou:

--------------515350BF2634BEEAA568B817
Content-Type: application/pdf;
 name="[nejake meno suboru, vela znakov, ale to je jedno proste len je to
dlhe
 takze ho zalomilo].pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="[nejake meno suboru, vela znakov, ale to je jedno proste len
je to dlhe";
 filename*1="takze ho zalomilo].pdf"


Moj oblubeny minimalisticky klient, ultrafunk popcorn
(https://ultrafunk.com/ -- Popcorn email client 1998 - 2010?Discontinued)
z principu nevie zobrazovat prilohy, ale vie ich na poziadanie ulozit; v
tomto pripade vsak ulozil subor s menom [prvy znak z mena - v povodnom
mene bol hned druhy znak bodka] ale s dlzkou 0. Toto samozrejme vzhladom
na tu divnu hlavicku a na vek a charakter toho klienta nie je prekvapujuce.

(Plan B pre tento pripad je, ze si zobrazim mail v nedekodovanej podobe (to
popcorn samozrejme znova z principu vie), copy-pastnem ho do suboru a
pouzijem MIME dekoder z Total Commandera. To znova z principu bez
problemov zafunguje, lebo Total Commander je chvalabohu blbuvzdorny v tom
smere, ze uplne kasle na Conten-Type aj Content-Disposition a jednoducho
vsetko ulozi ako subory s priponou .txt; ale aj on pouzil ako meno len ten
prvy znak, zrejme kvoli tej bodke.)

(Plan C je, ze popcorn vie preposlat mail bez akejkovek zmeny, t.j. ani
nezmeni nic v hlavickach (aj ked pocas toho procesu sa odosielany mail
zobrazi v editore takze je ho mozne rucne zmodifikovat), len samozrejme
treba preposielat tu nedekodovanu verziu; takze si to preposlem na konto
kde to viem pozriet "plnohodnotnym" klientom; ten to meno suboru zobrazil
v povodnej podobe - aj ked tento tiez nezobrazuje .pdf nativne, a do
docasneho adresara pre zobrazenie externym pdf viewerom ho ulozil tiez len
s tym prvym znakom)

Pozeral som si RFC, a parameter filename* je z
https://tools.ietf.org/html/rfc6266#section-4.3 , kde sa pise:
The parameters "filename" and "filename*" differ only in that
   "filename*" uses the encoding defined in [RFC5987], allowing the use
   of characters not present in the ISO-8859-1 character set
   ([ISO-8859-1]).

RFC5987 https://tools.ietf.org/html/rfc5987#section-3.2 pise okrem ineho:
 Furthermore, RFC 2231 allows the character set information to be left
   out.  The encoding defined by this specification does not allow that.


Takze horeuvedena hlavicka minimalne porusuje toto pravidlo, kedze v nej
nie je uvedene kodovanie. 
Mimochodom, v tom skutocnom mene suboru nie su ziadne znaky, ktore by sa
nedali kodovat v ISO-8859-1.

To samozrejme by nijako nevylepsilo symptomy ktore som videl, to su
problemy/vlastnosti (podla pohladu) tych jednoduchych nastrojov co
pouzivam.

Dalej, RFC6266 doporucuje pouzivat oba parametre, filename aj filename*,
cim sa dava sanca starsim klientom, ktore filename* nepoznaju. Njn, "be
conservative in what you do, be liberal in what you accept from others" je
uz dnes pokladany len za trapne znejucy brept od bradaca Postela, ktory to
uz napokon ma za sebou...

No a na zaver este pre tych, co by mienili pisat nejaky emailovy klient,
link na jednoduchu schemicku znazornujucu postup na plne uchopenie
parametra Content-Disposition:
http://test.greenbytes.de/tech/tc2231/2231relations.svg

wek


PS. 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.4.0