Iulian Ursache-Dogariu <[EMAIL PROTECTED]> scria la data de 11 Iunie 2005:
> On Friday 10 June 2005 18:37, Liviu Daia wrote:
> > (2) Un sacenariu in care Ecartis-ul cu patch-ul propus genereaza
> > mesaje invalide este urmatorul: un mesaj trimis catre lista avand un
> > attachment Base64 si altul 8bit, si care bounce-aza. Bounce-ul este
> > invalid.
>
> Mai precis, primul part in Base64 si al doilea in 8bit.
De fapt, indiferent cum le-ai combina.
> Desi scenariul asta e destul de greu de realizat (vezi mai spre
> sfarsit), intr-adevar, avem o problema.
>
> Beware, long message ahead. Nerabdatorii sunt rugati sa sara direct la
> punctul 3). ;-)
>
>
> 1) Mai intai putina teorie :)
>
> Functia unmime_file uneste partile unui mesaj MIME (mesajul original),
> care poate fi sau nu multi-part, intr-un mesaj RFC822 (email clasic, cu
> un singur bloc de headere si un singur body, fara parti MIME).
Si sterge attachment-urile care nu sunt de tip text/plain.
In sfarsit, de fapt e mai complicat, pentru ca nu sterge complet
attachment-urile multipart si message, dar in esenta scopul ei este
intr-adevar sa uneasca partile text intr-un singur body si sa ignore
restul.
> In mesajul original, fiecare part MIME poate fi encodat in propriul
> sau transfer-encoding.
Ca sa nu mai vorbim ca poate avea propriul sau charset. :-) Situatia
in care exista mai multe charset-uri in acelasi mesaj nu e nemaiauzita
(desi probabil nu pe RLUG): multe mesaje au un attachment intr-o limba
asiatica si un altul cu traducerea in engleza... Dar sa spunem ca nu
problema asta ne framanta acum.
> Numai ca dupa de-MIME-ificare, mesajul rezultat trebuie sa aiba un
> singur transfer-encoding.
Si un singur charset.
> Care sa fie acesta?
>
> Developerii Ecartis au ales 8bit.
>
> Numai ca, spre durerea noastra de cap, ei nu _convertesc_ part-urile
> la 8bit, ci doar lipesc octetii primului part de octetii celui de-al
> doilea, s.a.m.d., ignorand encodingul fiecarui part. Bineinteles,
> octetii unui mesaj base64 sau quoted-printable de ex, sunt valizi
> si in interiorul unui mesaj 8bit. Insa intr-o "anvelopa" 8bit,
> respectivii octeti isi pierd semnificatia.
>
> Aici e radacina necazurilor cu diacriticele.
Adevarat.
> 2) Patch-ul si problema
>
> Patch-ul lui xcyborg rezolva f bine cazul mesajelor cu un singur
> part MIME. Fiind vorba de un singur part, si deci de un singur
> transfer-encoding, solutia de bun-simt este sa lasam acel encoding
> neatins.
>
> In cazul mesajelor multipart insa, functia patchuita, asa cum este
> acum, pune pe **intregul mesaj** content-transfer-encoding-ul
> *primului* part.
Ceea ce este o alta problema, inca si mai vizibila, decat cea la
care ma refeream eu.
> - Daca toate part-urile au acelasi transfer-encoding, nu apar necazuri.
> - Daca, de exemplu, primul part ar fi "8bit" si al doilea "base64",
> mesajul rezultat ar fi marcat ca 8bit; iar prin lipirea chioara a
> bucatii base64 de cea 8bit rezulta intr-adevar un mesaj 8bit valid.
Valid ca structura, nu si ca semnificatie. Cand citesti mesajul,
partea Base64 ramane nedecodata.
> - DAR, daca e invers, adica primul part este base64 si al doilea este
> 8bit, mesajul rezultat este marcat ca fiind encodat base64, dar el de
> fapt contine octetii base64 de la primul part PLUS niste octeti
> aleatori, proveniti de la al doilea part (care e 8bit). Mesaj
> **INVALID**.
In sensul ca bietul MUA va incerca sa decodeze si junk-ul 8bit tot
ca Base64, adevarat.
> 3) Posibile solutii:
>
> 3.1. La ora actuala unmime_file ruleaza ABSOLUT DEGEABA chiar si
> pe mesaje ne-MIME, sau cu un singur part MIME. Fiindca majoritatea
> mesajelor traficate pe rlug si offtopic sunt din aceasta categorie,
> putem preveni o mare parte din problemele cu diacriticele pur
> si simplu impiedicand rularea functiei unmime_file pe mesajele
> ne-multipart, indiferent de ce zice humanize_mime.
Corect.
> 3.2. In cazul mesajelor multipart: Solutia ideala ar fi sa decodam
> fiecare part in mod corespunzator si sa le aducem la 8bit.
De fapt asta e singura solutie, vezi paragraful urmator.
> Daca insa continuam cu lipirea chioara a part-urilor unul de altul,
> trebuie sa avem grija sa alegem mai inteligent transfer-encoding-ul
> mesajului de-MIME-ificat. Mai precis, sa alegem cel mai "permisiv"
> transfer-encoding care se gaseste in mesajul original. In ordinea
> descrescatoare a permisivitatii: 8bit (teoretic 255 octeti), 7bit,
> quoted-printable, base64. Deci, daca unul din part-urile mesajului
> original (nu conteaza care) este 8bit, intregul mesaj de-MIME-ificat
> trebuie sa fie 8bit.
Scuze, dar oricum ai lipi un attachment Quoted-Printable cu altul
Base64, rezultatul nu e nici Quoted-Printable, nici Base64, nici altceva
cu sens.
Daca problema pe care incerci sa o rezolvi este sa feresti MUA-ul de
a incerca sa decodeze un Quoted-Printable ca Base64 sau invers, atunci
amestecului de mai sus nu ii poti pune decat un encoding neutru, adica
8bit, 7bit sau binary.
Daca insa problema este sa obtii ceva cu sens si pentru cel
care citeste mesajul, atunci singura solutie este sa decodezi toate
attachment-urile (text), eventual sa le aduci la un charset comun, apoi
sa le lipesti, si sa le re-encodezi. Asta nu e foarte greu de realizat
in practica (mai putin povestea cu charset-ul): e suficient sa modifici
mimehandle_text(), folosind aceleasi functii de encode / decode ca in
mimehandle_multipart_default(). Recodarea charset-ului e singura parte
nebanala.
O alta solutie este sa re-encodezi attachment-urile text ca 8bit cu
un program extern, inainte sa le trimiti spre Ecartis. Asta rezolva
elegant problema diacriticelor, si te scuteste de a mai modifica
Ecartis. Un program care stie sa faca asta este Emil:
ftp://ftp.sunet.se/pub/unix/mail/emil/
Incantatia urmatoare (sub forma de pipe):
emil -F MIME -T 8bit
va re-encoda attachment-urile text ca 8bit, si va lasa neschimbate
celelalte attachment-uri. Singura problema: Emil a avut si el gauri de
securitate in trecut.
> O tentativa de patch se afla la [1]. Patch-ul e incomplet (pentru ca
> in ultima clipa mi-am dat seama ca am uitat de "7bit", care, atentie,
> este transfer-encoding-ul default, in lipsa unui header explicit) si
> muncitoresc, pentru ca nu-mi sunt familiare sursele ecartis-ului :-)
> Sper totusi sa fie de folos.
Chiar netinand cont de obiectia de fond de mai sus, patch-ul are
multe alte probleme, una dintre ele fiind aceea ca header-ele MIME
trebuie parse-ate (nu le poti aplica strncasecmp() direct).
> E ciudat insa ca nu am reusit cu nici un MUA sa produc un mesaj cu
> primul part base64 si al doilea part 8bit. Si inclin sa cred ca orice
> MUA care stie de base64 NU va encoda un atasament in 8bit la un mesaj
> base64.
Exista MUAs in care poti forta un anume encoding pentru fiecare
attachment (exemplu: Mutt). Dar personal ma astept ca majoritatea
covarsitoare a mesajelor de tipul asta sa nu fie produse de un MUA, ci
de un generator automat, de tip Indy Library sau MIME Tools.
> 4) Problema deschisa: digest-urile?
Daca re-encodezi attachment-urile cum am spus mai sus rezolvi
automat si problema asta.
> Please comment.
Tu ai cerut-o. :-)
> Multumesc pentru atentie :)
Salutari,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
---
Detalii despre listele noastre de mail: http://www.lug.ro/
