Well, ok, it is a feature, not a bug. I hope it will qualify as a bug for Thunderbird, because manual edit of the subscription file is just batshit crazy.
Sent from ProtonMail Mobile On Thu, May 24, 2018 at 07:33, 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 somethings 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.
