SOGo: Adding an attendee to an existing event does not notify the existing attendees

Component: SOGo Calendar — attendee list modification
Severity: Medium — existing attendees are never informed about new participants
Observed: 2026-10-19

Environment:

• SOGo 5.12.11 (running under Mailcow 2026-09a)

Summary

When the organizer adds a new attendee to an existing event, only the new attendee receives the invitation. Existing attendees receive no message at all — not even one containing the changed attendee list. Their mailboxes keep the old ICS attachments; they learn about the new participant only through calendar sync, if at all.

Google Workspace and Microsoft Exchange send an updated invitation to existing attendees when the attendee list changes ("X has been added to the meeting"). RFC 5546 likewise treats a change of the attendee list as a modification of the iCalendar object to be communicated to the attendees.

Reproduction

Works with three SOGo accounts:

1. Organizer O creates an event with participant P1.
2. O adds participant P2 to the event (SOGo Web UI).
3. Check P1's mailbox and calendar.

Actual behavior

• P2 (new attendee): receives the full invitation with the correct current state (both ATTENDEEs, same UID). OK.
• P1 (existing attendee): receives no message. The ICS attachments in P1's mailbox remain the old ones (listing only P1 as ATTENDEE).
• The server-side event state is updated (P2 is visible in the event view); P1's CalDAV-synced calendar shows P2 correctly after sync.
• Side finding: SEQUENCE was not incremented for this modification (see also the separate SEQUENCE report).

Expected behavior

All existing attendees receive an updated invitation with the changed ATTENDEE list (and incremented SEQUENCE), so participants who work via e-mail are informed that another person has been added — comparable to Google Workspace and Exchange.

Impact

Existing participants are never told via e-mail that the event has grown by one person. In organizations where invitations are read by e-mail (planning, hierarchy, relevance or confidentiality of the added participant), this is misleading. With CalDAV-only clients the gap stays invisible — which is exactly why it goes unnoticed.

Suggested fix

On attendee-list modification, send all existing attendees an updated invitation (current event state, new ATTENDEE list, incremented SEQUENCE) in addition to the invitation sent to the new attendee.