ProtonMail bridge sends unsolicited mailbox updates despite no IDLE command was issued by the client

[richardweinberger]

The following trace shows the problem.
My client does a "SELECT INBOX" and then nothing. All of a sudden the sever sends * 51989 FETCH (FLAGS (NonJunk) UID 51990).
IMHO this violates the IMAP protocol.
Unsolicited mailbox updates are only allowed as part of a command result or while the client is idling (after the IDLE command).

a LOGIN me@host password
a OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR CHILDREN IDLE MOVE ID QUOTA APPENDLIMIT=26214400 UNSELECT UIDPLUS] LOGIN completed
a SELECT INBOX
* FLAGS (\Seen \SEEN \Flagged \FLAGGED \Deleted \DELETED \Draft \DRAFT $Junk Junk NonJunk)
* OK [PERMANENTFLAGS (\Seen \SEEN \Flagged \FLAGGED \Deleted \DELETED \Draft \DRAFT $Junk Junk NonJunk)] Flags permitted.
* 51989 EXISTS
* 0 RECENT
* OK [UIDNEXT 51991] Predicted next UID
* OK [UIDVALIDITY 4] UIDs valid
a OK [READ-WRITE] SELECT completed
* 51989 FETCH (FLAGS (NonJunk) UID 51990)
a LOGOUT
* BYE Closing connection
a OK LOGOUT completed

[cuthix]

I think this is following RFC
https://datatracker.ietf.org/doc/html/rfc3501#section-7

An example of unilateral untagged server data occurs when the IMAP
connection is in the selected state. In the selected state, the
server checks the mailbox for new messages as part of command
execution. Normally, this is part of the execution of every command;
hence, a NOOP command suffices to check for new messages. If new
messages are found, the server sends untagged EXISTS and RECENT
responses reflecting the new size of the mailbox. Server
implementations that offer multiple simultaneous access to the same
mailbox SHOULD also send appropriate unilateral untagged FETCH and
EXPUNGE responses if another agent changes the state of any message
flags or expunges any messages.

which means here

* 51989 FETCH (FLAGS (NonJunk) UID 51990)

the server is notifying client that flag has changed to message with UID 51990

I agree that this part of IMAP is unfriendly for client implementation and we are trying to have changes to reply in more expected way in future.

If you understand and agree with my answer I suggest to close this issue.

[richardweinberger]

Hm, I understand this paragraph in a different way. it describes a response such as:

a FETCH 1:51744 (UID RFC822.SIZE)
...
...
...
* 51742 FETCH (UID, NIL RFC822.SIZE 9537)
* 51743 FETCH (UID, NIL RFC822.SIZE 1228)
* 51744 FETCH (UID, NIL RFC822.SIZE 1227)
* 51744 EXPUNGE
* OK [UNSEEN 51744] Message 51744 is first unseen
* 51744 EXISTS
* 51744 FETCH (FLAGS (NonJunk) UID 51833)
a OK FETCH completed

Here the server notices the client about a changed state on UID 51744 while a FETCH command ran. Same could have happened while a NOOP.

In my report the client did nothing at all and no command was running. But still, the server sent itself data.

The RFC on IMAP IDLE makes it IMHO very clear that without IDLE a client must poll to get updates.
Polling means executing NOOP or other commands where the response can contain unsolicited updates.
Only while the IDLE command is running the server is allowed to send updates without client initiation.
https://datatracker.ietf.org/doc/html/rfc2177

[cuthix]

Actually, that is good point. Unfortunately, this is hard to control from Bridge code base right now. We would need to make a significant refactor of underlying go-imap library in order to fix this. We are working on solution but in this stage it is very hard to give timeline.

[jameshoulahan]

This is not a bug. RFC3501 explicitly permits the server to send untagged responses pretty much whenever it wants (with a few exceptions); this is covered in section 5.3.