IESG Secretary | 27 May 19:32 2014

WG Action: Conclusion of IMAP QRESYNC Extension (qresync)

The IMAP QRESYNC Extension (qresync) working group in the Applications 
Area has concluded. The IESG contact persons are Barry Leiba and Pete 

With the publication of RFC 7162, the qrecync working group has
completed its work and will be closed. I thank Dave Cridland and
Eliot Lear for chairing, Alexey Melnikov for editing the updated
document, and all participants for their work on the update.

As always, the <imapext <at>> mailing list will remain open for
further discussion of IMAP extensions.

Barry Leiba, Applications AD

imapext mailing list
imapext <at>

Barry Leiba | 26 May 16:55 2014

Re: RFC 7162 on IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)

> A new Request for Comments is now available in online RFC libraries.
>         RFC 7162
>         Title:      IMAP Extensions: Quick Flag Changes
>                     Resynchronization (CONDSTORE) and
>                     Quick Mailbox Resynchronization (QRESYNC)
>         Author:     A. Melnikov, D. Cridland

And with the publication of RFC 7162, I will ask the Secretariat to
close the qresync working group.  Thanks to all for the participation,
and thanks to Dave Cridland, Eliot Lear, and Alexey Melnikov for being
chairs and authors.

Barry, Applications AD

imapext mailing list
imapext <at>

Jayantheesh S B | 14 May 23:00 2014

Contacts and Calendar Sync for IMAP Protocol

Hi All,


IMAP Lemonade provides solution for various problems and defines standards for various protocol, which is very useful for mobile environment.


We see lot IMAP extension like IDLE, QRESYNC, CONDSTORE are very useful for the end user, since it consumes less battery usage with less mobile data.


Similarly, we see apart from Email sync, Contacts and Calendar sync also gives lot of value addition and useful for end user.  


Right now we did not see any standard in IMAP for Contacts and Calendar sync. But Gmail does this with their own propriety protocol.  


Kindly throw some light on this and suggest if any standard protocol already available for Contact and Calendar Sync ?




imapext mailing list
imapext <at>
Cyrus Daboo | 14 May 18:08 2014

RFC 5524 - what is the proper capability to use?

Whilst researching the issue with missing capabilities in the IANA registry 
I ran into the following: RFC 5524 (Extended URLFETCH for Binary and 
Converted Parts) defines a capability string of "URLAUTH=BINARY" in section 
3 and the ABNF in Section 5. However, the IANA section uses 
"URLFETCH=BINARY", which is what IANA has registered at

The Dovecot server I use advertises "URLAUTH=BINARY".

So which is correct? What do other servers do? What do clients expect?


Cyrus Daboo

imapext mailing list
imapext <at>

Stephan Bosch | 14 May 18:08 2014

Re: METADATA and METADATA-SERVER not in IANA IMAP capability registry.

(ohw, somehow mailing list got dropped from To:)

Cyrus Daboo schreef op 14-5-2014 17:26:
> OK.
> I was going to do a quick scan and see if any other capabilities are
> missing. Here is what I found:
> AUTH= (3501) Not sure this is needed given it is in the base spec itself.
> URLAUTH=BINARY (5524) - actually this is bad. The spec uses
> "URLAUTH=BINARY" in section 3, but uses "URLFETCH=BINARY" in the IANA
> section (which is registered). However, the Dovecot server I use has
> "URLAUTH=BINARY". I do not see any errata for 5524 so this issue needs
> to be addressed.

Ow. That is quite bad indeed.

We didn't notice that either. Dovecot implementation is based on the ABNF.

I know of at least one other server that supports this capability: Cyrus 

I quickly grepped the source code and, luckily, it uses "URLAUTH=BINARY" 

Still, I wonder whether there are others. The list on the imapwiki is 
far from complete, nor up-to-date.

Isode was involved in writing this RFC, but I don't know whether they 
actually implemented it for their product. Dave?



