MBOX-Line: From tss at iki.fi  Tue Jun 19 11:55:58 2012
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] BINARY + CATENATE
Message-ID: <1340132158.5967.46.camel@hurina>

I don't think their interaction is specified anywhere? I think strictly
reading the RFCs it means that:

Server is allowed to modify only the data in literal8 part. If CATENATE
first added a header using regular literal:

Content-Type: application/msword
Content-Transfer-Encoding: binary

and then attempted to send another part as literal8, the server would
have to fail with UNKNOWN-CTE, because it's not allowed to replace the
Content-Transfer-Encoding with base64 anymore since it wasn't in
literal8. Also it wouldn't be possible to use a CATENATE URL to add a
binary file, because a URL isn't a literal8.

Another way of thinking would be that if literal8 was used for the
header, the rest of the message would be allowed to be binary even if
the parts aren't literal8.

And the 3rd way of thinking would be that if a literal8 was used
anywhere in the literal at all, the server would be allowed to modify
the whole message. This would make it rather annoying to handle, because
the server wouldn't know if it needs to do any changes until it has
received and parsed the entire CATENATE command.

I'm thinking that I'll make my server only do the conversion if the
CATENATE begins with a literal8. If it doesn't and a literal8 is later
seen, the APPEND would fail with UNKNOWN-CTE.


