Bug: subscriptions file

[Roger Klorese]

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> 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> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20180523/b84d777c/attachment-0001.html>