evolution crashed with SIGSEGV after opening email with attachment

StacktraceTop:imap_body_decode (in=0xb2d6d1d8, ci=0xb4827100, folder=0xb4802820, cis=0xb48332a0)
imap_parse_body (body_p=0xb2d6d234, folder=0xb4802820, ci=0xb4827100)
imap_get_message (folder=0xb4802820, uid=0x850c8a0 "137", ex=0xb4800af4)
camel_folder_get_message (folder=0xb4802820, uid=0x850c8a0 "137", ex=0xb4800af4)
get_message_exec (m=0xb4800ae0) at mail-ops.c:1720

thanks for your report, that's known upstream, you can track it here: http://bugzilla.gnome.org/show_bug.cgi?id=520233

Since bug 384716 is marked as a duplicate, commenting here.

The problem reported in 384716 is definitely have nothing to do with sender address, but rather IMAP decoding.
In my case, problem triggered on e-mails from exactly one person and only using IMAP provided by safesecureweb.com mail hosting.

$ telnet mail36.safesecureweb.com imap
Connected to mail36.safesecureweb.com.
Escape character is '^]'.
* OK IMAP4rev1 SmarterMail

GMail IMAP brings these very same messages absolutely ok.

If needed, I can try to arrange an account for testing. Although, not 100% sure.
Please contact me directly for this via dmelentyev AT dynamo-ny DOT com.

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.

Also, it is quite easy to break the stack with very deep recursion here (same function, imap_body_decode()):

896: if (*inptr++ != '(')
  return NULL;

 if (ci == NULL) {
  ci = camel_folder_summary_content_info_new (folder->summary);
  g_ptr_array_add (cis, ci);
 }

904: if (*inptr == '(') {
  /* body_type_mpart */
  CamelMessageContentInfo *tail, *children = NULL;

  tail = (CamelMessageContentInfo *) &children;

  do {
/*!!!*/ if (!(child = imap_body_decode (&inptr, NULL, folder, cis)))
    return NULL;

   child->parent = ci;
   tail->next = child;
   tail = child;
917: } while (*inptr == '(');

Just imagine inptr points to a string with some thousands of '('s.
I might be wrong or outdated in exact stack calculations, but supposing at least 20 bytes of stack per call (ret ptr + 4 pointers in arguments, 4 bytes per pointer) and 2Mb thread stack will result in maximum level of recursion equal 104857 2*1024*1024/20 = 104857
Add here some memory alignment, other calls in this thread's stack, variables... Stack is not that deep actually. I'd rather expect no more than 5-10 thousand calls.
And I hardly see any checks for this case or any attempt to roll out this recursion into a loop.

I consider the code dangerous and significantly broken. :(

Wow, "CamelMessageContentInfo *tail" and "imap_body_decode()" recursion! Probably the author did forget that he wasn't writing in Haskell and the C++ compiler won't do tail recursion optimization for this code :)))

this was fixed upstream on :

"Created commit 500e0e9 in eds master (2.31.1+)
Created commit 5cfb419 in eds gnome-2-30 (2.30.1+)"

this bug is fixed in evolution 2.30.1 which is now in Maverick