It should not be raising an error message at all. The contract of the email module is that it does not raise errors when parsing, instead it registers defects. Now, granted, the old API mostly does this during initial parsing, But see, for example, how get_payload handles base64 decoding defects. (Not that that is great code, but it is the available example for the old API).

As for the defects, here is some code that shows what the new API produces:

import email, email.policy

message = email.message_from_string("""\
Content-Type: application/x-foo;
    name*0="foo";
    name*="bar"

Foo
""", policy=email.policy.default)

print(message['content-type'])
print(message['content-type'].defects)
print(message['content-type'].content_type)
print(message['content-type'].params)
print(message['content-type'].params['name'])

And here is the output it produces on master:

application/x-foo; name="foo"
(InvalidHeaderDefect('Parameter marked as extended but appears to have a quoted string value that is non-encoded'), InvalidHeaderDefect('Missing required charset/lang delimiters'), InvalidHeaderDefect('duplicate parameter name; duplicate(s) ignored'))
application/x-foo
{'name': 'foo'}
foo

Note that these defects are registered during initial parsing. It is better to use the new API.

Thanks for the patch, though. And in fact, since the old API is kind of broken in a lot of ways anyway, I wouldn't actually object to just using your fix if other people think it is OK.

Thanks for the explanation! I wasn't aware this was part of the old API. I'll let others weigh in on this, but since it's part of the old API, perhaps it's better to leave it as it is then?