Implement IMAP quota extension (was: Understanding new feature: quota)

[pmarini-nc]

Quite excited to see that 0.0.9 has added support for quota!

I'm trying to get it working but I have a few points that I don't understand fully:

1. What is the unit of the specified quota? Bytes? Can it be specified in MB or GB?
2. I have first tried to configure it per-account in the web-interface, specifying for example 1048576, but it was giving an error (number not valid) and saving was not possible. Then I inserted the parameter QuotaMessageSize: 1024 in mox.conf, restart and I was able to save a per-account value. Finally I tested removing QuotaMessageSize from mox.conf and I was still able to modify and save a per-account value. Not sure whether there is some relationship between the global value and the per-account value, it may make sense to force the per-account value to be less than the global value.. can you please explain?
3. Now that I have a quota in place for a user (maybe wrongly defined as specified above), I noticed that Thunderbird still reports "The server does not support quotas" when selecting Inbox->Folder Properties->Quotas

[mjl-]

Thanks for reporting!

1. In the config file the value is in bytes. I agree it's not too user-friendly... It is currently an integer, but we could change it to a string and accept "mb"/"gb" etc. The admin web interfaces does convert that now, so that should be moved into config file handling. As a quick fix I'll clarify in the docs for the field in the config file that it's in bytes. Let's leave this issue open for a size like "...MB".
2. I tested the QuotaMessageSize just now, and numbers seem to be accepted here. Could there be a leading/trailing space in there perhaps? Though I'm getting this error message in that case: "parsing integer: strconv.ParseInt: parsing \" 1048576\": invalid syntax". I don't think "number not valid" was the literal error string you got? At least I can't find that in the code. The "global quota size" is the "default quota for accounts that don't set their own". The "per-account quota" is intended to mean "the quota configured for the account". But I can see how the wording "per-account quota" implies that the global quota is a total size of all accounts. I'll update the field docs to make it clear both settings are max sizes per account. There was also a bug: The account max size comment claims a negative max value (no limit) would override the global max size, but that wasn't happening: the global value would still apply. Will fix.
3. The IMAP quota extension indeed isn't implemented. The goal with this change was to protect the server against a single account filling up storage. From reading the IMAP quota RFC it seemed each mailbox (folder) will have a max size that would have to be enforced. I never used IMAP quota, so don't know how users use them and my imagination is lacking. Is it intended to prevent some mailbox (e.g. for mailing lists) from taking up all the users's space, while still allowing deliveries to the regular Inbox? It doesn't strike me as a very common situation. It would make sense to be able to state the total max message size for an account, but (from memory) I don't think that's what the IMAP quota extension does. Mox does have the STATUS=SIZE extension to quickly return the total size of each mailbox. But that's unrelated to total max size config/enforcement.

[pmarini]

In the config file the value is in bytes. I agree it's not too user-friendly... It is currently an integer, but we could change it to a string and accept "mb"/"gb" etc. The admin web interfaces does convert that now, so that should be moved into config file handling. As a quick fix I'll clarify in the docs for the field in the config file that it's in bytes. Let's leave this issue open for a size like "...MB".

I think that, as far as you document it, it is ok to accept only integers here. But yes, the possibility to specify it in MB or GB is a nice-to-have.

I tested the QuotaMessageSize just now, and numbers seem to be accepted here. Could there be a leading/trailing space in there perhaps? Though I'm getting this error message in that case: "parsing integer: strconv.ParseInt: parsing " 1048576": invalid syntax". I don't think "number not valid" was the literal error string you got? At least I can't find that in the code.

My fault, the error is "invalid number" if there is a leading/trailing space, as you mentioned.

The "global quota size" is the "default quota for accounts that don't set their own". The "per-account quota" is intended to mean "the quota configured for the account". But I can see how the wording "per-account quota" implies that the global quota is a total size of all accounts. I'll update the field docs to make it clear both settings are max sizes per account.

This is how I understood it, my wording was poor.

There was also a bug: The account max size comment claims a negative max value (no limit) would override the global max size, but that wasn't happening: the global value would still apply. Will fix.

3. The IMAP quota extension indeed isn't implemented. The goal with this change was to protect the server against a single account filling up storage. From reading the IMAP quota RFC it seemed each mailbox (folder) will have a max size that would have to be enforced. I never used IMAP quota, so don't know how users use them and my imagination is lacking. Is it intended to prevent some mailbox (e.g. for mailing lists) from taking up all the users's space, while still allowing deliveries to the regular Inbox? It doesn't strike me as a very common situation. It would make sense to be able to state the total max message size for an account, but (from memory) I don't think that's what the IMAP quota extension does. Mox does have the STATUS=SIZE extension to quickly return the total size of each mailbox. But that's unrelated to total max size config/enforcement.

Besides details on how the IMAP quota is defined in the specifications, I think it is a good information that the user can keep an eye on. If I'm not mistaken then, the implementation in mox does not expose the used quota value to the user, via its client, correct? So, to resume, in addition to the fundamental goal that you mention, I think that quota goal is to let the user know how much space he/she is using.

From my perspective, the email provider Fastmail exposes the quota in the way it should:

and these are the actual value of the used and total quotas. In Fastmail's case, the values are the same for all the mailboxes, so it is probably a simplification of the use case you mention above, of putting a mailbox quota, but I think it matches user expectation.

[mjl-]

Good info, thanks. Looking at the RFCs again, I think I previously only looked at https://datatracker.ietf.org/doc/html/rfc2087, which has been obsoleted by https://datatracker.ietf.org/doc/html/rfc9208. Reading that, I don't see any blockers to implement it. Let's keep this open for implementing the IMAP quota extension. Doesn't look too hard.

[mjl-]

The commit just now implements the IMAP quota extension specified in RFC 9208. See the commit message for some caveats. With a limit set, Thunderbird will now show it.

[pmarini-nc]

Sorry to say that I wouldn't be able to test it unless you provide a binary that includes the improvement..

[mjl-]

Good point, making a mental note to provide instructions, and make them a bit easier to follow.

If you have a Go toolchain installed (go version >= 1.21), you can compile it yourself: CGO_ENABLED=0 GOBIN=$PWD go install github.com/mjl-/mox@v0.0.11-0.20240311132432-4dea2de34374.

You can also download a binary: https://beta.gobuilds.org/github.com/mjl-/mox@v0.0.11-0.20240311132432-4dea2de34374/linux-amd64-go1.22.1-stripped/

[pmarini-nc]

Ok, as soon as I can connect with Thunderbird, I'll try there (#140). And if it takes longer, I can try with another client that supports the quota.

[pmarini-nc]

Hi, So, I just tested with 0.0.11 and it works as expected. I have assigned the value 1.000.000.000 and this is what Thunderbird shows:

Moreover you have also added human formatting option, that's great!

However it would be great to have the human formatting option outlined in the tooltip. I tried 2g and it works, while 2G is invalid but no error is shown in the web interface on saving.

[mjl-]

@pmarini-nc thanks for the feedback! the bug about not seeing an error message when the input couldn't be parsed should be fixed now. tooltip and helpful error message is added about the units. and uppercase is allowed too now.