On Saturday, 30 July 2005 at 18:49, Marco d'Itri wrote:
>
> Subject: Bug#297084: possible fix
> Reply-To: John Hedges <john@xxxxxxxxxxxxxx>, 297084@xxxxxxxxxxxxxxx
> To: 297084@xxxxxxxxxxxxxxx
> From: John Hedges <john@xxxxxxxxxxxxxx>
>
> I get the same problem. I found '\0's in the messages that caused the
> hang and this fix works for me - whether it is the right thing I couldn't
> say.
>
> John
>
> diff -ruN mutt-1.5.9.orig/imap/message.c mutt-1.5.9/imap/message.c
> +++ mutt-1.5.9/imap/message.c 2005-07-29 16:01:13.446252488 +0100
> @@ -590,6 +590,9 @@
>
> for (last = EOF, len = 0; (c = fgetc(fp)) != EOF; last = c)
> {
> + if (c == '\0')
> + continue;
> +
> if (c == '\n' && last != '\r')
> buf[len++] = '\r';
This doesn't seem right. For one thing you can end up appending fewer
bytes than you had said you would - I don't think that's going to be
good for most servers. And for another, to quote RFC 3501:
The APPEND command appends the literal argument as a new message to
the end of the specified destination mailbox. This argument SHOULD be
in the format of an [RFC-2822] message. 8-bit characters are
permitted in the message. A server implementation that is unable to
preserve 8-bit data properly MUST be able to reversibly convert
8-bit APPEND data to 7-bit using a [MIME-IMB] content transfer
encoding.
In other words, it sounds like Courier's not compliant. It would be
good if mutt didn't hang though. I'd have to see a trace to understand
better what was happening. I suppose the worst case scenario is that
mutt converts 8-bit bodies to base64 or something itself before
uploading, but that's really not ideal.
Attachment:
pgpQ9p5RkdRDu.pgp
Description: PGP signature