Comment 6 for bug 229669

Well, after quict look at code in camel/providers/imap/camel-imap-utils.c:
( http://git.gnome.org./cgit/evolution-data-server/tree/camel/providers/imap/camel-imap-utils.c?id=6be48b0f55981e67fab9f8243d2d504387dc5691 )

                if (g_ascii_strncasecmp (inptr, "nil", 3) != 0) {
923: subtype = imap_parse_string (&inptr, &len);
  } else {
   subtype = NULL;
   inptr += 3;
  }

  ctype = camel_content_type_new ("multipart", subtype ? subtype : "mixed");
  g_free (subtype);

932: if (*inptr++ != ')') {
   camel_content_type_unref (ctype);
   return NULL;
  }

And then checking imap_parse_string_generic (which is what imap_parse_string() mapped to via #define )

Reveals that inptr MUST be checked for being NULL after the call.
From imap_parse_string_generic in-file doc:

 * Return value: the parsed string, or %NULL if a NIL or no string
 * was parsed. (In the former case, *@str_p will be %NULL; in the
 * latter, it will point to the character after the NIL.)

Conclusion:
1. inptr could need duplicating before call to imap_body_decode(), because it's value is not constant
2. inptr MUST be checked for NULL after the call

IMHO - this is a clear bug, even more, specially crafted e-mail and/or IMAP server could exploit this bug for DoS at end-user side.
So, could be even a security issue.