imapext mailing list
imapext <at>

Stephan Bosch | 14 May 01:09 2014

METADATA and METADATA-SERVER not in IANA IMAP capability registry.


I just noticed that the IMAP METADATA and METADATA-SERVER capabilities
(RFC 5464) are not listed in the IANA IMAP capability registry:

Is there a particular reason for that?



imapext mailing list
imapext <at>

Nigar Sultana | 6 May 20:13 2014

Identifying new message from QRESYNC RFC5162

Hello All,

The understanding from RFC5162 is response to QRESYNC on selected mailbox returns the status of old message which is modified. 

There are few case for which i did not got much info in RFC5162: 
1. If the state of the old message is not changed but there are some new messages. The query is: Should server intimate the recent message UID information to client? 

2. If the state of the old message is changed but their are no new messages. -- The understanding is server returns the UID of old message which has the flag/state changes

3. IF the state of the old message is changes and there are some new message. The query is: should server intimate the recent messages UID information to client?

Nigar Sultana
imapext mailing list
imapext <at>
narendra singh bisht | 1 May 20:36 2014

Finding out REAL Drafts folder on an IMAP Server.

Hey there,


I don’t know how trivial this question is, but I’ve been thinking on this a lot.

How do I find the REAL Drafts folder on an IMAP server?

For Gmail and AOL, I could see there is some mapping in the response which will help me find out the server’s draft folder.

But for lot of others server, including, it seems there is no proper and consistent way to find the server’s Drafts folder.

Few flavors of Drafts folder name:





Please suggest a way to find it out.

Thanks & Regards
imapext mailing list
imapext <at>
Arnt Gulbrandsen | 25 Apr 14:30 2014

a very simple little imap extension, really quite magnificently simple


as some of you will have discovered, opening large mailboxes takes real 
time. So I discussed that with Brandon and wrote a draft, really short, 
perhaps it's actually shorter than the boilerplate. The gist: "If a client 
runs ENABLE UIDONLY, then that client cannot later use any MSNs in any 
commands, and if syntax forces the server needs to send an MSN, then it 
just sends a phony number." There are a couple of details.

Attached. Comments most welcome.


Network Working Group                                   Arnt Gulbrandsen
Internet-Draft                                                April 2014
Intended Status: Proposed Standard

                       The IMAP UIDONLY Extension

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at The list of Internet-
   Draft Shadow Directories can be accessed at

   This Internet-Draft expires in October 2014.

Gulbrandsen              Expires September 2014                 [Page 1]
Internet-draft                                                April 2014


   Opening a large mailbox in IMAP can take mailbox; 30 seconds is
   realistic if the mailbox contains ten million messages. Most of that
   time is needed to number the messages consecutively.

   This extension provides a way to avoid having to number the messages

1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   Formal syntax is defined by [RFC5234].

   Example lines prefaced by "C:" are sent by the client and ones
   prefaced by "S:" by the server. The five characters [...] means that
   something has been elided.

2.  Overview

   Some/many clients do not use IMAP MSNs at all, and rely entirely on
   UIDs. Some servers (notably gmail) take a long time to open very
   large mailboxes, since they have to compute an MSN for each message.

   This extension allows a client to declare that it only uses UIDs, and
   that the server can skip all processing related to MSNs.

   A client declares that it wishes to use this extension with the
   command ENABLE UIDONLY.

3.1.  Client requirements

   A client hat has issued ENABLE UIDONLY cannot use MSNs in any
   commands. This means that it MUST NOT use the FETCH, STORE and SEARCH
   commmands, that it MUST NOT use MSNs as search-key in the UID SEARCH
   command, and that it MUST NOT expect to receive an EXISTS response.

   While the client will still receive MSNs, it MUST NOT expect them to
   mean anything. (RFC editor: Remove this parenthesis. It seems to be
   easier to add support for UIDONLY by disregarding parsed MSNs than to
   change both the parser and the layer above, so I chose to leave dummy

Gulbrandsen              Expires September 2014                 [Page 2]
Internet-draft                                                April 2014

   MSNs in.)

