Urlauth #3
Closed
Urlauth #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1) if you send BINARY data, you need to change the BODYPARTSTRUCTURE to match, so it should be saying BINARY / 8BIT / 7BIT depending on the data domain rather than still saying BASE64. I'm 100% sure of this one, see example "A client again requests data with no content transfer encoding, but this time requests the body structure." and compare to example "A client requests only the body structure.". 2) if you request multiple things, they are separate items: (BODYPARTSTRUCTURE ...) (BINARY ...) rather than combined (BODYPARTSTRUCTURE ... BINARY ...) in a single list. I'm 100% sure of this, see examples "A client again requests data with no content transfer encoding, but this time requests the body structure." and "A client requests the body structure and the original content.". Even the degenerate case: "Some parts cannot be decoded, so the server will provide the BODYPARTSTRUCTURE of the part as is and provide NIL for the binary content" 3) if you fetch a 7BIT part which has subparts (multipart or message type) then it could be debated that you shouldn't decode all the subparts as well. There's no example of this in 5524, however RFC 3516 defines the BINARY fetch command, and says: "Every IMAP4 body section has a MIME content-transfer-encoding. (Those without an explicit Content-Transfer-Encoding header are implicitly labeled as "7bit" content." and "server processing of the FETCH BINARY command involves two logical steps: 1) perform any CTE-related decoding 2) determine the domain of the decoded data" From which I derive that the Content-Transfer-Encoding of the embedded MESSAGE/RFC822 MIME part is the identity operation in the 7BIT domain.
…f the MIME separator in it
|
Hi! Thanks we'll take a look at this! |
|
Huh, took forever to look into this. Doesn't seem like there are many/any people using URLAUTH.. I think:
|
|
That sure is forever! I've just been running a locally modified set of patches so our tests pass. Would be very happy to be able to run vanilla upstream though :)
…On Tue, Mar 30, 2021, at 23:18, sirainen wrote:
Huh, took forever to look into this. Doesn't seem like there are many/any people using URLAUTH.. I think:
* Returning (BODYPARTSTRUCTURE ... BINARY ...) - Right, this is definitely a bug
* BODYPARTSTRUCTURE returning converted content-transfer-encoding: Yes, but I think it's valid for it to return either 7bit, 8bit or binary, right?
* As for returning multiple MIME parts .. Didn't we discuss this at some point related to BINARY extension alone, and decide that it's just not allowed to be used for non-leaf parts? Or that it's server-defined behavior what happens when it's non-leaf. So I think I should just remove it from the test.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEJ3PNT2YYFGYB2M26LYTTGG6TBANCNFSM4CVPMVSQ>.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
***@***.***
|
|
DOP-279 - will eventually be merged once we get URLAUTH fixed in Dovecot.. |
|
please reopen against main |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a series of 4 patches.
The first one just changes the urlauth-binary tests to match my reading of what the spec actually intends.
In particular the existing tests are clearly bogus because they look for a BODYPARTSTRUCTURE which still says that the encoding is BASE64, while the BODYPARTSTRUCTURE is supposed to represent the converted data and the encoding should contain the identity domain of the BINARY content if BINARY is requested.
The second patch just adds a boring additional test.
The third adds a test for the case of an unparseable part, to make sure that the server returns the original bodystructure and a NIL BINARY part.
The fourth adds a part with a quoted-printable encoded version of the MIME boundary, which would cause broken results from a server which blindly decodes each individual part without checking for boundaries in the resulting MIME structure.