View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006254 | SOGo | Backend Calendar | public | 2026-10-12 14:45 | 2026-10-12 14:45 |
| Reporter | kvdb | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 5.12.11 | ||||
| Summary | 0006254: CalDAV stores and serves back duplicate RRULE and VALARM properties unchanged | ||||
| Description | Some CalDAV clients upload recurring events whose master VEVENT repeats the same RRULE many times, and whose master and RECURRENCE-ID overrides repeat byte-identical VALARMs. SOGo stores these objects as received and returns them through CalDAV to every other client, so one faulty client spreads the damage to every device that syncs the calendar. Seen on a production server (mailcow, SOGo 5.12.11), across 14 mailboxes:
Effect on other clients: Thunderbird shows the same reminder many times and cannot display the recurrence ("Repeat details unknown"); Android Etar can join the repeated RRULEs into one rule and crash while parsing the event. The duplicates come from a Thunderbird bug that appends one RRULE/VALARM copy per offline edit playback (https://bugzilla.mozilla.org/show_bug.cgi?id=1713625, fixed for Thunderbird 155, not in 140 ESR; also https://bugzilla.mozilla.org/show_bug.cgi?id=1999085). SOGo does not create them, but it keeps redistributing them after the client is fixed. RFC 5545 section 3.8.5.3 says RRULE SHOULD NOT occur more than once, and the recurrence set from multiple RRULEs is undefined. Multiple VALARMs are legal (section 3.6.1), so only alarms that serialize identically are duplicates. Distinct alarms must be kept (see 0004600). | ||||
| Steps To Reproduce |
| ||||
| Additional Information | Pull request: https://github.com/Alinto/sogo/pull/385 | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-10-12 14:45 | kvdb | New Issue |