Issue Description
Creating or updating an event with attendees on the family calendar while authenticated as alex or sam fails silently from the client’s point of view (no error is surfaced in the Stalwart Web UI logs). Live Tracing in the Web UI shows the following event during the request:
MAIL FROM unauthorized
The remote client is not authorized to send mail from the given address
This event appears sandwiched between generic HTTP connection started / HTTP connection ended trace entries for the same request — there is no separate SMTP session, AUTH, or MAIL FROM protocol-level trace around it. This suggests the check is raised internally by the CalDAV/JMAP scheduling logic (triggered when an event with attendees/organizer is saved), not by an actual external SMTP client submission.
Expected Behavior
When Alex or sam creates a new event with attendees on the shared family calendar, the resulting invitation (iTIP/iMIP) should be sent with [email protected] as the organizer/sender address, since family is the owner of that calendar. alex/sam should be authorized to trigger this send by virtue of having write access to the shared calendar.
Actual Behavior
See issue description
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
S3-compatible
Search Engine
Internal
Directory Backend
Internal
Additional Context
Environment
Stalwart Mail & Collaboration Server, self-hosted, single domain (example.org)
3 individual accounts on the same domain:
[email protected] (personal account)
[email protected] (personal account)
[email protected] (shared/family account, has its own mailbox and calendar)
The family calendar is shared with alex and sam via CalDAV (WebDAV ACL sharing), granting them read/write access. Sharing was done through a standard CalDAV client (Apple Calendar), not via a custom WebDAV ACL request.
Clients used: Apple Calendar / Thunderbird (CalDAV)
Troubleshooting already performed
Confirmed the calendar sharing/ACL itself works correctly (read/write access to the family calendar from alex/sam is functional; only the scheduling/invitation send fails).
Suspected the mustMatchSender setting on the MtaStageAuth singleton (Settings › MTA › Session › AUTH Stage), which by default requires the authenticated user (or one of their associated email addresses) to match the envelope sender.
Added an expression rule to exempt this specific case:
json {
"match": [
{
"if": "(authenticated_as == '[email protected]' || authenticated_as == '[email protected]') && sender == '[email protected]'",
"then": "false"
}
],
"else": "true"
}
No change in behavior — the error persisted.
As a further diagnostic step, set mustMatchSender to unconditionally false ({“else”: “false”}, no match rules), fully disabling the check.
The error still occurred on a subsequent test (confirming this setting is not the mechanism producing the “MAIL FROM unauthorized” event for this internal scheduling path).
mustMatchSender has since been reverted back to the default ({“else”: “true”}).
Working hypothesis
This looks related to RFC 6638 (CalDAV Scheduling Extensions), which defines a distinct privilege — CALDAV:schedule-send-invite — on the calendar owner’s Scheduling Outbox collection, separate from ordinary read/write ACL on the calendar collection itself. A user with write access to a shared calendar is not automatically authorized to trigger scheduling messages on behalf of the calendar’s owner unless this additional privilege is granted.
It’s unclear from the documentation whether Stalwart:
derives this privilege automatically from the regular calendar write/bind ACL (in which case this would be a bug), or
requires a separate, explicit grant of this privilege (in which case: how is this exposed to admins/users — is it available through the Web UI, JMAP Sharing, or only via a raw WebDAV ACL request against the owner’s scheduling outbox?), or
is simply not yet supported for this scenario.
Questions
Is sending iTIP/iMIP invitations “as” the owner of a shared calendar (by a user who only has calendar-sharing write access) currently supported?
If yes, what is the correct way to grant the necessary privilege — is there a Web UI / JMAP path for this, or does it require a manual WebDAV ACL request against the calendar owner’s scheduling outbox?
If no, is this planned, or is the recommended workaround to always create/send such events from the owning account itself?
Happy to provide further Live Tracing output, exact request/response payloads, or server version details on request.
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.
on