* [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
