[MlMt] “Contains both $Junk and $NotJunk flags”

[Bill Cole]

On 24 Jun 2020, at 17:51, Dave C wrote:

> I get this error:
> - - -
> MailMate encountered the following error: “Server response: “I8 
> BAD [CLIENTBUG] APPEND Contains both $Junk and $NotJunk flags”.”.
> Mailbox: “Inbox”.

Interesting... I have not seen a server which enforces that before.

> - - -
> First question: What exactly is causing this error and how to fix it? 
> “Try again” and “try later” simply result in repeated errors.

Somehow you have set both the "$Junk" and "$NotJunk" flags on a message 
in such a way that MailMate is trying to set them both (i.e. with an 
IMAP 'APPEND' command) and the server objects to that.

I think the solution is to take the account offline and fix the flags on 
that message so that it has at most one of $Junk and $NotJunk set. After 
that, bringing the account back online should allow MM to sync properly.

> Second question: Why is this a fatal error? (I have to take the 
> account off-line to get MM to continue). Shouldn’t this be an 
> “informational” error and not cause the account to fail?

Probably, in theory. The "Try Later" option should be essentially that 
although "Later" may be immediate if you have the mailbox configured to 
run in "Connected" mode (common for the Inbox.) MM works to stay 
perfectly in synch with the server, so if you have a flag change which 
has not been pushed to the server and an open connection with the right 
mailbox selected, MM will try to transmit the change. Benny has never 
implemented non-modal error notification and it is literally impossible 
for an IMAP client to differentiate between 'BAD  [CLIENTBUG]' 
responses. All MM can know is that the APPEND command that it tried 
failed because of something that the server considers improper in the 
command. It is possible (only Benny can say...) that MM has no concept 
of possible dependencies between tasks which are queued for an account 
or mailbox and it prevents problems by simply making sure that changes 
are done in a rigid order. Rather than continuing after a command has 
failed, possibly with commands that are predicated on the success of the 
failed command, MM stops doing anything that might be dependent.

-- 
Bill Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire