MBOX-Line: From tss at iki.fi  Sun Mar  4 06:05:33 2012
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] recent response in status command
In-Reply-To: <4F536EBE.7080509@nfg.nl>
References: <4F53524C.3000308@nfg.nl>
	<ACDE4DFC-35B3-4CD9-80F9-DD2AB711BBC4@iki.fi>
	<4F536EBE.7080509@nfg.nl>
Message-ID: <5F81467D-EBB4-49AE-9F0A-2FB96A26580C@iki.fi>

On 4.3.2012, at 15.31, Paul J Stevens wrote:

>>> The 3rd session selecting
>>> the mailbox and fetching the flags *before* one of the selected sessions
>>> fetch them seems perfectly valid to me.
>> 
>> I'm not entirely sure what you mean. Anyway, what the test is supposed to do is:
>> 
>> - 1 and 2 connections have mailbox selected
>> - 1 connection APPENDs a new message
>> - most servers assign \recent flag to connection 1 before APPEND returns tagged OK
> 
> That smells to me like an implementation dependent choice, not a
> protocol dictated requirement.

That is, yes, that's but:

>> - just in case some server might have assigned it to 2nd connection, the 2nd connection does a NOOP

These two combined is a requirement.

>> - now imaptest knows that the \recent must be in either connection 1 or connection 2 (both connections have informed the client with EXISTS that there are new messages, so the \recent flag must have been set)
> 
> I'm here to learn, but I don't see this in the specs.
> 
> Returning an updated EXISTS response in a session doesn't imply that
> later on the client will actually request the message flags.
> 
> I understand a \recent flag must never be returned more than once or in
> more than one session. But as I (re)read rfc3501 a \recent flag is not
> assigned to a session until a FETCH FLAGS response was returned.

I don't understand how you can read it that way:

           Message is "recently" arrived in this mailbox.  This session
           is the first session to have been notified about this
           message; if the session is read-write, subsequent sessions
           will not see \Recent set for this message. 

The \recent flag is assigned immediately when any IMAP read-write (=SELECTed) session is notified about a new message. The untagged RECENT reply should also be sent after the EXISTS reply when the message is \recent for that session.

> I get the feeling there are undocumented semantics in play here. Doing a
> STATUS doesn't affect the mailbox, fine. So even when a STATUS response
> returns a RECENT > 0, it seems perfectly valid to me if subsequence
> SELECT/FETCH on the same mailbox with the same session don't return any
> messages with the \recent flag.

If this happens, then between the STATUS RECENT>0 and SELECT there was another session that had SELECTed the mailbox.

> What the test seems to imply is that following transcript with two
> sessions A and B is incorrect.
> 
> A status mailbox (messages unseen recent)
> * status mailbox (messages 1 unseen 1 recent 1)
> A select mailbox
> * 1 exists
> * 1 recent
> ...
> A ok [read-write] select completed
> 
> B status mailbox (messages unseen recent)
> * status mailbox (messages 1 unseen 1 recent 1)

If B STATUS was sent after A SELECT then yes, it's incorrect.

> B select mailbox
> * 1 exists
> * 1 recent
> ...
> B ok [read-write] select completed
> B fetch 1 flags
> * 1 fetch (flags (\recent))
> B ok fetch completed
> 
> A fetch 1 flags
> * 1 fetch (flags ())
> A ok fetch completed

And this is definitely incorrect. The \recent flag exists only in session A. It's not visible in any other sessions.

Dovecot implements \recent handling mostly in memory. The only thing that needs to be stored about recent messages is first_recent_uid, which gets updated to UID+1 whenever UID's \recent flag is removed in some session.
