On 23 Apr 2016, at 01:26, Joel Roth <joelz@pobox.com> wrote:

Hi Dovecot maintainers,

I'm maintainer of Net::IMAP::Client, a perl IMAP client library.[1]

I've had two bug reports related to Dovecot's in-progress messages.[2,3]

While patches have been submitted to resolve both of these bugs, I would like to minimize the possibilty of future breakage. Hence the following questions:

1. Which parts of the RFC are relevant to the in-progress messages?

2. Do you have a list of all of Dovecot's in-progress messages?

3. If, in future, other in-progress messages may be added, can you provide a standard syntax that I may use to strip them from the reply stream.

IMAP server is free to send any untagged replies to the client at any time. The IMAP clients should parse the wanted information from the received untagged replies and ignore the rest. It sounds like your IMAP library is doing exactly the opposite by treating any unexpected untagged replies as errors.

Here's an excerpt from the RFC:

Certain server data MUST be recorded by the client when it is received; this is noted in the description of that data. Such data conveys critical information which affects the interpretation of all subsequent commands and responses (e.g., updates reflecting the creation or destruction of messages).

Other server data SHOULD be recorded for later reference; if the client does not need to record the data, or if recording the data has no obvious purpose (e.g., a SEARCH response when no SEARCH command is in progress), the data SHOULD be ignored.

2. https://rt.cpan.org/Public/Bug/Display.html?id=84623

Strictly speaking a SEARCH command can return multiple untagged SEARCH replies, all of which should be merged together.. Luckily there are no servers actually doing it (that I'm aware of) and I'm not planning on changing Dovecot to do that either.

3. https://rt.cpan.org/Public/Bug/Display.html?id=113489

This isn't enough. There are other untagged replies that can be sent. Dovecot can also send "* NO .." while it's waiting for locks.

I'm also wondering how your client will behave when receiving unsolicited FETCH replies caused by other concurrent clients. For example this can happen:

x uid fetch 1:* internaldate

• 1 FETCH (UID 1 INTERNALDATE "22-Apr-2016 20:41:08 +0300")
• 2 FETCH (UID 2 INTERNALDATE "22-Apr-2016 20:41:08 +0300")
• 3 FETCH (UID 3 INTERNALDATE "22-Apr-2016 20:41:08 +0300")
• 2 FETCH (FLAGS (\Seen))
• 4 EXISTS x OK Fetch completed (0.001 + 0.000 secs).

Looks like Dovecot currently sends all these unsolicited responses after the requested replies, but that's not required by RFC. I'm not planning on changing it though, except that enabling NOTIFY extension can cause them to happen at any time.

Also, I assume your library doesn't try to use message sequence numbers for anything and in general doesn't try to keep track of the latest mailbox state? Because that would require tracking the EXPUNGE/EXISTS/FETCH replies, which could happen as a result of most of the IMAP commands (except EXPUNGE has restrictions).

Also a few links about writing IMAP clients:

http://imapwiki.org/ClientImplementation http://dovecot.org/imap-client-coding-howto.html http://dovecot.org/client-commandments.txt