SOGo: Incoming REPLYs (accept/decline) are not automatically recorded in the organizer's calendar

Component: SOGo Webmail / Calendar — processing of incoming calendar replies
Severity: Medium — organizer sees stale attendee status; hidden manual workflow step
Observed: 2026-10-19, two independent cases (internal and external acceptance)

Environment:

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

Summary

When a participant's reply (METHOD:REPLY) arrives in the organizer's mailbox, SOGo does not update the attendee status in the calendar automatically. The status remains NEEDS-ACTION until the organizer opens the REPLY mail in Web UI and manually clicks "update status".

Google Calendar, Microsoft Exchange/Outlook, and standard CalDAV clients all process incoming REPLYs automatically — the manual click in SOGo is a workflow gap.

Reproduction

Works with two SOGo accounts:

1. Organizer A invites participant B to an event.
2. B accepts the event (in SOGo or in an external client, e.g. Gmail/Thunderbird).
3. A checks his SOGo calendar without clicking anything in the mailbox.

Actual behavior

• The event still shows B as NEEDS-ACTION; the calendar entry's LAST-MODIFIED does not change.
• Only after manually opening the REPLY mail in SOGo Web UI and clicking "update status" does the status switch to ACCEPTED — same UID, no duplicate.
• Second case (external participant, accepted in Gmail): exactly the same behavior — also recorded only after the manual click.

Expected behavior

A REPLY arriving in the organizer's mailbox is applied to the calendar automatically (status update, LAST-MODIFIED bumped, no duplicates) — as in Google Calendar, Exchange/Outlook, and CalDAV clients. The manual click should at most remain a fallback.

Delimitations (not bugs)

• The REPLYs were well-formed (METHOD:REPLY, PARTSTAT=ACCEPTED, correct UID, addressed to the organizer).
• The recording itself works correctly — only the automatic trigger is missing.

Impact

Organizers see wrong/stale attendee statuses (e.g. "pending" instead of "accepted") until they know about and perform the manual step. In busy mailboxes the REPLY mail is easily missed, leaving statuses silently wrong.

Suggested fix

Process incoming METHOD:REPLY messages for events organized by the local user automatically at mail delivery time — using the same correlation rules (UID + attendee address) that the manual "update status" button applies.