[Mimedefang] Heads up: MIME::tools 5.500 has problems...
skmimedefang at smail.inf.fh-bonn-rhein-sieg.de
Tue Feb 8 10:00:11 EST 2011
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 8 Feb 2011, David F. Skoll wrote:
> It is; I replied back to myself to that effect.
Sorry, I didn't read the whole thread closely.
>> Maybe a complete split towards MIME::Tools::UTF8 would solve the
>> problem and MIME::Tools returns encoded names only.
> MIME::Tools does return encoded names only anyway. I'd like to get
> rid of all the MIME::Decoder junk and provide one function that decodes
and MIME::WordDecoder ... .
> MIME-encoded words into internal Perl format (essentially Unicode.)
hmm, I tried to find the problem I had in 2008 in MIME::Tools 5.5, but
didn't found it. There was a problem that a MIME:: function returned a
decoded header value (filename) as octet, which I passed back to MIME::*
to create a new part, where it was used verbatim as ASCII.
Maybe it was the rfc2231 encoding. In this case you would need to recode
it into a rfc2047 compliant string, IMHO. So one wouldn't need Encode in
Couldn't you drop the use of MIME::WordDecoder in Filer, too, and use
anonymous filenames? Unless I am mistaken, only the deprecated decode()
function would use MIME::WordDecoder then.
One could leave MIME::Tools ASCII (on-wire format), and one can always
contruct new entities from values got from MIME::Tools functions.
(targets: "I don't believe the original author was consistent in assuming
whether or not recommended_filename had already done the decoding. :(" of
your reply on Thu Jan 27 14:38:55 2011 -> one would need to "unmime"
In conjuntion with a general purpose function, e.g. unmime() or
Encode::MIME::Header::decode(), to decode a MIME string into a perl
Maybe, this is exactly what you've answered on Sat Feb 05 10:22:28 2011.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the MIMEDefang