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.
The first version took a template missing from the account's Inbox
metadata as deleted, skipped the browser's own list once the account
held anything, wrote the marker before the settings blob had loaded,
and let a round overwrite edits made while it ran. Each of these could
drop templates, or bring deleted ones back.
Now the marker entry `org.bulwarkmail.templates` holds tombstones
(90 days, at most 8 KB, oldest dropped first) and only a tombstone
deletes; a missing entry is uploaded again. Every round merges the
browser's list in when it is this account's, each version once, minus
what a newer tombstone deleted. While settings sync hasn't loaded the
account's settings, the list isn't used and no marker is written; a
blob that loads later is merged into the account's copy. The settings
blob drops its templates only once the marker is on the server. Without
settings sync the list goes into the first account that answers only.
A round that saw changes while it ran plans again against the server as
it left it. An answer without the metadata property counts as
unsupported. Changes move `updatedAt` past the previous value, dateless
synced templates get a fixed early date, and ids that don't fit a
metadata key get a new id derived from the old one. Queued changes go
out before an account signs out; a full sign-out keeps unsent templates
and deletions.
Team templates are written only if the entry is still the version the
edit started from ("Changed by someone else"), never carry Bcc, and a
refusal is told apart by Stalwart's error type. The template manager's
lists are a real tab list with arrow keys and 44 px row buttons on
phones.
The task modal and the plugin API send an all-day due as a bare date
("2026-10-14"). A task's due and start are LocalDateTimes (RFC 8984).
Stalwart accepts the bare date and echoes it back over JMAP, but the
stored iCalendar has no DUE, so CalDAV clients (phones, Thunderbird)
show the task without a date. "2026-10-14T00:00:00" with showWithoutTime
is stored as DUE;VALUE=DATE.
createCalendarTask and updateCalendarTask now complete a bare due or
start to midnight. Every write goes through them, so a task saved by an
older client gets a proper due when it moves to another account.
Tests: create, update and the cross-account move against round trips
recorded on Stalwart v0.16.24 (JMAP set, then CalDAV GET of the stored
iCalendar); times and a cleared due stay as they are.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Retry interrupted or invalid runtime configuration requests with bounded backoff and per-attempt timeouts. Validate the complete response before caching it, and prevent stale HTTP-cached configuration.
Cover request and body timeouts, shared hook consumers, retry bounds, the server response contract, and both Lite configuration paths.