[neomutt-users] Neomutt closing IMAP connections during mail download/querying

[Pietro Cerutti]

On Aug 14 2021, 19:22 UTC, Jonas Tobias Hopusch <jotoho at mailbox.org> wrote:
>Hello everyone,
>
>I have been having issues with neomutt for the last few days involving IMAP
>connection losses on (almost?) all interactions with the mail server.
>
>Every time I open a folder in neomutt it begins fetching the needed data
>before stopping with the message "Mailbox
>postmaster at jotoho.de@imap.mailbox.org geschlossen". (Translation: "Mailbox
>{imap_url} closed")
>
>It then apparently retries connecting before letting me into the folder but
>none of the mails are actually being shown. The mail selector (cursor)
>oftentimes hangs in the middle of an empty list of emails.
>
>To make the emails actually show, I then need to exit and reenter that folder
>again. When scrolling through bigger folders like my mail archive the client
>sometimes connects to the server again, just to fail with the same message as
>on opening the folder but with no obvious effect.
>
>Neither my secondary mail client on the same PC (evolution) nor K-9 Mail on
>my smartphone show any issues working with my mail provider. I wanted to find
>out which side was responsible for closing the IMAP connections so I took a
>look at the connections with the provider using Wireshark. Apparently the
>connections are closed due to my PC sending repeated TCP RESET packets.
>These things make me believe the issue lies on neomutt's side rather than my
>providers.
>
>Curiously, the ArchLinux website says that the package was not updated since
>February, so that excludes a change in neomutt from being the cause. Since my
>neomutt configuration is stored in a git repository, I was also able to
>confirm that recent changes in the neomuttrc file are not to blame by rolling
>back to the end of July when the issue didn't exist and confirming that the
>error still happened. The only thing I can think of is something like a
>breaking change or regression in a dependency of neomutt that broke stuff.
>
>Perhaps unrelated: Around the time this first happened, I had accidentally
>moved a folder of my mailbox into another folder using evolution before
>quickly moving them back to their normal place. This is the second time that
>happened and both times this caused "phantom folders" to appear in neomutt. I
>presume that they are (temporary) folders that existed while moving folders
>around and do not exist anymore but are still registered somewhere. 
>(Maybe in this mysterious list of "subscribed" folders on the server that's
>mentioned in the neomutt documentation? Don't know how IMAP works in detail)
>The phantom folders are neither shown in evolution, K-9 Mail nor the webmail
>client of my provider.
>
>Trying to open those phantom folders makes neomutt report that "IMAP command
>failed: a0044 NO Mailbox doesn't exist: twitch/software" but they still
>remain in the list of folders. (I'm using the option "set
>imap_check_subscribed" in neomuttrc)
>Since no issue like this happened the first time those phantom folders
>appeared I'm thinking that maybe those four phantom folders break some
>internal limit on tolerated IMAP errors that wasn't broken with only two
>phantom folders? Don't know if there is any merit to that train of thought.
>
>Please let me know if I need to provide any further information to help debug
>this issue.
>
>Thanks in advance.

Hi, I have two suggestions:

1. unsubscribe from the phantom folders, using :unsubscribe-from +Foo, 
and see if that helps some.

2. upgrade to NeoMutt master and see if the problem goes away. We have 
limited resources and unlikely to be able to debug very specific issues 
with months old releases.

Thanks,

-- 
Pietro Cerutti