• v0.33.0 f9d35afaee

    joeyr released this 2026-08-23 09:37:54 -05:00 | 101 commits to main since this release

    G3: label administration on the Gmail tenant. create_folder, rename_folder and delete_folder, behind MAIL_FOLDER_ADMIN — which is parallel to MAIL_WRITABLE_FOLDERS rather than nested inside it, and registers nothing when off.

    The finding this phase turns on

    A straight port of icloudmail.delete_folder would have told the user their mail was about to be destroyed. That tool says the messages do not go to trash and nothing can recover them, which is true there. On Gmail it is false: a label holding two messages was deleted on the live account and both were still in All Mail afterwards — the one that carried no other label came back with [], archived rather than gone.

    What a label delete destroys is the filing, and that part is irreversible, because nothing records which messages carried the label. So the two guards stay and their numbers change meaning. expected_message_count is how many messages lose the label, and the refusal reports a second number beside it: how many are then left carrying no label at all, reachable only by searching All Mail. That is the number the user actually feels, and it cannot be derived from the first.

    Also in this release

    • create_folder reports the parent Gmail invents. CREATE a/b with no a succeeds and leaves a as a \HasChildren \Noselect placeholder — a hierarchy node, not a label. Returned as implied_parent, because "created Work/Receipts" otherwise reads as though there is now a Work label.
    • rename_folder reports how many nested labels moved with it. A Gmail rename carries the whole subtree, including labels outside MAIL_FOLDERS that this server cannot see. Every handle under the prefix dies — and UIDVALIDITY and the UIDs inside are untouched, so the handle breaks purely because it carries the old name.
    • A label with children is refused, although Gmail would allow it: Gmail keeps the children and goes on showing the parent name as an empty grouping.
    • [Gmail]/ is refused as a namespace by this server, because Google itself accepts a label created there.
    • The server no longer calls itself READ-ONLY while it can delete a label. Folder admin rides its own gate, so it reaches a configuration where nothing else changes anything.
    • The "add it to MAIL_FOLDERS first" caveat is now conditional on there being an allowlist. On the wildcard deployment a new label is readable the moment it exists.

    50 checks green in the live pass; see docs/operations.md. Full detail in CHANGELOG.md.

    Deploying: this needs MAIL_FOLDER_ADMIN: "true" in the stack file (already pushed to the homelab repo), a yaml stack update in Portainer with re-pull ticked, and the Gmail connector reconnected — the tool list changed.

    Downloads