The message method get_params() and the related get_param() and
get_filename() do not properly decode an RFC 2231 encoded parameter such
as the following:

Content-Disposition: inline;
filename*0="Re: [Mailman-Users] Messages shunted with \"TypeError: ";
filename*1="decodingUnicode is not supported\".eml"

This is because the message helper function _parseparams() mistakenly
thinks the second semicolon is inside a quoted string because it counts
the quoted (escaped) quote and sees an odd number.

The attached patch will fix this.

Okay, bug confirmed:

>>> m = email.message_from_string('Content-Disposition: inline; filename*0="foo \\"test"; filename*1="\\"bar"')
>>> m.get_filename()
'foo "test"; filename*1=""bar'

And here is the result with the patch applied:

>>> m = email.message_from_string('Content-Disposition: inline; filename*0="foo \\"test"; filename*1="\\"bar"')
>>> m.get_filename()
'foo "test"bar'

Attached a patch. Unit test included.

According to RFC2231 the named disposition (content disposition field) is provided by the MIME mechanism. The encoded parameter like the following:

Content-Disposition: inline;
filename*0="Re: [Mailman-Users] Messages shunted with \"TypeError: ";
filename*1="decodingUnicode is not supported\".eml"

is not behaving the way it should be.
The patch by rcoyner seems fine to me as it rectifies the wrong behaviour of _parseparam i.e. the counting issue of nested 'double quotes' and clears the unit tests.

Thanks Mark and Ryan for the patches, and Shashwat for the review. Committed to trunk in r80062, 2.6 in r80063, py3k in r80078, and 3.1 in r80079.