feat: Add support for limited read and write buffers in `ClientFlow` and `ServerFlow`

[jakoschiko]

Currently the read and write buffers in ClientFlow and ServerFlow are unlimited. An attacker might exploit this by using some IMAP quirks (e.g. very long lines) in order to allocate unlimited memory on the attackee. We can solve this by introducing (optional) support for limited buffers.

To do:

• ClientFlowOptions and ServerFlowOptions need optional sizes for the read and write buffer. The default values are up for discussion.
• Find a way to enforce the limited size on our buffer somehow. Currently we are using BytesMut as buffer implementation. Not sure if it supports that.
• If the buffer overflows, we need to inform the user about that. Maybe StreamError is the right choice of doing that.
• It would be nice if the proxy also allows to configure the sizes via config file.

[duesee]

Dovecot accepts roughly ~2^16 bytes in total for commands. If you try to send a literal at some point that will exceed the total size, this literal is rejected. In other words: There is no fixed max literal size.

[jakoschiko]

Dovecot accepts roughly ~2^16 bytes in total for commands. If you try to send a literal at some point that will exceed the total size, this literal is rejected. In other words: There is no fixed max literal size.

I'm confused. Our current default for max literal size:

https://github.com/duesee/imap-flow/blob/dce759a8531f317e8d7311fb032b366db6698e38/src/server.rs#L46-L47

But ~2^16 is much smaller than 25 * 1024 * 1024. Is our limit for literals much larger than the limit for commands in dovecot?

[jakoschiko]

Find a way to enforce the limited size on our buffer somehow. Currently we are using BytesMut as buffer implementation. Not sure if it supports that.

I think this function will do the magic.

[duesee]

Sorry for the delay.

I feel that I should reiterate on what Dovecot does:

From my experimentation it seems that Dovecot has a MAX_BYTES_PER_COMMAND of 2^16. It doesn't track single literals but adds the sizes up. Adding up is necessary because there are commands that allow infinite literals, e.g., SEARCH.

Now, 2^16 (64 KiB) is too small for an email. However, email content is also transmitted through a literal in APPEND. Thus, I assume the APPEND command is handled differently in Dovecot to allow multiple MiBs.

In imap-flow we used 25 MiB because Gmail allows to send emails with up to 25 MiB. But this large limit may only make sense when using APPEND.