| Subject: | Mail::IMAPClient doesn’t parse extension data for multipart messages correctly. |
| Date: | Thu, 29 May 2008 07:58:30 -0700 |
| To: | bug-Mail-IMAPClient [...] rt.cpan.org |
| From: | dougimapclient [...] claar.org |
Summary: Mail::IMAPClient doesn’t parse extension data for multipart
messages correctly.
This problem existed in 2.2.9, so I updated to 3.0.7, but it is still there.
Given this bodystructure from IMAP:
8 UID FETCH 22178 BODYSTRUCTURE* 3656 FETCH (BODYSTRUCTURE (("TEXT"
"PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 582 10 NIL NIL NIL)("TEXT"
"HTML" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 672 12 NIL ("inline" NIL)
NIL) "alternative" ("boundary"
"0__=08BBFED2DFFB8B7B8f9e8a93df938690918c08BBFED2DFFB8B7B") ("inline"
NIL) NIL) UID 22178)
I get this BodyStructure from Mail::IMAPClient:
DB<2> p Dumper $bodystructure
$VAR1 = bless( {
'bodyparms' => undef,
'bodyextra' => undef,
'bodyid' => undef,
'_top' => 1,
'bodydisp' => undef,
'_id' => 'HEAD',
'bodysubtype' => 'alternative',
'_prefix' => '',
'bodysize' => 'NIL',
'bodytype' => 'MULTIPART',
'bodystructure' => [
bless( {
'bodyparms' => {
'CHARSET' => 'US-ASCII'
},
'bodyextra' => undef,
'bodyid' => 'NIL',
'bodydisp' => 'NIL',
'bodysubtype' => 'PLAIN',
'bodysize' => '582',
'bodytype' => 'TEXT',
'bodyMD5' => 'NIL',
'textlines' => '10',
'bodylang' => 'NIL',
'bodydesc' => 'NIL',
'bodyenc' => '7BIT'
}, 'Mail::IMAPClient::BodyStructure' ),
bless( {
'bodyparms' => {
'CHARSET' => 'US-ASCII'
},
'bodyextra' => undef,
'bodyid' => 'NIL',
'bodydisp' => {
'inline' => 'NIL'
},
'bodysubtype' => 'HTML',
'bodysize' => '672',
'bodytype' => 'TEXT',
'bodyMD5' => 'NIL',
'textlines' => '12',
'bodylang' => 'NIL',
'bodydesc' => 'NIL',
'bodyenc' => '7BIT'
}, 'Mail::IMAPClient::BodyStructure' )
],
'bodylang' => undef,
'bodydesc' => undef,
'bodyenc' => {
'inline' => 'NIL'
}
}, 'Mail::IMAPClient::BodyStructure' );
RFC3501 says:
Extension data follows the multipart subtype. Extension data
is never returned with the BODY fetch, but can be returned with
a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
the defined order. The extension data of a multipart body part
are in the following order:
body parameter parenthesized list
A parenthesized list of attribute/value pairs [e.g., ("foo"
"bar" "baz" "rag") where "bar" is the value of "foo", and
"rag" is the value of "baz"] as defined in [MIME-IMB].
body disposition
A parenthesized list, consisting of a disposition type
string, followed by a parenthesized list of disposition
attribute/value pairs as defined in [DISPOSITION].
body language
A string or parenthesized list giving the body language
value as defined in [LANGUAGE-TAGS].
body location
A string list giving the body content URI as defined in
[LOCATION].
Applying this to my message, we should get the following:
bodysubtype: "alternative"
bodyparms: ("boundary"
"0__=08BBFED2DFFB8B7B8f9e8a93df938690918c08BBFED2DFFB8B7B")
bodydisp: ("inline" NIL)
bodylang: NIL
Instead, the code appears to produce:
bodysubtype: "alternative"
ignored: ("boundary"
"0__=08BBFED2DFFB8B7B8f9e8a93df938690918c08BBFED2DFFB8B7B")
bodyenc: ("inline" NIL)
bodysize: NIL
Doug Claar
Message body is not shown because it is too large.