If something deletes and recreates the folder, it’s not really the folder to which you subscribed, is it?! On Wed, May 23, 2018 at 10:33 PM Aki Tuomi <aki.tu...@dovecot.fi> wrote:
> I understand that reading that paragraph makes it sounds obscure and > outdated. But the problem is that if something deletes & recreates your > folder, while you were gone, you would lose the subscription. This includes > other MUAs that are in no way obligated to resubscribe to the folder if > they do this. > > Aki > > On 23.05.2018 23:13, Rupert Gallagher wrote: > > Sorry for top posting, my client is still broken. > > I have never seen the ghost of a "system-alerts" or similar "well-known" > mail folder in the past 30 years. > > Compliance with an RFC obscure feature is compellong us all to clear > subscriptions > fol ders by hand. > > As we meet the problem over and over again, a non-RFC configuration option > could solve the problem, and it would be very much appreciated... > > > On Wed, May 23, 2018 at 11:57, Aki Tuomi <aki.tu...@dovecot.fi> wrote: > > > On 23.05.2018 12:31, Rupert Gallagher wrote: > > Dovecot does not clear the subscription file from non-existent folders. > > > Hi! > > Thank you for your bug report. Unfortunately this is not a BUG, but > mandated behavior by RFC3501, see last two paragraphs in the excerpt. > > Aki Tuomi > > 6.3.6. SUBSCRIBE Command > > Arguments: mailbox > > Responses: no specific responses for this command > > Result: OK - subscribe completed > NO - subscribe failure: can't subscribe to that name > BAD - command unknown or arguments invalid > > The SUBSCRIBE command adds the specified mailbox name to the > server's set of "active" or "subscribed" mailboxes as returned by > the LSUB command. This command returns a tagged OK response only > if the subscription is successful. > > A server MAY validate the mailbox argument to SUBSCRIBE to verify > that it exists. However, it MUST NOT unilaterally remove an > existing mailbox name from the subscription list even if a mailbox > by that name no longer exists. > > Note: This requirement is because a server site can > choose to routinely remove a mailbox with a well-known > name (e.g., "system-alerts") after its contents expire, > with the intention of recreating it when new contents > are appropriate. > > >
