With enableAssistedDiscovery disabled, calendar-home-set returns one href per account sharing with the user (16 hrefs in our case, own home first). eM Client handles this correctly, but other clients (iOS / Thunderbird) only discover a single, seemingly random calendar.
With enableAssistedDiscovery enabled, calendar-home-set only returns the user’s own home and PROPFIND Depth 1 on /dav/cal/ is turned into Depth 2. Other clients now work, but eM Client only discovers a single, seemingly random calendar.
Since the setting is global, there is no configuration that works for both kinds of clients on the same server.
Relevant Log Output
PROPFIND Depth 0 on /dav/cal/ – assisted discovery enabled:
xml
<A:calendar-home-set><D:href>/dav/cal/user%40domain/</D:href></A:calendar-home-set>
Assisted discovery disabled:
xml
<A:calendar-home-set><D:href>/dav/cal/user%40domain/</D:href><D:href>/dav/cal/shared1%40domain/</D:href>… (16 hrefs)</A:calendar-home-set>
Request: make assisted discovery configurable per account/group (or per User-Agent), or make one of the two modes compatible with both kinds of clients.
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
OIDC
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
This is a known limitation of assisted discovery, not a bug: enableAssistedDiscovery on the WebDav singleton is a single global switch, and it isn’t configurable per account, group, or client (User-Agent). There’s currently no per-client override in the docs or config schema, so with a mixed fleet of eM Client and spec-compliant clients (iOS/Thunderbird) you’re stuck picking the mode that suits the majority.
Per the docs, the recommended long-term fix for clients that only handle a single calendar-home-set href (like eM Client here) is to have them add proper support for WebDAV ACL and multi-value calendar-home-set/addressbook-home-set discovery, since assisted discovery deliberately violates spec (Depth 1 promoted to Depth 2) specifically to work around clients that assume a single home path. See WebDAV assisted discovery and the WebDav settings reference.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Thanks, but I think the diagnosis is inverted. eM Client is the spec-compliant one here: it works with assisted discovery disabled (multi-value calendar-home-set, 16 hrefs). It’s the other clients that need assisted discovery, and eM Client breaks when it’s enabled (it then discovers a single random calendar, presumably because of the Depth 1 → Depth 2 promotion on /dav/cal/).
So enabling the workaround for non-compliant clients breaks a compliant one, with no way to scope it. Would a per-account/group or per-User-Agent toggle be considered as a feature request?
eM Client is the one following the spec here. Assisted discovery exists for clients that only read the first calendar-home-set entry, and the Depth 1 to Depth 2 promotion that rescues them is what throws eM Client off. The setting is server-wide, and v1.0.0 doesn’t scope it per account or per client either, so the toggle you describe would be new work. Please post it in Feature Ideas, where it can be tracked.
With assisted discovery off, which is the spec-compliant default, Thunderbird can still show the shared calendars if you add each one by its collection URL, https://<host>/dav/cal/<owner>/<calendar>/.