Goal

Pick the hosted webmail to fork and adapt to the committed direction (Sovrn owns login UX; webmail receives a Sovrn-minted OIDC/JMAP bearer token and calls Stalwart JMAP directly). Compare candidates on forkability against that seam.

Candidates

• https://github.com/root-fr/jmap-webmail (Next.js, Stalwart-focused, OIDC+Basic auth)
• https://github.com/bulwarkmail/webmail
• https://github.com/linagora/tmail-flutter (Also builds for iOS and Android from same code base)

Evaluation axes

• Auth seam: how easily the login flow is replaced with “receive Sovrn bearer token (session cookie → token handoff) → Authorization: Bearer against JMAP endpoint”
• JMAP coverage: Email/query, Mailbox, EmailSubmission (send), EventSource/WebSocket push, attachments (blob upload/download), Contacts, Calendar, Bonus: JMAP settings like sieve scripts, vacation responders, etc.
• Token refresh + session lifecycle hooks
• Stalwart compatibility (registry-free, pure JMAP client)
• License, dependency weight, maintenance activity
• Effort to fork and keep upstream-rebased vs. hard-fork
• Effort to update the UI/UX to map a modern email client workflow (likely needs a hard-fork)
• Accessibility (particularly for tmail-flutter, which uses Flutter web = notoriously bad div soup that screws up accessibility for screen readers)

Outcome

ADR or findings note selecting the fork; a reference integration lands in C6 (0d541aa) E2E.

Depends on: C5 (c1c7e19) tokenissuer → Stalwart OpenId chain (defines the token handoff seam).