mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Dan Karp <dkarp@zimbra.com>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:40 -0000
Message-ID: 935361765.24151183780846496.JavaMail.root@dogfood.zimbra.com permalink / raw / eml / mbox
If there are 2 read-write sessions active on a mailbox to which a new message is added, one receives the message with \Recent set and one receives it without.  If there is 1 read-only session and 1 read-write session on the mailbox, is the server permitted to return the message as \Recent to both?
Reply
E-mail headers
From: guenther+imap@sendmail.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:40 -0000
Message-ID: Pine.BSO.4.64.0707062217220.4344@vanye.mho.net permalink / raw / eml / mbox
On Fri, 6 Jul 2007, Dan Karp wrote:
> If there are 2 read-write sessions active on a mailbox to which a new 
> message is added, one receives the message with \Recent set and one 
> receives it without.  If there is 1 read-only session and 1 read-write 
> session on the mailbox, is the server permitted to return the message as 
> \Recent to both?

Yes.  If the read-only session wins the race to be notified first, then 
both sessions will see the message as \recent.  If the read-write session 
wins the race, then it'll be the only one to see it as \recent.

I don't think there's anything to say that a server can't 'notify' a 
client by inserting an EXISTS (and possibly RECENT) placeholder into its 
output buffer but not actually sending it until it has received a command 
from the client.  The ordering between sessions of server-side actions 
such as these are often unobservable by clients, so a client can't depend 
on a particular ordering.  A server that *always* 'notified' all the 
read-only sessions before any read-write sessions would be odd (why 
bother?**) but presumably compliant.


Philip Guenther


** Hmm.  The read-only sessions could then represent the \recent flag with 
a single unchanging number (the UID of the first \recent message) instead 
of needing a bitmap.  Nah: having completely different code for read-only 
sessions would be a pessimization instead of an optimization
Reply