Bug: subscriptions file

Timo Sirainen tss at iki.fi
Thu May 24 16:37:28 EEST 2018


I'd rather not add RFC-breaking settings. But there's IMAP4rev2 discussion going on in https://www.ietf.org/mailman/listinfo/extra <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 <ruga at protonmail.com> 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/4fdaafba/attachment.html>


More information about the dovecot mailing list