Hello,
We are currently testing SOGo 6 as a CalDAV backend for users who work
primarily with Apple Calendar and do not normally open SOGo Web.
External invitation replies reach the organizer's mailbox correctly, but
their PARTSTAT is only processed when the message is opened in SOGo Web.
For users relying exclusively on CalDAV clients, the attendee status
therefore remains unchanged.
From reading the SOGo 6 code, most of the necessary iMIP foundation
already seems to be present. ImipParser can parse complete MIME
messages, ImipProcessor handles REPLY messages, and the code identifies
a Celery mailbox scanner as an intended caller.
We have prepared a small preliminary patch that hardens METHOD:REPLY
processing:
- validates the organizer and replying sender, including SENT-BY
- requires the single ATTENDEE mandated by RFC 5546
- ignores replies for a different event revision
- avoids a database write when PARTSTAT is already current
- applies RECURRENCE-ID replies to the correct detached occurrence,
using that occurrence's own SEQUENCE
The current patch adds 55 production lines to ImipProcessor, together
with focused regression tests. All 650 calendar backend tests pass. It
does not yet contain the IMAP worker.
We can provide it immediately as a git-format-patch or publish a
reviewable commit if it would help evaluate the proposal.
Before implementing the background worker, we would like to confirm that
the general approach fits the project's direction. Our proposed design is:
- an opt-in, domain-configured periodic Celery job
- METHOD:REPLY only for the initial implementation
- the existing ClientImap with a domain IMAP service/master account
- SASL PLAIN authorization identity to access each target mailbox,
avoiding storage of individual mailbox passwords
- read-only INBOX selection
- UID and BODYSTRUCTURE polling, with BODY.PEEK[] used only for messages
containing a calendar part
- Redis checkpoints containing UIDVALIDITY and the last processed UID
- bounded, idempotent replay if checkpoint state is lost
- no changes to Seen flags and no moving or deleting messages
- no Mailcow-specific code
We also considered processing messages through an MTA delivery hook, but
that would couple SOGo to the mail-delivery stack of each deployment.
A periodic agent appears to follow the direction already described in
the parser while keeping the implementation within SOGo.
Would this be a useful contribution?
In particular, would you prefer a different authentication or checkpoint
boundary ? If the approach is suitable, would you be willing to accept
the implementation despite the repository currently being closed to
external contributions, and what contribution route would you prefer?
Regards,
--
Julien ARNAUD
🦆 DevOps & OpSec
(+33) 2 40 17 47 46
https://privacy.sib-retail.com
https://twitter.com/Annoying_Tech
