[MlMt] Ghost mailboxes

[Randall Gellens]

On 25 May 2018, at 11:27, Bill Cole wrote:

> On 25 May 2018, at 12:55, Randall Gellens wrote:
>
>>> You can use the GUI. Right-click the IMAP account -> "Edit IMAP 
>>> Account..." -> "Edit Subscriptions..." and uncheck the phantom 
>>> mailbox.
>>
>>
>> I don't see "Edit Subscriptions" under "Edit IMAP Account".  There's 
>> a pane to fill in the server info, account info, etc.
>
> Yes, and a button in the IMAP section.
>
> See attached image...

Ah, I hadn't noticed that, thanks.

Interestingly, on any account, clicking it results in an error dialog 
box:

	Mailbox Retrieval Failed

	Error: “Reading ended without error.”



>>> The root causes of this are that most IMAP servers don't 
>>> sanity-check the "subscriptions" list against the actual list of 
>>> mailboxes and that all MUAs for an account share a common 
>>> subscription list, so they tend to avoid exerting automatic 
>>> arbitrary control over it.
>>
>>
>> I guessed that perhaps MM doesn't refresh the mailbox list after 
>> deleting a mailbox.
>
> Yes, after a fashion.
>
> The issue is that there isn't One True Mailbox List, and MM does not 
> propagate the changes that it makes to the list of all available 
> mailboxes (by deleting a mailbox on the server) to the list of 
> mailboxes that are "subscribed" and as a consequence get synchronized 
> by MM and displayed to the user.

Admittedly it's been many years since I was active in IMAP protocol 
development and server-side work, but to my knowledge, the IMAP protocol 
is designed so the client asks the server for a list of mailboxes 
(typically using wildcards to get all).  This represents the list of 
mailboxes that exist (with flags to indicate if they are permitted to 
have children, etc.)  So, typically, a client periodically refreshes the 
list of all mailboxes by walking the mailbox tree and fetching all at 
each level, and does so after doing a delete or a move (which 
technically is a RENAME).

If I recall correctly from the days when IMAP was being developed, 
subscriptions were an afterthought that was glued on to the protocol to 
support shared mailboxes.  The IMAP protocol specifically allows for 
mailboxes that no longer exist to be on a user's subscription list, so a 
client should never assume that a subscribed mailbox exists.

I took a peek at RFC 3501 to refresh my memory, and it explains the 
reasoning behind non-existent subscribed mailboxes:

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


--Randall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20180525/99404b77/attachment.html>