Switch to imap-flow

quentin commented

2023-08-10 07:16:39 +00:00

Owner

There are two cases in which a line from the client does not
represent a complete command. In one case, a command argument is
quoted with an octet count (see the description of literal in String
under Data Formats); in the other case, the command arguments require
server feedback (see the AUTHENTICATE command). In either case, the
server sends a command continuation request response if it is ready
for the octets (if appropriate) and the remainder of the command.
This response is prefixed with the token "+".

Note: If instead, the server detected an error in the
command, it sends a BAD completion response with a tag
matching the command (as described below) to reject the
command and prevent the client from sending any more of the
command.

It is also possible for the server to send a completion
response for some other command (if multiple commands are
in progress), or untagged data. In either case, the
command continuation request is still pending; the client
takes the appropriate action for the response, and reads
another response from the server. In all cases, the client
MUST send a complete command (including receiving all
command continuation request responses and command
continuations for the command) before initiating a new
command.

The protocol receiver of an IMAP4rev1 server reads a command line
from the client, parses the command and its arguments, and transmits
server data and a server command completion result response.

From imap-codec maintainer:
In imap-codec 0.5.0, literal handling was rather difficult. You had to first encode -> Vec<u8> a message and then push it through a second stage that identified literals and did the "literal dance". This was error prone because the second stage was missing crucial information. For example, it could not detect that * OK Some weird text {1337} is NOT a literal.

Later versions of imap-codec deal with this differently: https://docs.rs/imap-codec/latest/imap_codec/codec/struct.Encoded.html

Still, even sending a message as a client is complicated in IMAP as the client can potentially receive any other response before the command continuation request.

Furthermore, Decodeing for a server is different. A client can just call Decode::decode and is done. But a server needs to actively do the literal dance. Here the difficulties of sending a literal accept, a literal reject (which requires the correct tag!), enforcing line, literal, and max message limits, etc. all need to be handled (and abstracted over) together. This is the first thing I would want to solve in a "slightly higher-level" implementation. One that can handle literals, out-of-order responses, etc., without caring too much about IMAP semantics, e.g., enforcing that you can't SELECT before LOGIN, don't LOGIN twice, etc.

There are two cases in which a line from the client does not represent a complete command. In one case, a command argument is quoted with an octet count (see the description of literal in String under Data Formats); in the other case, the command arguments require server feedback (see the AUTHENTICATE command). In either case, the server sends a command continuation request response if it is ready for the octets (if appropriate) and the remainder of the command. This response is prefixed with the token "+". Note: If instead, the server detected an error in the command, it sends a BAD completion response with a tag matching the command (as described below) to reject the command and prevent the client from sending any more of the command. It is also possible for the server to send a completion response for some other command (if multiple commands are in progress), or untagged data. In either case, the command continuation request is still pending; the client takes the appropriate action for the response, and reads another response from the server. In all cases, the client MUST send a complete command (including receiving all command continuation request responses and command continuations for the command) before initiating a new command. The protocol receiver of an IMAP4rev1 server reads a command line from the client, parses the command and its arguments, and transmits server data and a server command completion result response. From imap-codec maintainer: In imap-codec 0.5.0, literal handling was rather difficult. You had to first `encode -> Vec<u8>` a message and then push it through a second stage that identified literals and did the "literal dance". This was error prone because the second stage was missing crucial information. For example, it could not detect that `* OK Some weird text {1337}` is NOT a literal. Later versions of imap-codec deal with this differently: https://docs.rs/imap-codec/latest/imap_codec/codec/struct.Encoded.html Still, even sending a message as a client is complicated in IMAP as the client can potentially receive any other response before the command continuation request. Furthermore, `Decode`ing *for a server* is different. A client can just call `Decode::decode` and is done. But a server needs to actively do the literal dance. Here the difficulties of sending a literal accept, a literal reject (which requires the correct tag!), enforcing line, literal, and max message limits, etc. all need to be handled (and abstracted over) together. This is the first thing I would want to solve in a "slightly higher-level" implementation. One that can handle literals, out-of-order responses, etc., without caring too much about IMAP semantics, e.g., enforcing that you can't SELECT before LOGIN, don't LOGIN twice, etc.