Your message dated Sun, 31 Jan 2010 20:30:13 +0900
with message-id <[email protected]>
and subject line Re: Bug#555715: libemail-mime-perl: Maybe ought not die on
illegal subject encodings...
has caused the Debian Bug report #555715,
regarding libemail-mime-perl: Maybe ought not die on illegal subject
encodings...
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
555715: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555715
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libemail-mime-perl
Version: 1.863-1
Severity: important
Okay, I've been hesitating filing this one, and actually hesitated where
send it, since it involves this package as well as perl base itself (which
contains Encode and Encode::MIME::Header). Feel free to reassign,
reprioitise, sodomise, etc, just try not to ignore if possible.
Email::MIME::header easily dies on illegal subjects, like
=?134?Q?China_Chamber_of_International_Commerce_,__Qingdao_C...
with
Unknown encoding "134" at /usr/lib/perl/5.10/Encode.pm
Surely, it is unknown, but it became extremely common to do this for spam,
and it's not useful to croak on it. The problem is that the whole processing
chain just loves to croak on that:
/usr/lib/perl/*/Encode/MIME/Header.pm does everywhere
/usr/lib/perl/*/Encode.pm follow the line
and /usr/share/perl5/Email/MIME.pm just calls them and hopes the best, and
in this case 'best' never gonna happen.
I am not sure it's proper of Encode to croak on illegal encoding, but since
it's in base perl I tend to look it as "they have probably more insight than
me". But I guess then Email::MIME should protect against death with an
eval{} block, and handle the situation gracefully, and return undef for
unparseable headers requested to be parsed.
Right now I have to eval{} every parse->subject to avoid death but this
isn't pretty nice to ask for when end user usually want either decoded heaer
or nothing, but hardly exiting of the program.
I trust you have better insight, so I let you to decide whether I'm wrong,
or if not who should fix this and how. I would eval{} all Encode calls in
Email::MIME and handle the errors, and in my daring moments I'd even fix
Encode:: parts not to croak but return undef. :-)
Thanks.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (2000, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.31.3.bfs304-narya2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=hu_HU (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash
Versions of packages libemail-mime-perl depends on:
ii libemail-mime-contenttype-per 1.014-3 Parse a MIME Content-Type Header
ii libemail-mime-encodings-perl 1.313-1 unified interface to MIME encoding
ii libemail-simple-perl 2.004-1 Simple parsing of RFC2822 message
ii libmime-types-perl 1.28-1 Perl extension for determining MIM
ii perl 5.10.1-5 Larry Wall's Practical Extraction
libemail-mime-perl recommends no packages.
libemail-mime-perl suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 1.863-1
Hi,
as gregor noted [1] this bug is fixed in libemail-mime-perl/1.863-1.
I'm thus closing this bug report.
Regards,
Ansgar
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555715#12
--- End Message ---
