mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Timo Sirainen <tss@iki.fi>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:48 -0000
Message-ID: 1340132158.5967.46.camel@hurina permalink / raw / eml / mbox
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.
Reply