Jan,
Thank you for your response. What I am working
on is not an IMAP server in the conventional
sense but what I call an IMAP Server
Engine. Companies license it either to add IMAP
capability to an existing email server that lacks
it or, more commonly, to provide IMAP access to
other types of message stores such as voicemail
systems and email archives. The product is called MISE.
Pete Maclean
At 10:06 AM 2/8/2013, Jan Kundr?t wrote:
>On Friday, 8 February 2013 15:50:38 CEST, Pete Maclean wrote:
>
> > When a client has not enabled CONDSTORE and sends an ENABLE
> > QRESYNC command to a server that advertises QRESYNC capability,
> > should the untagged response say "* ENABLED QRESYNC" or "*
> > ENABLED QRESYNC CONDSTORE"? My reading of the spec tells me the
> > latter but I observe that another server sends the former.
>
>I believe that both of these are compliant. I
>haven't found a definitive answer on this in
>either 5161 (ENABLE) or 5162 (QRESYNC) RFCs. I
>have one suggestion for the actual
>implementation: please don't ever send EXPUNGE
>when QRESYNC is enabled, and never reference
>other UIDs in VANISHED than those which have
>been just expunged. These restrictions are not
>mandated by the current version of the RFC, but
>are very important for clients (they prevent an
>ambiguous state where the client suddenly
>doesn't know which UIDs still remain in the
>mailbox). Also, thanks for implementing QRESYNC;
>it's an extremely important RFC which improves
>the clients' behavior tremendously; the savings
>on traffic when opening mailboxes are huge. What
>IMAP server is the code you're working on? With
>kind regards, Jan -- Trojit??, a fast Qt IMAP
>e-mail client -- http://trojita.flaska.net/
>_______________________________________________
>Imap-protocol mailing list
>Imap-protocol@u.washington.edu
>http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol