Folder subscription issue

[Sebastian Hagedorn]

Hi,

I'm curious if this only happens for rename to trash, or for all renames
of subscribed folders. IMHO it makes no sense to automatically subscribe
to a folder in the trash. So perhaps the bug isn't in the replication
code but rather in the handling of rename to trash?


Am 10.07.19 um 11:11 Uhr schrieb Egoitz Aurrekoetxea:
> About the folder subscription issue, I think I got something, at least a
> close approximation... When a user causes in mua a rename mailbox (a
> rename for a folder caused by a folder move in hierarchy), after the own
> rename, if folders were subscribed “should” (for the "plain user" at
> least) become subscribed in the new path. It seems that after a user
> rename in Cyrus the new folder is automatically subscribed (even if no
> subscribe command is sent by the mua). But this, does not cause in the
> replica (in the slave, if SUB is not sent by the client)
> a sync_apply_changesub() or something like entering in the
> “ move_subscription” condition in mboxlist_renamemailbox(), and then,
> the folder is properly renamed but not subscribed in the slave. I think
> this is what I’m suffering. Obviously, if after a rename the mua sends a
> subscribe too, no issue is seen. I think the problem happens when a
> mailbox rename happens and a SUB is not send later.
> 
> An example : 
> 
> The folder domain.com
> <http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG
> is moved (renamed) to trash.
> 
> May 16 16:16:50 mx6c imap[83976]: conversations_rename_folder: renamed
> domain.com
> <http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG
> to domain.com <http://domain.com>!user.parta^partb.Trash.XINGANG
> May 16 16:16:50 mx6c imap[83976]: Rename: domain.com
> <http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG
> -> domain.com <http://domain.com>!user.parta^partb.Trash.XINGANG
> May 16 16:16:50 mx6c imap[83976]: Deleted mailbox domain.com
> <http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG
> 
> In the master (sync), the folder in Trash is subscribed but in the slave
> it is not, and remains subscribed the folder in the original location in
> the “____.sub” file.
> 
> A diff between the master (replication client) .sub file and the slave’s
> one is (mx5 is the master, the client and 6 the slave): 
> 
> --- subscripciones-mx5c/parta.partb.sub2019-07-10 08:47:29.000000000 +0200
> +++ subscripciones-mx6c/parta.partb.sub2019-07-10 08:48:08.000000000 +0200
> 
> +domain.com
> <http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG
> -domain.com <http://domain.com>!user.parta^partb.Trash.XINGANG
> 
> Perhaps a move_subscription to one or sync_apply_changesub should be
> forced in order to fix it?. I have seen issues with Outlook 2016 and
> Thunderbird… both mua… perhaps by RFC they should send the SUB command
> but… it’s the only theory I could arrive to… I have a ton more cases
> like this one.. Data gets properly handled but subscriptions have this
> issue (perhaps we could say is a mua issue but….)..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x197B06994D105B45.asc
Type: application/pgp-keys
Size: 17099 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190710/84a37e5c/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hagedorn.vcf
Type: text/x-vcard
Size: 333 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190710/84a37e5c/attachment-0001.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5367 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190710/84a37e5c/attachment-0001.p7s>