The definition of insanity...

That's certainly not expected behavior. There's a known issue (possibly only with Gmail accounts) which I haven't been able to track down yet, but this looks different since no flags are stored at all.

Does it still happen after relaunching MailMate? If it does, could you try the latest test release of MailMate as well (hold down ⌥ when clicking “Check Now”).

I suspect that an issue like this is triggered by the state of a single message (UID 6279). Somehow MailMate thinks something needs to be updated, but it never realizes that this is incorrect. I wouldn't be surprised if this is related to the \Recent flag which MailMate has some issues with.

More data points:

Still happens with r5049 and r6044 on El Capitan.
Seems to only happen to mailboxes where rules are routinely applied automatically to many (in some cases all) new messages.
Could involve "\Recent" handling, as I have a smart mailbox that I thought would assure that nothing would keep the flag, but it seems not to work:

    {   countKey = "all";
        filter = "(#flags ~ '\\Recent' and #date < 2 days ago)";
        name = "Recent-NOT";
        parentUUID = "MAILBOXES";
        partitioningHeader = "#source.path";
        rules = (
            {   actions = (
                    {   disable = ( "\\Recent" );
                        type = "changeFlags";
                    },
                );
                description = "KillRecent";
                filter = "from ~ '@'";
            },
        );
        set = {
            operator = "Any";
            subSets = ( "ALL_MESSAGES", "DRAFTS", "JUNK" );
        };
        showAccounts = :true;
        uuid = "5A001477-413E-41D2-B0F8-13B9D330937D";
    }

Sent a crash report for this persistent spinning and throttling

I FINALLY was able to catch the start of this loop in an activity log. See attachment.

The summary of the action:

• There are 2 new messages in "AbuseMail" which have just been moved there by automation in another IMAP client from another (non-INBOX) mailbox in the same account. MailMate had not seen the messages in the original mailbox.

• MM attempts to synchronize "AbuseMail" by opening a new connection and using these commands:

  • SELECT AbuseMail
  • NOOP (why?)
  • UID FETCH 1:* (UID)
  • UID FETCH 1391:* (INTERNALDATE) (1391 is the first new UID)
  • UID FETCH 1:1390 (UID FLAGS) (CHANGEDSINCE 2414) (empty response)
  • 2 second gap, blank line in log, switch from 'D' to 'G' command prefix
  • NOOP (why?)
  • UID FETCH 1391:1392 (UID BODY.PEEK[] RFC822.SIZE)
  • UID FETCH 1391:1392 (FLAGS) (response shows both with only \Recent)
  • no time gap, blank line in log, switch from 'G' to 'H' command prefix
  • NOOP (why?)
  • UID FETCH 1392 (FLAGS) (WHY? You JUST saw \Recent and since you're still in the same SELECT session, it still is \Recent)
  • no time gap, blank line in log, still using 'H' command prefix
  • Verbatim repeat of NOOP, UID FETCH 1392 (FLAGS), and blank line, up to 20 times per second.

• The repeating NOOP & UID FETCH cycle only broke when I took the AbuseMail mailbox offline. Since \Recent is only valid for the life of a SELECT session in a mailbox, the offline/online cycle clears it.

Because this loop of commands executes so fast on both the server and client side, it is enough to make everything else MM does slow down, e.g. selecting a different mailbox in the UI results in a multi-second delay in the message list changing.

I've managed to find a reproducible case of this problem that I've been able to reduce to a small low-noise set of logs. Unfortunately, I can't upload the logs because Lighthouse says:

Upload Quota Reached

   Please notify the account owner.

I get the infinite loop on this one (read-only) mailbox on imap.ietf.org, an open-access public archive of IETF mailing lists. If I quit and restart MM, the looping resumes. This is the only case where i've seen that, and my theory is that it is due to the fact that MM can't actually update flags on the server side, while the server perversely keeps presenting the latest 2 messages as \Recent.

Oops, I forgot to mention that the mailbox which persists in this behavior is imap://anonymous@imap.ietf.org/Shared Folders/rfc-dist
You can log in with your email address as the password.

Interesting quirks:

   1. The sequence numbers in the mailbox perfectly match the UIDs
   2. MM seems to think it has no UID info for the 2 most recent messages

I've sent the log set to the mm-feedback address.