Bug: subscriptions file

[Peter Chiochetti]

Am 2018-05-24 um 07:38 schrieb Roger Klorese:
> If John Doe dies and a new John Doe is born, they’re not the same 
> person, are they?

They can even coexist, hundreds at a time. That is not a good analogy.

Peter

> On Wed, May 23, 2018 at 10:37 PM Aki Tuomi <aki.tuomi at dovecot.fi 
> <mailto:aki.tuomi at dovecot.fi>> wrote:
> 
>     That's rather difficult semantic question.
> 
>     Aki
> 
> 
>     On 24.05.2018 08:35, Roger Klorese wrote:
>>     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.tuomi at dovecot.fi
>>     <mailto:aki.tuomi at 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.tuomi at dovecot.fi <mailto:aki.tuomi at 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.
>>
>