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>
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. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20180524/bfc2842c/attachment.html>
If John Doe dies and a new John Doe is born, they?re not the same person, are they? On Wed, May 23, 2018 at 10:37 PM Aki Tuomi <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> 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/4fc4535b/attachment.html>