A NOTE has been added to this issue. ====================================================================== http://www.dbmail.org/mantis/view.php?id=996 ====================================================================== Reported By: dfroe Assigned To: ====================================================================== Project: DBMail Issue ID: 996 Category: IMAP daemon Reproducibility: always Severity: major Priority: normal Status: new target: ====================================================================== Date Submitted: 17-Dec-12 18:10 CET Last Modified: 18-Dec-12 20:42 CET ====================================================================== Summary: Improperly formatted MIME Boundary in BODYSTRUCTURE response Description: I am having trouble with dbmail and thunderbird with certain mails. Thunderbird just shows an empty mail body when opening the mail. This affects all MIME mails with attachment which use certain boundary strings.
I opened a bugzilla report for Mozilla Thunderbird where you can find all details about this issue. https://bugzilla.mozilla.org/show_bug.cgi?id=821250 For example, a mail is being parsed this way in debug log: _structure_part_multipart(+1488): parse [2] parts for [multipart/mixed] with boundary [----=_Part_150954_739912730.1353583710075] This is the IMAP BODYSTRUCTURE response: Info:[clientbase] ci_write(+312): [0x8088ca000] S > [630/630:* 126 FETCH (UID 647213 BODYSTRUCTURE ((("text" "plain" ("charset" "iso-8859-1") NIL NIL "quoted-printable" 5376 134 NIL NIL NIL NIL)("text" "html" ("charset" "iso-8859-1") NIL NIL "7bit" 31526 409 NIL NIL NIL NIL) "alternative" ("boundary" "=?us-ascii?q?----=3D=5FPart=5F150956=5F304026143=2E1353583710?= =?us-ascii?q?125?=") NIL NIL NIL)("application" "octet-stream" ("name" "2012_12rechnung_5611468629.pdf") NIL NIL "base64" 204884 NIL ("attachment" ("filename" "2012_12rechnung_5611468629.pdf")) NIL NIL) "mixed" ("boundary" "=?us-ascii?q?----=3D=5FPart=5F150954=5F739912730=2E1353583710?= =?us-ascii?q?075?=") NIL NIL NIL)) ] You can see that the boundary string is being encoded according to RFC2047 (quoted printable). This obviously is a bug because it is not allowed (and not necessary) to encode the boundary string. This happens every time when a boundary string with an equal-sign (=) or an underscore (_) is being used. Then the string is being encoded and Thunderbird (and probably other mail clients that rely on the BODYSTRUCTURE) crash. This does not happen when the boundary string only contains A-Za-z0-9 chars. But according to RFC2046 it is allowed to used = or _ in the boundary string. How can we fix this issue? I would appreciate a fast solution (or even a first workaround) since I have to use Thunderbird with dbmail. Unfortunately I still could not isolate that line in the sourcecode which actually performs the unwanted encoding of the boundary string in the bodystructure response. If I can assist you in any way, please just let me know. Thanks for your help in advance. ====================================================================== ---------------------------------------------------------------------- (0003509) dfroe (reporter) - 18-Dec-12 20:42 http://www.dbmail.org/mantis/view.php?id=996#c3509 ---------------------------------------------------------------------- I could finally figure out a quick and dirty workaround. Fortunately it works as intended and I can read all mails again with thunderbird which did not work before. >From what I could discover a function trace when executing a BODYSTRUCTURE command looks like this: File: dm_misc.c _structure_part_multipart imap_append_hash_as_string get_param_list The last function then actually calls g_mime_utils_header_encode_text from the gmime library. That is where the RFC2047 encoding misleadingly happens. Original: gchar *s = g_mime_utils_header_encode_text(((GMimeParam *)value)->value); I modified that line this way: gchar *s = (strcasecmp((char *)key, "boundary") == 0) ? ((GMimeParam *)value)->value : g_mime_utils_header_encode_text(((GMimeParam *)value)->value); This code change only skips the RFC2047 encoding when the key "boundary" of a hash is being processed. I hope this avoids any side effects. However this results in a properly formatted BODYSTRUCTURE return string where the mime boundary string is printed as it is without any further encoding. Can you please review this issue and transfer this workaround to a real patch so dbmail's responses are fully RFC compliant. Otherwise we might encounter strange effects with some mail clients. Issue History Date Modified Username Field Change ====================================================================== 17-Dec-12 18:10 dfroe New Issue 17-Dec-12 18:11 dfroe Tag Attached: bodystructure 17-Dec-12 18:11 dfroe Tag Attached: boundary 17-Dec-12 18:11 dfroe Tag Attached: imap 17-Dec-12 18:11 dfroe Tag Attached: mime 17-Dec-12 18:11 dfroe Tag Attached: thunderbird 18-Dec-12 20:42 dfroe Note Added: 0003509 ====================================================================== _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
