June 28, 2026 at 4:18 AM, "Oswald Buddenhagen via isync-devel" <[email protected] mailto:[email protected]?to=%22Oswald%20Buddenhagen%20via%20isync-devel%22%20%3Cisync-devel%40lists.sourceforge.net%3E > wrote:
> > > > The server is RFC-compliant: > > > i doubt it. > > rfc4551 section 1 says: > > > > > > > > > A client supporting CONDSTORE extension indicates its willingness to >> > > > receive mod-sequence updates in all untagged FETCH responses by >> > > > issuing: > > > [...] > > > This document uses the term "CONDSTORE-aware client" to refer to a >> > > > client that announces its willingness to receive mod-sequence updates >> > > > as described above. > > > > > > it doesn't explicitly state that the server MUST NOT send anything > condstore-related otherwise, but it's kinda implied. > > rfc7162 updates the extension, and its section 3.1 says: > > > > > > > > > A client supporting the CONDSTORE extension indicates its willingness >> > > > to receive mod-sequence updates in all untagged FETCH responses by >> > > > issuing one of the following, which are called "CONDSTORE enabling >> > > > commands": > > > [...] > > > Once a client issues a CONDSTORE enabling command, it has announced >> > > > itself as a "CONDSTORE-aware client". > > > > > > this _still_ doesn't explicitly _forbid_ unsolicited condstore-related > behavior, but it tries _really_, _really_ hard to imply it. one has to be > particularly dense to not get the hint. Fair enough — you're right, and I withdraw that framing. mbsync never issues a CONDSTORE-enabling command, so under 7162 §3.1, it never becomes CONDSTORE-aware, and the server should not volunteer MODSEQ. > in summary, the server is simply broken. in fact, dovecot agreed last time > this has happened: > https://dovecot.org/list/dovecot-news/2014-October/000276.html Agreed: the v2.2.14 changelog says "MODSEQ was sent in FETCH reply even if CONDSTORE/QRESYNC wasn't enabled." Upstream already fixed this in 2014, so Migadu is running something modified or regressed. The targeted MODSEQ skip isn't the right fix for the tree — please drop the patch. > so please report the problem to the provider, and ask them to ensure that > upstream is aware of the issue if it's not due to a local modification. Will do — I'm filing it with Migadu now, citing 7162 §3.1 and the v2.2.14 fix, and asking them to confirm whether it's a local patch or stock Dovecot and to fix/report upstream. > i would consider a workaround that generally discards unknown data items > (issuing a warning about it once per store), but i'll do that only if the > server isn't fixed soon. Makes sense. No urgency on my end — I'm running a locally patched mbsync in the meantime. If Migadu doesn't reply and you do add the general discard-unknown-items tolerance, I'm happy to test it against the live server. Thanks for the quick and thorough review. Tyler _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
