SOGo: SEQUENCE not incremented on series cancellation (METHOD:CANCEL) — external clients reject the cancel

Component: SOGo Calendar (event modification / cancellation)
Severity: High — external participants silently keep stale events
Observed: 2026-10-19

Environment:

• SOGo 5.12.11 (running under Mailcow 2026-09a)
• External reference client for observation: Google Calendar (enforces SEQUENCE version ordering)

Summary

When an organizer reschedules a single occurrence of a recurring event and then cancels the entire series, the METHOD:CANCEL message for the base series contains no SEQUENCE property (implicit 0) — even though participants had just received SEQUENCE:1 for the single-occurrence change. Clients that enforce version ordering (Google Calendar does) discard the CANCEL as an older version (0 < 1) and keep all occurrences. SOGo participants remove the series correctly.

Reproduction

Works on a fresh instance with two SOGo accounts and one Google mailbox:

1. The organizer (SOGo) creates a recurring weekly series (e.g. 4 occurrences) with two participants: one SOGo user and one Google mailbox. Both sides receive the series correctly (same UID, same RRULE).
2. The organizer reschedules a single occurrence of the series in the SOGo Web UI (e.g. 19:00 → 20:00).
   • SOGo sends the exception instance (RECURRENCE-ID, same UID) with SEQUENCE:1.
   • Both participants process it correctly; Google shows the affected occurrence at the new time.
3. The organizer then cancels the entire series.
   • SOGo sends METHOD:CANCEL to all participants for the base-series UID.
4. Check: the SEQUENCE property in the CANCEL message (raw mail) and the result in Google Calendar.

Actual behavior

• The CANCEL for the base series contains no SEQUENCE property (implicit 0).
• SOGo participant: series is removed completely.
• Google Calendar: nothing is removed — all occurrences remain in the calendar. Google discards the CANCEL because the implicit 0 is lower than the last version it saw (1).

Delimitations:

• Google had applied the step-2 single-occurrence change correctly — only the CANCEL is discarded. Pure version-ordering behavior, not a general interop problem.
• The missing reply button in the CANCEL mail is normal (RFC 5546 requires no reply to CANCEL).

Additionally observed in the same deployment:

• Cancelling a single (non-recurring) event: the CANCEL carried SEQUENCE:1 — i.e. a copy of the last state, not an increment by one.
• Adding an attendee: SEQUENCE was left unchanged.

Expected behavior

RFC 5545 §3.8.7.4: SEQUENCE "MUST be updated with a new value that is incremented by one" whenever the iCalendar object is revised. The CANCEL for a series must carry a SEQUENCE greater than any SEQUENCE previously issued for that UID (base event or exception instances), so that all clients accept the cancel as a newer version.

Impact

If an organizer modifies one occurrence of a series and later cancels the series, every external participant (Google/Outlook/Apple) keeps the old occurrences indefinitely. Without manual cleanup or explicit communication, the cancellation is lost for them — unacceptable for production use.

Suggested fix

Always increment SEQUENCE by one when generating any revised component, including METHOD:CANCEL, and ensure the CANCEL for a series carries at least the maximum SEQUENCE previously issued for that UID (including exception instances).