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. 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). In mesajul original, fiecare part MIME poate fi encodat in propriul sau transfer-encoding. Numai ca dupa de-MIME-ificare, mesajul rezultat trebuie sa aiba un singur transfer-encoding. 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. 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. - 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. - 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**. 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. 3.2. In cazul mesajelor multipart: Solutia ideala ar fi sa decodam fiecare part in mod corespunzator si sa le aducem la 8bit. 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. 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. 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. 4) Problema deschisa: digest-urile? Please comment. Multumesc pentru atentie :) i. [1] http://devel.jayomega.net/tmp/ecartis_1.0.0_permissive_tranfer_encoding.diff -- Iulian Ursache-Dogariu | iulianu at | GPG Key ID: 0x92B1C594 jabber:[EMAIL PROTECTED] | gmx dot net | http://www.jayomega.net -- "Live as if you were to die tomorrow. Learn as if you were to live forever." (Gandhi) --- Detalii despre listele noastre de mail: http://www.lug.ro/
