Fluxmail
Upgrade guides

Upgrade to 0.25.0

Mailbox owners control sharing and server settings, administrators move mailboxes by removing members, and keys created for others reach only mailboxes both members can read.

Fluxmail 0.25.0 stops administrators from reaching another member's private mail through Fluxmail. Some administrator commands that changed other members' mailboxes now return permission_denied. The SQLite store moves to format 8.

Find your migration

InterfaceRequired changes
CLIOwners run fluxmail accounts access and fluxmail accounts assign for their own mailboxes. To move a departing member's mailboxes, run fluxmail members remove <member> --reassign-to <member>. In JSON and NDJSON output, fluxmail apikey list returns each key as an object instead of a line of text.
RESTOwners change sharing and ownership with PATCH /api/v1/accounts/{accountId}/access. PATCH /api/v1/admin/accounts/{accountId} now works only on mailboxes you own. DELETE /api/v1/admin/members/{memberId} accepts a reassignTo query parameter. API key responses include issuedByMemberId, issuedByEmail and issuedByStatus.
MCPNo client migration.

Mailbox sharing belongs to the owner

Only a mailbox's owner can change who can reach it or hand it to another member. In 0.24.0 these changes required an administrator, and an administrator could make them on any mailbox. Members can now run fluxmail accounts access and fluxmail accounts assign on mailboxes they own. A member a mailbox is shared with can't share it further. Every member listed with --share-with must belong to the instance.

Server settings belong to the owner

Only a mailbox's owner can reauthorize it or change its IMAP and SMTP server settings. That covers fluxmail accounts add --reauthorize and reauthorizeAccountId on the REST connection routes. It also covers an administrator connecting an IMAP mailbox with an address that's already connected, which used to replace that mailbox's settings.

Administrators can still connect a new mailbox for a member who is active or hasn't enrolled yet. They can also remove mailboxes, edit IMAP folder mappings and sender addresses, and list every mailbox's metadata.

Move mailboxes by removing the member

In 0.24.0 you reassigned a departing member's mailboxes and then removed the member. In 0.25.0 you do both in one command:

fluxmail members remove grace@example.com --reassign-to ada@example.com

The new owner must be active or invited and not yet enrolled. Without --reassign-to, Fluxmail still refuses to remove a member who owns mailboxes, so you can also remove the mailboxes first. Removing a member also revokes the API keys they created for other members. The audit log gets an account.owner.reassign entry for each mailbox that changes owner.

Keys created for other members

A key that an administrator creates with fluxmail apikey create --member reaches only mailboxes that both the administrator and the member can read. --account accepts only mailboxes the administrator can read. The key can't change who can access the member's mailboxes, hand them over, or change their connections, and keys created with it keep the same limit. The key stops working while the administrator who created it is suspended.

fluxmail apikey list --format table shows issuedBy= with the creator's email address on keys created for another member, and marks a key disabled while its creator is suspended. Fluxmail can't tell who created keys made before 0.25.0, so those keys show no creator and keep their current reach. Replace any of those keys you created for another member.

Store format 8

Stop every process sharing the store before the first 0.25.0 process opens it. Fluxmail backs up the store before it migrates. Fluxmail 0.24.0 can't open a format 8 store, so rolling back requires that backup.

Last updated