Bug #41632 for MIME-tools: MIME::Field::ParamVal mishandles mixed RFC2231 and non-RFC2231 parameters

Ben Winslow via RT wrote: Show quoted text
I would call that a bug in Apple Mail. The (incredibly awful and badly-written RFC 2231) is silent about what to do when you have mixed-style parameters like that. Apple is therefore relying on unspecified behaviour. Show quoted text
The RFC does explicitly say: "...the mechanism MUST NOT depend on parameter ordering since MIME states that parameters are not order sensitive." So how would we handle this: Content-Disposition: inline; filename*1=" blech"; filename="foo bar"; filename*0="foo"; It so happens that with Apple Mail, filename matches the concatenation of filename*n. But I don't think MIME::Tools should incorporate code to work around broken MIME generators. Regards, David.

On Fri Dec 12 10:36:36 2008, DSKOLL wrote: Show quoted text
Show quoted text
unspecified Show quoted text
Well, the RFC explicitly states that parameter value continuations are meant to prevent damage to the value by header wrapping. Leading whitespace is fine when wrapping headers, but it might not be fine when gluing together a parameter -- one of the examples in the RFC is an URI (for the rarely used message/external-body type), where whitespace in the URI is obviously wrong. It seems logical to me, then, that the RFC2231-style values should always be preferred when present -- the non-RFC2231 value is only useful for reverse compatibility. While the RFC should definitely have stated this explicitly, I think it's reasonable to treat the non-RFC2231 value this way (and I'm sure this probably seemed obvious when RFC2231 was written and nothing supported it yet.) Show quoted text
Good point. Show quoted text
Okay, perhaps simply assigning the non-RFC2231 value to part 0 is naïve -- that's easy enough to fix, and I'll post an updated patch later today. I still think the RFC2231 value should be used ("foo bleh"), as the non-RFC2231 filename may simply be a reduced version of the RFC2231 filename; for example, a file named "genetisch geänderte Mörderkaninchen.jpg" could be sent as: Content-Disposition: inline; filename*0*=iso-8859-1'de'genetisch%20ge%E4nderte%20M%F6rderkan; filename*1="inchen.jpg"; filename="genetisch geaenderte Moerderkaninchen.jpg" In this case, I'd want to use the RFC2231 version if I knew how to parse it. Show quoted text
We could argue all day about whether Apple Mail's behavior is correct or not, but Apple Mail does behave this way right now, and real people are sending real messages with it. Failure to cope with these messages (especially in a gray area between standards) isn't very robust, and parsing the message differently than MUAs are parsing it doesn't benefit anyone. Show quoted text
Just for reference, my (very quick) testing with RFC2231-style attachment filenames before, after, and surrounding the non-RFC2231 filename turned up the following: Thunderbird - Always uses the non-RFC2231 header when both are present Claws-mail - Always uses the RFC2231 header when both are present Opera Mail - Uses whichever version appears first (even when mixed) Squirrelmail - No support for RFC2231; no support for filename in Content-Disposition; attachment is untitled unless non-RFC2231 version is present Outlook Express 6.00.2800.1933 - No support for RFC2231; no support for filename in Content-Disposition; attachment is untitled unless non-RFC2231 version is present Outlook 2000 - No support for RFC2231; no support for filename in Content-Disposition; attachment is untitled unless non-RFC2231 version is present It's clear that RFC2231's ambiguity has lead to inconsistent support, but MIME::Field::ParamVal's current behavior isn't in line with the way anyone else seems to be supporting it.

Hi, Please try this patch... it ignores the non-RFC-2231 parameter if at least one RFC-2231 parameter is present. It should apply cleanly to MIME-tools-5.427 diff --git a/MANIFEST b/MANIFEST index 0d79335..c93adb3 100644 --- a/MANIFEST +++ b/MANIFEST @@ -73,6 +73,7 @@ t/Ref.t t/Smtpsend.t t/ticket-11901.t t/ticket-37139.t +t/ticket-41632.t t/WordDecoder.t t/WordEncoder.t t/Words.t diff --git a/lib/MIME/Field/ParamVal.pm b/lib/MIME/Field/ParamVal.pm index 715c628..527d0db 100644 --- a/lib/MIME/Field/ParamVal.pm +++ b/lib/MIME/Field/ParamVal.pm @@ -268,13 +268,18 @@ sub parse_params { } $rfc2231params{$name}{$num} .= $val; } else { - # Make a fake "part zero" for non-RFC2231 params - $rfc2231params{$param}{"0"} = $val; + # Make a special part for non-RFC2231 params + $rfc2231params{$param}{"-1"} = $val; } } # Extract reconstructed parameters foreach $param (keys %rfc2231params) { + # If we have RFC2231 parts and a non-RFC2231 part, don't + # use the non-RFC2231 part. + if (exists($rfc2231params{$param}{"-1"}) && scalar(keys(%{$rfc2231params{$param}})) > 1) { + delete($rfc2231params{$param}{"-1"}); + } foreach $part (sort { $a <=> $b } keys %{$rfc2231params{$param}}) { $params{$param} .= $rfc2231params{$param}{$part}; } diff --git a/t/ticket-41632.t b/t/ticket-41632.t new file mode 100644 index 0000000..122f211 --- /dev/null +++ b/t/ticket-41632.t @@ -0,0 +1,22 @@ +use strict; +use warnings; + +use Test::More tests => 4; + +# Handle the case of both RFC-2231 and non-RFC-2231 parameter values. +# In this case, we ignore the non-RFC-2231 parameters + +use MIME::Field::ParamVal; + +my $params; + +$params = MIME::Field::ParamVal->parse_params('inline; filename="foo"; filename*1="ar"; filename*0="b"'); + +is($params->{'_'}, 'inline', 'Got the "inline" right'); +is($params->{'filename'}, 'bar', 'Ignored non-RFC-2331 value if RFC-2231 parameters are present'); + +$params = MIME::Field::ParamVal->parse_params('inline; filename="foo"'); +is($params->{'filename'}, 'foo', 'Got filename if RFC-2231 parameters are absent'); + +$params = MIME::Field::ParamVal->parse_params('inline; filename*1="ar"; filename*0="b"'); +is($params->{'filename'}, 'bar', 'Got RFC-2231 value');

On Fri Dec 12 16:19:56 2008, DSKOLL wrote: Show quoted text
Excellent! This works for me. Show quoted text
Thanks again, Ben