3.1.  Server requirements

   These rules apply from the time the server has received an ENABLE
   command that enables UIDONLY until the TCP connection is closed.

   The server MUST send the number 999999999999999 when it needs to send
   an MSN. [RFC Editor: Change 999999999999999 to the number of this

   The server MUST send the UID data item in all FETCH responses,
   including untagged FETCH responses.

   The server MUST respond with BAD to any command that uses an MSN,
   including a UID SEARCH command that uses MSNs. This search command
   would retrieve the UID of the last message:

      C: a uid search *
      S: a BAD [CLIENTBUG] You promised not to use MSNs

   The following alternative is legal, since in this case the * is a UID
   rather than an MSN:

      C: a uid search uid *
      C: * SEARCH 10240901
      S: a OK done

   The server MUST NOT send EXISTS responses at any time (not even
   during SELECT/EXAMINE processing), and MUST send UIDNEXT when it
   would have sent EXISTS. For example:

      C: a idle
      S: +
      S: * OK [UIDNEXT 10240902] next UID

   The server MUST send VANISHED responses (see [RFC5162], section 3.6)
   where it would ordinarily send EXPUNGED responses. ([RFC5162] defines
   a large extension called Quick Resync, of which VANISHED is a small
   part. Note that neither the server nor the client need support or use
   Quick Resync in general.)

5.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur

Gulbrandsen              Expires September 2014                 [Page 3]
Internet-draft                                                April 2014

   Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the
   non-terminal "capability".

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

       capability   =/ "UIDONLY"

6.  Security Considerations

   This document is believed not to have any security implications.

7.  IANA Considerations

   The IANA is requested to add UIDONLY to the list of IMAP extensions,

8.  Acknowledgements

   Thanks to Brandon Long for helpful comments.

9. Normative References

   [RFC2119]  Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, Harvard University, March

   [RFC3501]  Crispin, "Internet Message Access Protocol - Version
              4rev1", RFC 3501, University of Washington, June 2003.

   [RFC5162]   Melnikov, A. and D. Cridland, "IMAP4 Extensions for Quick
              Mailbox Resynchronization", RFC 5162, March 2008.

   [RFC5234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, January 2008.

10. Author's Address

   Arnt Gulbrandsen
   Schweppermannstr. 8
   D-81671 Muenchen

Gulbrandsen              Expires September 2014                 [Page 4]
Internet-draft                                                April 2014


   Email: arnt <at>

Gulbrandsen              Expires September 2014                 [Page 5]
Internet-draft                                                April 2014

          (RFC Editor: Please delete everything after this point)

Open Issues


Changes since -00

Gulbrandsen              Expires September 2014                 [Page 6]
imapext mailing list
imapext <at>
Arnt Gulbrandsen | 15 Apr 21:35 2014

what we need is obviously .imap, so we can have dinner.friendsof.imap

Wrote one of my registrars: "You may be aware that a batch of new Top Level 
Domains (TLDs) from ICANN have started rolling out" and the first mentioned 
domain is:


God have mercy.

imapext mailing list
imapext <at>

Barry Leiba | 6 Mar 11:42 2014


IMAP denizens...

Chris Newman has asked that we consider moving the Multimailbox Search
extension to Standards Track (it was published as RFC 6237 as
Experimental).  Appsawg is handling that:

I'd like to ask the IMAP crowd to do two things:

1. Review the document and post comments to apps-discuss <at>

2. Tell us, in your review or separately here, if you (a) have
implemented it and/or (b) have interest in implementing it (and
specify client, server, or both).

Please take a few minutes to do this -- the document isn't long, and
we very much need the reviews to move this ahead.


imapext mailing list
imapext <at>