Iulian Ursache-Dogariu <[EMAIL PROTECTED]> scria la data de 10 Iunie 2005:
> On Friday 10 June 2005 12:50, Liviu Daia wrote:
> > La o privire sumara, nu cred ca ai identificat corect problema
> > in contextul respectiv. Din cate inteleg eu (inca o data, la o
> > privire sumara), intrebarea la care trebuie sa raspunzi este: de ce
> > nu se decodeaza attachment-ul cand e scris in fisier, nu de ce se
> > schimba Content-Transfer-Encoding acolo. Motivul tine de faptul ca
> > nu e legal sa ai encoding-uri netriviale imbricatem, si asta cred
> > ca era ideea initiala. Pe de alta parte, majoritatea mailer-elor
> > sunt in stare sa decodeze si attachment-uri incodate asa (de pe
> > vremea cand Sun Mailtool trimitea mesaje asa :-)), deci mare paguba
> > probabil nu vei produce. Dar fix-ul nu e moral corect, sau cel
> > putin asa imi pare acum. FWIW.
>
> Whoa! Care attachment-uri?
Din punct de vedere al strucurii MIME, corpul principal al unui
mesaj este tot un attachment, chiar daca nu pare. :-) Vezi RFC 2045
(cred).
> Cum adica "nu e moral corect"?
Adica patch-ul duce la mesaje intr-un format ilegal (desi
majoritatea mailer-elor din ziua de azi ar trebui sa poata sa le
citeasca). Repet, la o prima privire.
> Cred ca esti putin confuz.
Multumesc, asemeni. :-)
> Beleaua e ca mesaje perfect valide devin invalide dupa ce trec prin
> Ecartis DEOARECE _ecartis_ modifica acel header cu de la sine putere.
Ce pari sa omiti tu este ca Ecartis nu modifica numai acest header,
ci (in anumite conditii) intreaga structura MIME a mesajului. Exemple:
digest-urile, optiunea rabid-mime (sau asa ceva), dar si mesaje aparent
mai nevinovate, cum ar fi cele cu caractere accentuate. Vezi RFC
2045-2047 si update-urile lor ca sa intelegi motivele.
> Asta incearca sa rezolve patch-ul lui Mihai.
Adevarat. Afirmatia mea e ca patch-ul elimina o problema si adauga
multe altele.
Salutari,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
---
Detalii despre listele noastre de mail: http://www.lug.ro/
