Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Sun__5_Dec_2004_15_32_13_+0000_edjipQKK7BECCtuF" --Signature=_Sun__5_Dec_2004_15_32_13_+0000_edjipQKK7BECCtuF Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 5 Dec 2004 09:09:56 -0300 "Santiago Vazquez" <[email protected]> wrote: SV> Si, lo que pasa es que tiene la codificacion MIME rota... los clientes SV> no entienden los parts y por lo tanto sale todo en us-ascii a pesar SV> del charset=3DISO-8859-1 que tiene por ah=ED... SV>=20 SV> El problema esta despues de la separacion de las cabeceras..tiene una SV> especie de boundary colgado por ah=ED, sin la cabecera mime. SV>=20 SV> Enrique, puede ser que el sylpheed este haciendo algo mal? SV>=20 SV> Santiago Vazquez Es un viejo problema, no solucionado, que me sucede con algunas combinaciones de MTA/antivirus/antispam (pero no con todas). Ya hace tiempo que Vicente, de ourproject (donde esta alojada la lista) lo estuvo viendo, pero al parecer no le encontro el aujero'el mate. El defecto es que algun programa en el medio (desde que mi mensaje sale a la red hasta que les llega a ustedes) inserta un retorno donde _no_ debe: entre el `boundary' y el indicador de Content-Type puestos originalmente. Mis candidatos a ``malo de la pelicula'' son el Amavis y el Spam Assassin del manejador de la lista. A ver si me explico:=20 (A) cuando sale, mi mensaje tiene en los headers lo siguiente: Content-Type: multipart/signed; protocol=3D"application/pgp-signature"; micalg=3D"pgp-sha1"; boundary=3D"Signature=3D_Sat__4_Dec_2004_14_19_30_+0000_QtMEeco5_MxSrFR+" El mensaje, entonces es: <headers> ... Mime-version: 1.0 Content-Type: multipart/signed; protocol=3D"application/pgp-signature"; micalg=3D"pgp-sha1"; boundary=3D"XXX" </headers> <cuerpo> --XXX Content-Type: text/plain; charset=3DISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable texto texto texto --[space] .signature --XXX Content-Type: application/pgp-signature [Firma GPG] --XXX </cuerpo> (B) El gestor de la lista reencapsula, insertandole un nuevo boundary Entonces el mensaje queda asi: <headers> ... Content-Type: multipart/mixed; boundary=3D"=3D=3DYYY" ... </headers> <cuerpo> --=3D=3DYYY [\n]<--------(1) Content-Type: multipart/signed; protocol=3D"application/pgp-signature"; micalg=3D"pgp-sha1"; boundary=3D"XXX" <-------(2) --XXX Content-Type: text/plain; charset=3DISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable texto texto texto --[space] .signature --XXX Content-Type: application/pgp-signature [Firma GPG] --XXX-- --=3D=3DYYY Content-Type: text/plain; charset=3D"iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [pie de solar] --=3D=3DYYY-- </cuerpo> (A) es como el mensaje sale de mi maquina (por las dudas, lo=20 verifique con tcpdump :)) (B) es como ustedes lo reciben (yo tambien lo recibo asi de mutilado cuando me llega de la lista) Notaran en (B) la marca (1): alli el programa maldito puso un retorno, que para hacer visible identifique con [\n]. (2) era el boundary original. Como ven, todo el quilombo se arma en (1). De m=E1s est=E1 decir que las marcas (1) y (2) no aparecen en el mensaje, sino que las puse yo para se=F1alar la fuente del quilombo. Ideas? Algun otro usuario de Sylpheed en la lista? Porque si hay otro usario de Sylpheed que genere mensajes de caracteristicas parecidas a los mios, y aparecen bien, entonces la cagada la esta haciendo el relay de mi ISP (improbable, pero a seguro lo bajaron en La Tablada). Toda ayuda sera agradecida. Mientras tanto, para los que usen sistemas de correo que almacenan en mh o maildir (en lugar del maldito mbox), la solucion transitoria es tomar el mensaje, editarlo para quitarle el retorno "pirata", et voila! Tambien se puede hacer con mbox, pero editar esos archivos kilometricos es un incordio. --=20 ``Izena duen guzia omen da.'' --Signature=_Sun__5_Dec_2004_15_32_13_+0000_edjipQKK7BECCtuF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkGzKgQACgkQjhuyRoeKKlz9QwCgjcKe/Pu2OSJf9Py8Nsd7S4HP bRcAmwQOsyx624ykmJANSWXtX01YqvGB =KFl6 -----END PGP SIGNATURE----- --Signature=_Sun__5_Dec_2004_15_32_13_+0000_edjipQKK7BECCtuF--