Re: Bug: subscriptions file

[Rupert Gallagher]

I shall volunteer,
not to be chewed,
alive,
by the lions,
on this fine day.

Sent from ProtonMail Mobile

On Thu, May 24, 2018 at 15:37, Timo Sirainen  wrote:

> I'd rather not add RFC-breaking settings. But there's IMAP4rev2 discussion 
> going on in https://www.ietf.org/mailman/listinfo/extra. Someone motivated 
> enough could perhaps try to suggest changing this behavior in there.
>
>> On 23 May 2018, at 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  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.

Re: Bug: subscriptions file

[Timo Sirainen]

I'd rather not add RFC-breaking settings. But there's IMAP4rev2 discussion 
going on in https://www.ietf.org/mailman/listinfo/extra 
. Someone motivated enough could 
perhaps try to suggest changing this behavior in there.

> On 23 May 2018, at 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  > 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. 

Re: Bug: subscriptions file

[Rupert Gallagher]

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  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  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.

Re: 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 > 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 > 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
> 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.

Re: Bug: subscriptions file

[Roger Klorese]

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  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  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  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.
>>
>>
>>
>

Re: Bug: subscriptions file

[Aki Tuomi]

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  > 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 > > 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.
>

Re: 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  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  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.
>
>
>

Re: Bug: subscriptions file

[Aki Tuomi]

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  > 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.

Re: Bug: subscriptions file

[Rupert Gallagher]

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  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.

Re: Bug: subscriptions file

[Aki Tuomi]

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.