iMIP email for single-instance change of recurring event describes the master occurrence instead of the affected one

Issues
1

Issue Description

When a single instance of a recurring calendar event is modified, deleted, or cancelled, the iMIP notification emails sent to participants contain only the data of the original event in both the subject and the human-readable body. The iCalendar attachment itself is correct, but the email notification text is misleading: attendees are told an event was updated or cancelled without any indication of which occurrence is affected. The mail suggests it is the original, first event.

Expected Behavior

Imagine a daily event starting “September 1, 2026”.
When a single instance of a recurring event is cancelled or modified, e.g. “September 17, 2026” the iMIP notification email should describe that specific instance, at minimum showing its date/time, and ideally indicating that only that occurrence is affected.

Like this:

  • Subject: “Cancelled: Test Termin @ Thursday, September 17, 2026 at 3:00 PM (Europe/Berlin)”
  • Body:
    This event has been cancelled
    When
    Thursday, September 17, 2026 at 3:00 PM (Europe/Berlin)

Actual Behavior

The master event is referenced everywhere in the mail.

  • Subject: “Cancelled: Test Termin @ Tuesday, September 1, 2026 at 3:00 PM (Europe/Berlin)”
  • Body:
    This event has been cancelled
    When
    Tuesday, September 1, 2026 at 3:00 PM (Europe/Berlin), Every day

Reproduction Steps

  1. As the organizer, create a recurring event with at least 2 future occurrences and at least 1 other attendee
  2. As the attendee wait for the email invitation
  3. As the organizer, edit only one instance of the recurring event and cancel it.
  4. As the attendee inspect the iMIP email received.

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

Stalwart Version 0.16.22

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

2

Looking at the iTIP handling code, this matches what’s happening in Stalwart: when building the cancellation/update notification, the summary used for the subject and human-readable body is always generated from the “main” (master) instance of the recurring event rather than from the specific occurrence being modified.

In crates/groupware/src/scheduling/event_cancel.rs, the itip_cancel function builds the notification like this:

let instance = itip.main_instance_or_default();
message.components.push(build_cancel_component(
    instance.comp,
    sequence,
    dt_stamp,
    &[],
));
...
summary: ItipSummary::Cancel(instance.build_summary(None, &[])),

main_instance_or_default() always resolves to the master recurring event’s component, so the ItipSummary (which drives the subject line and “When” text in the notification email template) is built from the master’s DTSTART/RRULE, not from the specific RECURRENCE-ID instance that was actually cancelled or modified. The attached iCalendar payload itself does carry the correct RECURRENCE-ID/instance data (via build_cancel_component copying the instance’s own DTSTART etc.), which is why the attachment is correct while the email text is not.

This is a genuine mismatch between the iCalendar attachment and the human-readable notification text, confirmed in the current source. I don’t see any override path where a specific occurrence’s summary is used instead of the master’s for the email subject/body.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

This has been fixed in the v1.0.0 branch as part of a large calendaring refactor. v1.0 is expected at the end of October or early November.