Issues with the quota implementation

[urkle]

Issue #1

The GETQUOTAROOT command is supposed to return a list of quota root and then each individual quota root definition.

Thus given a mailbox "mybox" with a quota root of "someroot" attach to it the correct response for S01 GETQUOTAROOT mybox should be this.

* QUOTAROOT mybox someroot
* QUOTA someroot (STORAGE 10 1000)
S01 OK completed

However, greenmail is returning this instead.

* QUOTAROOT mybox
* QUOTA someroot (STORAGE 10 1000)
S01 OK completed

Reference: https://datatracker.ietf.org/doc/html/rfc2087#section-5.2

Issue #2

Further multiple mailboxes can point to the same quota root and generally subfolder point to the quota root of the parent folder.. Thus given that "mybox" has a quota root of "someroot" as above, requesting the quotaroot for a subfolder

S01 GETQUOTAROOT mybox.folder

Would return the same quota root as the parent folder. thus.

* QUOTAROOT mybox.folder someroot
* QUOTA someroot (STORAGE 10 1000)
S01 OK completed

Issue #3

There is no way to remove a quota in Greenmail

1. deleting the user does not remove the quota roots
   a) and recreating that user attaches to the existing root.
2. deleting a folder with a quota root, does not delete the root
3. unable to set a quota root to "clear it" (e.g. setting it's limit to 0 or -1)
   a) actually trying to set it to -1 immediately disconnects when the - is sent over the connection.

(for automated tests it'd be nice to DELETE a quota root so things are reset for another test run).

[marcelmay]

@urkle , thanks alot for the precise feedback.

Regarding issue # 3 :

1. Fixed by Delete QUOTA when deleting/recreating user #505
2. This is unfortunately undefined in the RFC and left to the implementations (but would probably make sense)
3. The value can only be a number (positive integer). Yes, GreenMail should behave gracefully and provide an error message here => fixed by Quota resource invalid limit closes connection #506

I will provide additional comments on # 1 and # 2 .