Skip Menu |

This queue is for tickets about the Mail-IMAPClient CPAN distribution.

Report information
The Basics
Id: 133496
Status: patched
Priority: 0/
Queue: Mail-IMAPClient

People
Owner: PLOBBES [...] cpan.org
Requestors: rhesa [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Parse failure on BODYSTRUCTURE response with undocumented extension fields
Hi! I ran into this in the wild: * 7 FETCH (BODYSTRUCTURE (("TEXT" "plain" ("charset" "utf-8") NIL NIL "base64" 534 8 NIL NIL NIL NIL NIL NIL)("TEXT" "html" ("charset" "utf-8") NIL NIL "base64" 1266 18 NIL NIL NIL NIL NIL NIL) "alternative" ("boundary" "--_com.samsung.android.email_2722452845804670") NIL NIL NIL NIL NIL) UID 1139) This came from an Axigen IMAP server (not under my control). As you can see, it has several extraneous NIL fields in each part. I have read the IMAP specs in rfc3501 and did not see a reference to additional params after body location, but it does say body location A string list giving the body content URI as defined in [LOCATION]. Any following extension data are not yet defined in this version of the protocol, and would be as described above under multipart extension data. That last paragraph gives me enough justification for adding a placeholder for these undefined extension fields. I have prepared a PR in github for your consideration. I did not include the regenerated parsers, because it would add a lot of noise to the PR. If you want, I can still add a commit for that of course.
Accepted the pull request on github. This fix will be in the next release. Thanks for the contribution!
commit c4a759941711dc562d5a4ab50854c902365a7d07 Author: Rhesa Rozendaal <github@rhesa.com> Date: Mon Oct 12 03:38:37 2020 +0200 rt.cpan.org#133496: allow for undocumented BODYSTRUCTURE extensions