Skip Menu |
 

This queue is for tickets about the MIME-tools CPAN distribution.

Report information
The Basics
Id: 65162
Status: resolved
Priority: 0/
Queue: MIME-tools

People
Owner: dfs+pause [...] roaringpenguin.com
Requestors: Mark.Martinec [...] ijs.si
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Wed, 26 Jan 2011 19:02:47 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 837b
A change RT #63739 between MIME-tools-5.428 and MIME-tools-5.500 is now causing mail parsing to flop fatally with a die() in MIME::Words. The problem occurs because the MIME decoding of Content-Type.name (and similar fields) now occurs twice: once in MIME/Field/ParamVal.pm converting the file name to Perl characters (Unicode), then again in MIME::Words::decode_mimewords called from MIME::WordDecoder::decode, which dies on seeing a non-byte character. To reproduce: $ perl -MMIME::Parser -e 'MIME::Parser->new->parse(\*STDIN)' <0.txt MIME::Words: unexpected case: (βCURE.txt) pos 0 Please alert developer. A sample message 0.txt: From: test@example.com Subject: test Date: Tue, 25 Jan 2011 14:35:04 +0100 Message-Id: <123@example.com> Content-Type: text/plain; name*=utf-8''%CE%B2CURE%2Etxt test Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Wed, 26 Jan 2011 14:16:41 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 191b
Hi, Thanks for your bug report. Could you please try the attached patch? I feel quite dirty doing it this way, but it was the only sensible solution I could come up with. Regards, David.

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Wed, 26 Jan 2011 21:11:12 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 1.2k
David, Thanks, that was quick! Show quoted text
> Could you please try the attached patch? I feel quite dirty > doing it this way, but it was the only sensible solution > I could come up with.
Well, it does fix the immediate issue, although I fear it might break some expected uses (like banned filenames checks in amavisd :) The sample message (having a name: utf-8''%CE%B2CURE%2Etxt ) as returned by $head->mime_attr('content-type.name') and as $head->recommended_filename yielded a \316\262CURE.txt with 5.428, and a \x{03b2}CURE.txt with 5.500. Either of the two choices made a sensible candidate for checking rules. Now both attributes give =?UTF-8?B?zrJDVVJFLnR4dA==?=, so a caller must now do a 'MIME-Header' decoding (which is what I expected the change in #63739 tried to avoid). The docs on mime_attr() doesn't say anything about re-encoding attributes from RFC 2184 into RFC 2047 form. Perhaps we need an additional method besides mime_attr(), e.g. a mime_attr_raw, which could provide a: utf-8''%CE%B2CURE%2Etxt in case of this sample message. Then the mime_attr could continue to provide a decoded name, either as UTF-8 encoded bytes, or as perl Unicode characters. Somehow it sounds wrong that the MIME::WordDecoder::decode even tried to decode what was known to already have been decoded. Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Wed, 26 Jan 2011 15:43:39 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 1.7k
On Wed, 26 Jan 2011 15:11:28 -0500 "Mark.Martinec@ijs.si via RT" <bug-MIME-tools@rt.cpan.org> wrote: Show quoted text
> Well, it does fix the immediate issue, although I fear it might break > some expected uses (like banned filenames checks in amavisd :)
Yes, it's not a good solution. Show quoted text
> Either of the two choices made a sensible candidate for checking > rules. Now both attributes give =?UTF-8?B?zrJDVVJFLnR4dA==?=, > so a caller must now do a 'MIME-Header' decoding (which is > what I expected the change in #63739 tried to avoid). > The docs on mime_attr() doesn't say anything about > re-encoding attributes from RFC 2184 into RFC 2047 form.
Right. The problem is that RFC 2184 is completely evil. Consider something like: Content-Type: text/plain; name*0*=ISO-8859-1''%61%74%74 name*1*=UTF-8''Something_else name*2*=BIG5''%FE%45 I think the only sensible thing is to return a utf-8 value because utf-8 is a superset of all the other encodings. The only question is whether to return a native Perl UTF-8 string or the horrible re-encoded =?UTF-8?B?....?= string. MIME::tools is ancient and creaky and needs an overhaul. :( Show quoted text
> Perhaps we need an additional method besides mime_attr(), e.g. > a mime_attr_raw, which could provide a: utf-8''%CE%B2CURE%2Etxt > in case of this sample message. Then the mime_attr could continue > to provide a decoded name, either as UTF-8 encoded bytes, or as > perl Unicode characters.
The issue is that RFC 2184 allows you to mix different encodings in the same parameter. The rest of the MIME::tools API does not handle that well. Show quoted text
> Somehow it sounds wrong that the MIME::WordDecoder::decode > even tried to decode what was known to already have been decoded.
Yes, I agree. Let me dig into the code a bit more to see if I can come up with a better fix. Regards, David.
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Wed, 26 Jan 2011 15:47:43 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 344b
On Wed, 26 Jan 2011 15:43:39 -0500 "David F. Skoll" <dfs@roaringpenguin.com> wrote: Show quoted text
> Content-Type: text/plain; > name*0*=ISO-8859-1''%61%74%74 > name*1*=UTF-8''Something_else > name*2*=BIG5''%FE%45
Never mind; I'm an idiot... you can't change encoding within the same parameter (according to RFC 2184) Regards, David.
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Wed, 26 Jan 2011 22:18:06 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 607b
Show quoted text
> I think the only sensible thing is to return a utf-8 value because > utf-8 is a superset of all the other encodings. The only question > is whether to return a native Perl UTF-8 string or the horrible > re-encoded =?UTF-8?B?....?= string. MIME::tools is ancient and creaky > and needs an overhaul. :(
Agreed. Sounds to me like the properly decoded and then utf-8 encoded (as a string of octets) form would cause least surprise. This is what 4.* was returning, so it remains compatible, while solving the previous sloppy decoding. I would settle for a native Perl Unicode character string too. Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 27 Jan 2011 02:44:01 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 818b
Show quoted text
> > I think the only sensible thing is to return a utf-8 value because > > utf-8 is a superset of all the other encodings. The only question > > is whether to return a native Perl UTF-8 string or the horrible > > re-encoded =?UTF-8?B?....?= string. MIME::tools is ancient and creaky > > and needs an overhaul. :(
> > Agreed. Sounds to me like the properly decoded and then utf-8 > encoded (as a string of octets) form would cause least surprise. > > I would settle for a native Perl Unicode character string too.
On a second thought, your suggestion of native Perl string makes more sense to me now (not utf-8 encoded octets, and certainly not re-encoded to mime =?...? encoding). So that would be what 5.500 returns now, if it would not die. (it doesn't die if a caller supplies his own $parser->filer) Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 27 Jan 2011 10:33:09 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Hi, Mark, Show quoted text
> On a second thought, your suggestion of native Perl string > makes more sense to me now (not utf-8 encoded octets, and > certainly not re-encoded to mime =?...? encoding).
OK... please try this much simpler patch. Regards, David. diff --git a/lib/MIME/Words.pm b/lib/MIME/Words.pm index 92824c5..d8aac7d 100644 --- a/lib/MIME/Words.pm +++ b/lib/MIME/Words.pm @@ -211,7 +211,7 @@ sub decode_mimewords { ### Case 3: are we looking at ordinary text? pos($encstr) = $pos; # reset the pointer. if ($encstr =~ m{\G # from where we left off... - ([\x00-\xFF]*? # shortest possible string, + (.*? # shortest possible string, \n*) # followed by 0 or more NLs, (?=(\Z|=\?)) # terminated by "=?" or EOS }xg) { diff --git a/t/attachment-filename-encoding.t b/t/attachment-filename-encoding.t index 54693df..f7e36a8 100644 --- a/t/attachment-filename-encoding.t +++ b/t/attachment-filename-encoding.t @@ -8,7 +8,7 @@ use utf8; binmode STDOUT, ":utf8"; binmode STDERR, ":utf8"; -plan tests => 5; +plan tests => 7; main: { #-- Load MIME::Parser @@ -41,6 +41,16 @@ main: { #-- Check if parsed recommended filename matches the expected string is($filename, "attachment.<C3><A4><C3><B6><C3><BC>", "Parsed filename should match expectation"); + + # CPAN ticket #65162 + # We need the default parser to tickle the bug + $parser = MIME::Parser->new(); + $parser->output_to_core(0); + $parser->output_under('/tmp'); + $entity = $parser->parse_data("From: test\@example.com\nSubject: test\nDate: Tue, 25 Jan 2011 14:35:04 +0100\nMessage-Id: <123\@example.com>\nContent-Type: text/plain; name*=utf-8''%CE%B2CURE%2Etxt\n\ntest\n"); + $filename = $entity->head->recommended_filename; + is(utf8::is_utf8($filename), 1, "Parsed filename should have UTF-8 flag on"); + is($filename, "\x{3b2}CURE.txt", 'Got expected filename'); } #-- Parse quoted printable file and return MIME::Entity
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 27 Jan 2011 19:49:07 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 369b
Show quoted text
> OK... please try this much simpler patch.
Well, it avoids the immediate problem, but allowing implicit nested decoding is evil. Take this one: Content-Type: text/plain; name*=''%3d%3futf-8?b?BEFORE%3f%3d The $entity->head->recommended_filename will report a filename: =?utf-8?b?BEFORE?= yet the file actually generated file will be named: %04AND.dat Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 27 Jan 2011 13:51:36 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 373b
On Thu, 27 Jan 2011 13:49:27 -0500 "Mark.Martinec@ijs.si via RT" <bug-MIME-tools@rt.cpan.org> wrote: Show quoted text
> Well, it avoids the immediate problem, > but allowing implicit nested decoding is evil.
No, there's no nested decoding. Did you apply the patch against a pristine copy of 5.500? The patch replaces my earlier attempt... it shouldn't be added to it. Regards, David.
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 27 Jan 2011 20:16:58 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 613b
Show quoted text
> Did you apply the patch against a pristine copy of 5.500? > The patch replaces my earlier attempt... it shouldn't be added to it.
I did. Show quoted text
> No, there's no nested decoding.
There is, try it for yourself: $ perl -MMIME::Parser -e ' print MIME::Parser->new->parse(\*STDIN)->head->recommended_filename,"\n"' <1.msg =?utf-8?b?BEFORE?= $ ll -tr | tail -3 -rw-r----- 1 xxx xxx 5 Jan 27 20:13 %04AND.dat 1.msg: From: test@example.com Subject: test Date: Tue, 25 Jan 2011 14:35:04 +0100 Message-Id: <123@example.com> Content-Type: text/plain; name*=''%3d%3futf-8?b?BEFORE%3f%3d test Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 27 Jan 2011 14:38:45 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 360b
Hi, OK... I see the problem. This will take me some time to untangle. In some places, recommended_filename is preceded with an unmime call and in others it is not. I don't believe the original author was consistent in assuming whether or not recommended_filename had already done the decoding. :( For now, I'd recommend not using 5.500. Regards, David.
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Mon, 31 Jan 2011 16:04:52 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 498b
Hi, So far, what I've come up with is the attached patch against 5.500. It's pretty evil. We have to re-encode rfc2231-encoded parameters; I choose to encode them as =?UTF8?B?....?= That's because everything else in MIME::tools assumes that $head->mime_attr(...) gets encoded MIME-words. $head->recommended_filename now decodes the parameter it gets back. It returns an internal Perl string that may have the UTF-8 flag set. Please let me know how this patch works for you. Regards, David.
Download mime-tools.diff
text/x-diff 13.7k

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Tue, 1 Feb 2011 20:23:13 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 611b
Show quoted text
> So far, what I've come up with is the attached patch against 5.500. > It's pretty evil. > We have to re-encode rfc2231-encoded parameters; I choose to encode > them as =?UTF8?B?....?= > That's because everything else in MIME::tools assumes that > $head->mime_attr(...) gets encoded MIME-words. > $head->recommended_filename now decodes the parameter it gets back. > It returns an internal Perl string that may have the UTF-8 flag set. > > Please let me know how this patch works for you.
Thanks! So far so good, it seems it does the job. Let me observe our logs for a day or two before committing. Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Fri, 4 Feb 2011 01:26:16 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 1.5k
Show quoted text
> $head->recommended_filename now decodes the parameter it gets back. > It returns an internal Perl string that may have the UTF-8 flag set.
That is very nice now. Show quoted text
> We have to re-encode rfc2231-encoded parameters; > I choose to encode them as =?UTF8?B?....?= > That's because everything else in MIME::tools assumes that > $head->mime_attr(...) gets encoded MIME-words.
I would prefer to retain the same character set *and* language information, just transcode rfc2231 into rfc2047 Q-encoding. This would allow a mail scanning software to obtain richer original information about MIME attributes for names, avoiding a 'Lost in translation' syndrome :) Please try my attached patch. It applies on top of yours. I started implementing my suggestion above, but ended up also fixing some potentially lurking taint issues regarding global $1, $2, ... variables [perl #67962, fixed in perl 5.13], and removed some redundancies (like assigning an empty hash to a known empty (just created) hash, saves 6 perl opcodes), and replacing a $ with \z in some regexps where we really want to match the end-of-string, not some complex interpretation of the end-of-something. I also think that the changed code now better follows rfc2231: the 'chset'lang' decoding should not be applied independently to each continuation, but only when parts are already assembled (see example in rfc2231 section 4.1). Also, this decoding only applies when a final '*' enables it, otherwise it does not apply. I have one terminology concern regarding the name chosen for the new 'UTF-8' decoder in WordDecoder.pm, but more on this perhaps next time. Mark
Download 0.diff
text/x-diff 4.8k

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Fri, 4 Feb 2011 10:16:34 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 759b
Hi, Mark, Show quoted text
> I would prefer to retain the same character set *and* language > information, just transcode rfc2231 into rfc2047 Q-encoding.
That's a good suggestion. I agree it's a better option. Show quoted text
> Please try my attached patch. It applies on top of yours.
I tried it and all tests pass, so I think it's good. Show quoted text
> I also think that the changed code now better follows rfc2231: > the 'chset'lang' decoding should not be applied independently > to each continuation, but only when parts are already assembled
Yep. Show quoted text
> I have one terminology concern regarding the name chosen for > the new 'UTF-8' decoder in WordDecoder.pm, but more on this > perhaps next time.
OK. Let me know. :) I've applied your patch and committed it in my git repo. Regards, David.
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Fri, 4 Feb 2011 19:20:34 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 3.6k
Show quoted text
> I've applied your patch and committed it in my git repo.
Thanks! Show quoted text
> > I have one terminology concern regarding the name chosen for > > the new 'UTF-8' decoder in WordDecoder.pm, but more on this > > perhaps next time.
> > OK. Let me know. :)
I can understand that WordDecoder.pm probably pre-dates the Perl native handling of Unicode, so its structure, documentation and examples probably reflect that. From a current point of view, its terminology can be confusing (and it was for me, took several passes of browsing through code to grasp what it is that it is supposed to do). As I (think I) understand it now, it offers a couple of simple *transcoders* with poorly defined semantics, plus one genuine decoder (the 'UTF-8'). I'll try to explain the underlying conceptual model in Perl parlance, the way I see it was supposed to be, or at least the way I would expect it (bear with me, I know the steps 2 and 3 are integrated): 1. text in RFC 2047 is *decoded* into chunks, each chunk is a pair of: a character set name (with optional language), plus a string of octets. A non- RFC 2047 string is just represented as an empty (unknown) character set name, plus a verbatim copy of octets. This first step is done by MIME::Words::decode_mimewords, called from decode(). 2. the list of chunks (chset+octets) is further *decoded* into Perl native (Unicode) characters (not bytes) (we must not care or believe-we-know-better how it is represented internally). The resulting strings from all chunks are joined, forming a correct native characters string representation of a text from a mail header field. 3. the native character string is then optionally *encoded* into a requested encoding, resulting in a string of octets, i.e. an external representation of the given text in the requested encoding. The provided 'UTF-8' "decoder" is indeed the only true *decoder*, skipping the last encoding step. It does the #1 and #2, and returns a native perl characters string. Its name 'UTF-8' is a misnomer and is misleading, one would expect from its name that it does the final step #3 and encodes into UTF-8, but it doesn't, it returns a native (Unicode) string. In my view it should be renamed to something like 'native' or 'Unicode' or 'perl string'. Remaining traditional "decoders" are actually *transcoders*. They integrate steps #2 and #3 into one operation, and do it halfheartedly: for example given an RFC 2047 text in Latin-15 and transcoding it into Latin-1, a small handful of characters does not have their equivalent and should be nuked (by '?' or whatever), the rest is fine and can be retained. For completeness one might expect there exists a 'UTF-8' *transcoder*, which would as a step #3 encode the native string into UTF-8 octets and return that. It would be even better if one could provide an arbitrary encoding (known to Perl) as an argument to such a general-purpose transcoder - it should be trivial to implement, just needs to call Encoder::encode on a native string as obtained from step #2. I think at least the documentation should be updated, some examples are misleading (like the: ### Decode a MIME string (e.g., into Latin1) via the default decoder: $str = $wd->decode('To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld>'); which somehow leads a reader into thinking that the #3 encoding "into Latin1" is in any way related to the "ISO-8859-1" in the example RFC 2047 string), and perhaps the 'UTF-8' *decoder* renamed or at least documented that it is *not* a *transcoder* like all the rest, and maybe an 'UTF-8' *transcoder* implemented. Just though I should relieve it off my chest, sorry for being long and for giving you a headache :) Regards Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Sat, 5 Feb 2011 10:22:13 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 819b
On Fri, 4 Feb 2011 13:20:55 -0500 "Mark.Martinec@ijs.si via RT" <bug-MIME-tools@rt.cpan.org> wrote: [Thoughts about "decoding" vs "transcoding"] I agree with all of your points. :) Maybe I'll call the UTF-8 decoder MIME::WordDecoder::PerlString to make it clear it decodes to an internal Perl string. In the long term, I need to take a chainsaw to that code. It was written for ancient Perl and most of it's pretty lousy. It's time to stop worrying about Perl 5.6. :) I think we should only have one function: MIME-encoded string => internal Perl string. If you want to transcode to another character set, that's what Perl's Encode module is for. I will write a helper global function called "mimewords_to_perl_string" or something, and start deprecating all of the other decoding functions. Regards, David.
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Sun, 6 Feb 2011 01:35:40 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 911b
Show quoted text
> [Thoughts about "decoding" vs "transcoding"] > I agree with all of your points. :) Maybe I'll call the > UTF-8 decoder MIME::WordDecoder::PerlString to make it clear > it decodes to an internal Perl string.
Yes, that would be nice. Show quoted text
> In the long term, I need to take a chainsaw to that code.
:) Show quoted text
> It was written for ancient Perl and most of it's pretty lousy. > It's time to stop worrying about Perl 5.6. :) > > I think we should only have one function: MIME-encoded string => > internal Perl string. If you want to transcode to another character > set, that's what Perl's Encode module is for.
Agreed, that's a sensible thing to do. No need to duplicate functionality offered by the Encode module. Show quoted text
> I will write a helper global function called "mimewords_to_perl_string" > or something, and start deprecating all of the other decoding functions.
Thanks for your understanding and efforts! Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 17 Feb 2011 12:03:59 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 581b
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Mark, Please try: http://www.roaringpenguin.com/MIME-tools-5.501.tar.gz Signature: http://www.roaringpenguin.com/MIME-tools-5.501.tar.gz.sig My public key: http://www.roaringpenguin.com/files/dskoll-key-2005.txt Please DO NOT distribute this because it isn't yet the "official" 5.501 release. Regards, David. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFNXVT/wYQuKhJvQuARAqmKAJ9QHk/XTvYdhCzuGuvRK/qM4GU8hACgmPfY IdGVz7s0J+GccZDls2cj9cA= =JW7F -----END PGP SIGNATURE-----
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 17 Feb 2011 19:12:41 +0100
To: bug-MIME-tools [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Download (untitled) / with headers
text/plain 516b
Show quoted text
Thanks, looks good, works as expected! (tested with amavisd-new) Btw, one unrelated minor wish: could you please increase a bit the 2 kB I/O buffer size in MIME/Entity.pm and MIME/Body.pm, perhaps to 4k or 8k. For some operations I need to pass my own perl methods as a tied glob to MIME-tools, which end up being accessed (read) through MIME::Entity::print_body. Larger buffer would reduce a bit the overhead of calls for large mail. Mark
Subject: Re: [rt.cpan.org #65162] Double-decoding failure in 5.500, caused by a 'fix' #63739
Date: Thu, 17 Feb 2011 13:17:57 -0500
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 304b
On Thu, 17 Feb 2011 13:12:55 -0500 "Mark.Martinec@ijs.si via RT" <bug-MIME-tools@rt.cpan.org> wrote: Show quoted text
> Btw, one unrelated minor wish: could you please increase a bit > the 2 kB I/O buffer size in MIME/Entity.pm and MIME/Body.pm, > perhaps to 4k or 8k.
Sure. I've increased it to 8k. Regards, David.
Hello, I believe the just-released 5.501 version of MIME::tools fixes this bug. Regards, David.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.