Bug Report: Calendar Scheduling, Duplicate Attendees, and Group Mailbox Routing

[mvthul]

Currently, there are bugs in Bulwark/Stalwart regarding calendar invites, specifically when Shared/Group mailboxes and delegate permissions are involved. The primary symptoms include:

1. Routing failures (invites not arriving or failing to send).
2. Creation of duplicate attendees upon Accept/Decline.
3. Incorrect sender identities when an admin accepts on behalf of a group.

To help track down where the JMAP/iMIP routing loop is happening, I have created a testing matrix to cover all permission-based scenarios.
Perhaps community can help test and possibly think of scenarios that would like to be tested.

🧑‍💻 The Actors

• User A (Manager): Internal User WITH Read/Write/Manage permissions to Group X and Group Y.
• User B (Standard): Internal User (No special group permissions).
• Group X (Shared): Shared Group Mailbox / Calendar 1.
• Group Y (Shared): Shared Group Mailbox / Calendar 2.
• User Ext (External): External User (e.g., Gmail, Outlook, Proton).

---

🧪 Test Matrix: Standard Routing (The Baseline)

Scenario	Sender	Recipient	Delivery	Accept Status	Decline Status
1. Internal -> Internal	User B	User A	✅ Works	✅ Works	✅ Works
2. Internal -> External	User B	User Ext	✅ Works	✅ Works	✅ Works
3. External -> Internal	User Ext	User B	✅ Works	✅ Works	✅ Works

---

🧪 Test Matrix: Internal User <-> Group Mailboxes

Testing how Bulwark/Stalwart handles an internal user interacting with a shared resource.

Scenario	Sender	Recipient (Action By)	Delivery	Accept Status	Decline Status
4. Manager to Own Group	User A	Group X (User A accepts)	[Pending]	[Pending]	[Pending]
5. Standard to Group	User B	Group X (User A accepts)	[Pending]	[Pending]	[Pending]
6. Group to Standard	Group X	User B (User B accepts)	[Pending]	[Pending]	[Pending]
7. Group to Manager	Group X	User A (User A accepts)	[Pending]	[Pending]	[Pending]

• Expected Behavior for Scenarios 4 & 5: When User A accepts the invite on behalf of Group X, Group X's calendar updates to Accepted. User A's personal calendar is unmodified. User B receives an RSVP from group-x@domain, NOT user-a@domain.
• Actual Bug: [Briefly describe the duplicate attendee creation here]

---

🧪 Test Matrix: External <-> Group Mailboxes (iMIP / WebDAV ACL)

Testing how external iCalendar data is parsed into a group, and how delegate replies are routed externally.

Scenario	Sender	Recipient (Action By)	Delivery	Accept Status	Decline Status
8. Group to External	Group X	User Ext (Ext accepts)	[Pending]	[Pending]	[Pending]
9. External to Group	User Ext	Group X (User A accepts)	[Pending]	[Pending]	[Pending]

• Expected Behavior for Scenario 9: When External invites Group X, and User A clicks "Accept" inside Group X's mailbox, the iMIP email sent back to the external user must have the ATTENDEE and From address set to Group X, completely hiding User A's identity.

---

🧪 Test Matrix: Cross-Group Delegation (The Edge Cases)

Testing complex delegate routing when a user manages multiple shared resources.

Scenario	Sender	Recipient (Action By)	Delivery	Accept Status	Decline Status
10. Group to Group	Group X	Group Y (User A accepts)	[Pending]	[Pending]	[Pending]

• Expected Behavior for Scenario 10: User A creates an event in Group X and invites Group Y. User A then opens Group Y and accepts the invite. Group Y updates to Accepted. Group X logs that Group Y accepted. No duplicate attendees are generated.

---

Technical Note for Maintainers:
Based on the duplicates being created, it appears that when a delegate (User A) triggers an RSVP for a shared resource (Group X), the server/client is either injecting the Principal of the acting user into the attendee list, or failing to match the CalDAV/JMAP ORGANIZER/ATTENDEE tags correctly against the shared mailbox's identity.

I will update the [Pending] statuses as I work through the permutations.
These are for enterprise environment really important to work correctly!