* [14.Ağu.07 17:31 -0700] Ray Van Dolson: > That is a multipart/mixed message with a multipart/alternative message > inside of it. However, the first text portion of the > multipart/alternative portion appears to be improperly labeled as > base64.
Not the text part, the multipart/alternative part itself is labeled as base64. And AFAIK, that's not permitted for multipart types. > The only way I can get it to show up in mutt is to edit the raw > message and change the first base64 to 8bit (leaving the base64 for > the actual file attachment). You can also view from the attachments menu. > So is this message being generated incorrectly? Yes. > Should mutt handle things differently instead of just bombing out? Yes, IMHO. I'm using the attached patch for this. -- ~sertaç
--- mutt-1.5.16-orig/handler.c 2007-08-15 14:10:26.000000000 +0300 +++ mutt-1.5.16/handler.c 2007-08-15 14:10:05.000000000 +0300 @@ -1575,9 +1575,10 @@ fseeko (s->fpin, b->offset, 0); /* see if we need to decode this part before processing it */ - if (b->encoding == ENCBASE64 || b->encoding == ENCQUOTEDPRINTABLE || + if (b->type != TYPEMULTIPART && + (b->encoding == ENCBASE64 || b->encoding == ENCQUOTEDPRINTABLE || b->encoding == ENCUUENCODED || plaintext || - mutt_is_text_part (b)) /* text subtypes may + mutt_is_text_part (b))) /* text subtypes may * require character * set conversion even * with 8bit encoding. --- mutt/PATCHES.old Tue Nov 6 19:59:33 2001 +++ mutt/PATCHES Tue Nov 6 19:59:42 2001 @@ -0,0 +1 @@ +sy.multipart_decode