Re: imap/2244: Copying mail message from local mailbox to remote imaps server hangs when message contains NUL chars
The following reply was made to PR imap/2244; it has been noted by GNATS.
From: TAKAHASHI Tamotsu <ttakah@xxxxxxxxxxxxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc:
Subject: Re: imap/2244: Copying mail message from local mailbox to remote imaps
server hangs when message contains NUL chars
Date: Sat, 20 May 2006 07:47:36 +0900
* Fri May 19 2006 mutt.wayne@xxxxxxxx <mutt.wayne@xxxxxxxx>
> >Description:
> Some badly-formed spam contain NUL characters (\000).
> When messages containing NULL characters are moved between local mailboxes,
> no problem arise.
> When moved from local mailboxes to remote IMAP servers, mutt hangs.
> Tried with remote cyrus-imapd, courier-imap and dovecot.
I have no remote IMAP server working, but I suspect this code:
(imap/message.c: 584-651)
| flush_buffer(buf, &len, idata->conn);
|
| mutt_socket_write (idata->conn, "\r\n");
| fclose (fp);
|
| do
| rc = imap_cmd_step (idata);
| while (rc == IMAP_CMD_CONTINUE);
First, mutt counts fgetc() and send the count to IMAP server.
Next, mutt stores fgetc() to "buf" incrementing "len".
If "len" is long enough, mutt flush_buffer(buf,&len,idata->conn).
But flush_buffer() is just a wrapper of "mutt_socket_write(conn, buf);".
Note this doesn't use "len" at all.
Let's look at mutt_socket_write_d().
Wow, mutt_socket_write_d() uses mutt_strlen() as its buffer length.
This ignores the rest of the buffer after NUL.
So, even after mutt sent the message, IMAP server could wait for more data
because the length sent from mutt is less than the reported size, I guess.
Fix: Use "len" in flush_buffer().
Well, all the above is just a wild guess. No warranty. ;)
--
tamo