The admin pages save the whole policy from the draft they loaded. A
save from a page opened before another tab's or another admin's save,
or before a deleted plugin was dropped from the policy, used to put the
older policy back. GET /api/admin/policy now sends the policy version as
an ETag; the policy, organisation, plugins and themes pages send it back
as If-Match, and a save based on an older version answers 409 and keeps
the draft on the page. A PUT without If-Match replaces the policy as
before. Deleting a plugin or theme changes only its id in the stored
policy, and a policy import compares against what it replaces.
Test mocks of the config manager gain getPolicyVersion and updatePolicy,
which the route and the extension cleanup now call.
Stalwart does no BIMI, so sender icons were only ever favicons, which
anyone controls for any domain. The webmail server now does the
receiver side itself at /api/bimi, and avatars ask it only for
messages whose own Authentication-Results say dmarc=pass for the exact
From domain.
- `lib/bimi/`: DMARC policy check (quarantine or reject, pct=100, the
parent domain's sp and p for subdomains), the assertion record with
fallback to the parent domain, mark certificate validation (chain to
pinned DigiCert, GlobalSign and SSL.com VMC roots, BIMI key purpose,
validity, SAN, SCTs present, CRL revocation, logo from the logotype
extension), SVG Tiny PS checks and rendering to PNG, caching
- logos backed only by the DNS record show by default; the admin
setting "Require a mark certificate" (`BIMI_REQUIRE_CERTIFICATE`)
limits them to VMC and CMC backed ones
- a check mark beside the sender's name for certificate-backed logos
- avatars try contact photo, BIMI logo, plugin avatar, favicon; the
sender warning shield still wins, and logos follow the sender icons
setting and the no-third-party-traffic mode
- the two-label public suffix list moved to `lib/root-domain.ts`
SCT signatures are not verified and only the default selector is used.
Each impersonation handoff makes an app password on the target mailbox
that expires after 8 hours. Stalwart keeps an app password after its
expiresAt and counts it against the mailbox's limit (5 by default), and
nothing deleted the expired ones, so after five handoffs every further
one failed with "You have exceeded your quota of 5 app passwords" and the
mailbox could no longer be opened that way.
Before making a new one, the handoff now lists the mailbox's app
passwords and deletes its own expired ones, recognised by the
"Support session " description. The user's own app passwords and a
session still running are never touched. It is best effort: if the list
or the delete fails, the handoff tries to create the password as before.
Linus Rath
Shuki Vaknin