On 21.5.2013, at 9.40, Michael M Slusarz <slusarz@curecanti.org> wrote:
Using 2.2.2, I see this:
C: 6 APPEND "INBOX" (\seen) "16-May-2013 22:05:14 -0600" CATENATE (URL "/INBOX;UIDVALIDITY=1255685337/;UID=48812/;SECTION=HEADER" TEXT ~{40} S: 6 NO [UNKNOWN-CTE] Binary input allowed only when the first part is binary.
Why is there this limitation? It seems to me that CATENATE is confusing the content-type encoding of the data/part itself with the encoding of the IMAP literal.
A literal 8 is nothing more than a series of OCTET's that *may* contain nulls, but not necessarily. i.e., in the above example the 40 octets of data are US-ASCII text, which is perfectly acceptable to send as a literal8. (Client rationale: If BINARY exists on the server, we don't bother to scan IMAP literal's for null data -- we just send them as literal8's. It's an optimization that I would hate to get rid of.)
Well, the problem is that if it does contain NULs, the MIME part needs to be converted to something that doesn't. And to do that it needs to modify the previous header, which with current code was already read.. So to fix that it would need to read the whole message into a temporary file before actually saving it, which makes performance worse for the normal case..
Or are you saying that the error is fine if the text contains NULs, but simply should be allowed as long as it doesn't?