Možný ContentTransferEncoding HTML části mailu

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Jaké jsou povolené content transfer encoding hodnoty Html  části e-mailu ? jen quoted printable nebo i 8bit? Zpráva je
Content-Type: multipart/alternative; (má html tělo i převod na plaintext)

Stává se že textová konverze je 8bit utf-8 ,, unicode znaky v zdrojáku. Ale HTML část je qouted printable.

Případně je to věc konkrétní implementace(roundcube) že u html části napevno je qouted printable?

Zkoušel jsem use mime for 8bit ale rozďíl je ten že quotef printable je navíc i ta textplain část

[Reklama]

[Filip Jirsák]

Nezáleží na tom, o jakou část e-mailu se jedná. Každá část MIME zprávy může být kódována jinak, povolené hodnoty Content-Transfer-Encoding jsou 7bit, 8bit, binary, quoted-printable, base64 a pak uživatelsky definované typy.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

A je volba binary v dnešní době už běžně podporovaná na obou stranách? Dá se použít i pro přílohy. Hrozí nějaký problémy skompatibilitou? Hlavně pro přílohu (četl jsem o možném problému crlf a 1000znaků/line, ale to jestli chápu dobře se týká 8bit a ne binary)

A další věc(nesouvisející, oddělená), je možné poslat e-mail který bude mít vhlavičce jen ContentType třeba audio/mp3? Se všemi dalšími hlavičkami Subject,From.Takže by šlo "laicky"(správná formulace to není,ale z uživatelského chápání) o přílohu jenom .

Bude problém takový mail vhodně zobrazit (představa že po kliknutí na mail se otevře dialog Uložit nebo to začne rovnou hrát  )

Natož přijmout v MUA? Na Smtp urovni no problem ale jak to pochopíMUA...

[Filip Jirsák]

Obávám se, že tohle zjistíte jen otestováním dostatečného množství klientů (hlavně ten e-mail jen s audio přílohou). Svět poštovních klientů je džungle, každý se chová jinak.

[mark42]

Velmi pravdepodobne takyto mail neprejde cez rozne spam filtre.
Autorun mailovej prilohy (save as, prehrat) je nebezpecna vec, to na 100% nepojde out-of-the-box na novych mail kliientoch, ktore aspon trochu dbaju o bezpecnost.

[Reklama]