Long filenames with single quotes appear to be unparsable.

[murphatron]

Hello! We're utilizing this package to parse and display MIME messages we have in storage to the user. I'm encountering an error that occurs when the package attempts to parse an attachments Content-Disposition header with a filename utilizing parameter value continuation.

The header set for the attachment part looks like:

Content-Disposition: attachment;
    filename*0="1 Neuropathy 'Trick' Reverses Diabetic Nerve Pain? -Try Tonight.";
    filename*1=eml
Content-Type: message/rfc822;
    name="1 Neuropathy 'Trick' Reverses Diabetic Nerve Pain? -Try Tonight.eml"
Content-Transfer-Encoding: binary

And the reported error is:

iconv(): Wrong charset, conversion from `1 Neuropathy ' to `UTF-8//TRANSLIT//IGNORE' is not allowed

As you can see, the sender is forwarding an attached spam email which is resulting in this break. From what I can tell, it's the single quotes that seem to be creating the invalid assumption that the "1 Neuropathy " string segment is a charset and "Trick" string segment is the language.

[murphatron]

To expand a bit more, reading RFC2231, in order for parameter continuation and parameter value charset+language to be combined, the syntax of the parameter name to be filename*0* in this example (note it ends with a asterisk). The parameter naming convention from my email seems to imply that it should only be interpreted as continuation, not continuation with charset+language.

EDIT: I think the error might be here. This evaluation would result in $isEncoded simply if the parameter continuation index is 0.

[zbateson]

Hi @murphatron -- looks like it's a simple parsing issue as you discovered, thanks for reporting will look at this soon :)

[zbateson]

Fixed and released in 2.0.1 and 1.3.3. Feel free to reopen if you notice any issues.