38 lines
1.5 KiB
Plaintext
38 lines
1.5 KiB
Plaintext
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.
|
|
|
|
|