mailing list archives

My apologies if this question has been asked before (I assume it has) but I'm not having any luck finding an answer in the archives.

I'm struggling to rationalize the following two statements in RFC 3501:


Section 2.3.1.1 states: Note: The next unique identifier value is intended to provide a means for a client to determine whether any messages have been delivered to the mailbox since the previous time it checked this value.



Section 6.3.10 states: The STATUS command MUST NOT be used as a "check for new messages in the selected mailbox" operation (refer to sections 7<http://tools.ietf.org/html/rfc3501#section-7>, 7.3.1<http://tools.ietf.org/html/rfc3501#section-7.3.1>, and 7.3.2<http://tools.ietf.org/html/rfc3501#section-7.3.2> for more information about the proper method for new message checking).



If both these statements are true, what is the recommended method to retrieve the next unique identifier value from a server?



Thanks,

Darren



________________________________
This e-mail and any files transmitted with it are ShoreTel property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20110217/d2090ea3/attachment.html>

On 17.2.2011, at 19.55, Darren Croke wrote:

> Section 2.3.1.1 states: Note: The next unique identifier value is intended to provide a means for a client to determine whether any messages have been delivered to the mailbox since the previous time it checked this value.
>  
> Section 6.3.10 states: The STATUS command MUST NOT be used as a "check for new messages in the selected mailbox" operation (refer to sections 7, 7.3.1, and 7.3.2 for more information about the proper method for new message checking).
>  
> If both these statements are true, what is the recommended method to retrieve the next unique identifier value from a server?

Use STATUS for getting UIDNEXT for non-selected mailboxes. For selected mailbox, hopefully you don't care about knowing the UIDNEXT value. If you do, see this thread: http://mailman2.u.washington.edu/pipermail/imap-protocol/2011-January/001339.html

On Thu, 17 Feb 2011, Timo Sirainen wrote:
> Use STATUS for getting UIDNEXT for non-selected mailboxes. For selected
> mailbox, hopefully you don't care about knowing the UIDNEXT value.

The latter point bears emphasis.

There is no particular reason why you should ever need the UIDNEXT value
for the selected mailbox.  Although most servers will give you the UIDNEXT
value at SELECT time, it is neither sufficient nor necessary for mailbox
synchronization with prior state.

The UID value of message * is far more important, as this will tell you if
there are new messages in the mailbox that need synchronization.  UIDNEXT
may tell you if there WERE new messages, but it will not tell you if there
ARE new messages.

Furthermore, UIDNEXT should rightfully be considered a guess.  It is
guaranteed that UIDNEXT is higher than any UID that has ever been assigned
to a message in the mailbox.  There is no guarantee that a new message
will given that value as its UID; it may be given a higher value.  Nor is
there any guarantee that UIDNEXT is monotonically greater than the highest
assigned UID.

Put another way:

A UIDNEXT value of 1234 guarantees that the highest UID ever placed in the
mailbox is, at most, 1233.  It does not in any way assert that UID 1233
exists now, or ever existed in the past.

A UIDNEXT value of 1234 guarantees that a newly delivered message will
have a UID of at least 1234.  It does not in any way assert that the
message will get UID 1234 as opposed to UID 1235, UID 69105, etc.

The fact that some servers assign UIDs monotonically does not mean that
servers are required to make monotonic assignments.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Just to make sure it's clear, and please excuse the pedantry:

> will given that value as its UID; it may be given a higher value. ?Nor is
> there any guarantee that UIDNEXT is monotonically greater than the highest
> assigned UID.
...
> The fact that some servers assign UIDs monotonically does not mean that
> servers are required to make monotonic assignments.

Mark doesn't actually mean "monotonic", here... UIDs are *always*
monotonically increasing, which only means that they increase but
never decrease -- a new UID is always greater than all old UIDs
(unless UIDVALIDITY changes).

What he means -- and the best single word that says it is
"sequentially" -- is that there's no guarantee that they increase by
one.  So, re-phrasing those two sentences above:

"Nor is there any guarantee that UIDNEXT is exactly one greater than
the highest assigned UID."
...
"The fact that some servers assign UIDs in strict '+1' sequence does
not mean that servers are required to make assignments that way."

-- Barry, ever pedantic but always striving for clarity

Thanks for all the answers to my question. An interesting side note--Microsoft Exchange 2007 rejects * as an invalid message set...

Darren

-----Original Message-----
From: mrc@hsinghsing.panda.com [mailto:mrc@hsinghsing.panda.com] On Behalf Of Mark Crispin
Sent: Thursday, February 17, 2011 12:46 PM
To: Timo Sirainen
Cc: Darren Croke; imap-protocol@u.washington.edu
Subject: Re: [Imap-protocol] detecting new messages

On Thu, 17 Feb 2011, Timo Sirainen wrote:
> Use STATUS for getting UIDNEXT for non-selected mailboxes. For selected
> mailbox, hopefully you don't care about knowing the UIDNEXT value.

The latter point bears emphasis.

There is no particular reason why you should ever need the UIDNEXT value
for the selected mailbox.  Although most servers will give you the UIDNEXT
value at SELECT time, it is neither sufficient nor necessary for mailbox
synchronization with prior state.

The UID value of message * is far more important, as this will tell you if
there are new messages in the mailbox that need synchronization.  UIDNEXT
may tell you if there WERE new messages, but it will not tell you if there
ARE new messages.

Furthermore, UIDNEXT should rightfully be considered a guess.  It is
guaranteed that UIDNEXT is higher than any UID that has ever been assigned
to a message in the mailbox.  There is no guarantee that a new message
will given that value as its UID; it may be given a higher value.  Nor is
there any guarantee that UIDNEXT is monotonically greater than the highest
assigned UID.

Put another way:

A UIDNEXT value of 1234 guarantees that the highest UID ever placed in the
mailbox is, at most, 1233.  It does not in any way assert that UID 1233
exists now, or ever existed in the past.

A UIDNEXT value of 1234 guarantees that a newly delivered message will
have a UID of at least 1234.  It does not in any way assert that the
message will get UID 1234 as opposed to UID 1235, UID 69105, etc.

The fact that some servers assign UIDs monotonically does not mean that
servers are required to make monotonic assignments.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

This e-mail and any files transmitted with it are ShoreTel property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed.  If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer.  Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited

On Tue, 22 Feb 2011, Darren Croke wrote:
> Thanks for all the answers to my question. An interesting side
> note--Microsoft Exchange 2007 rejects * as an invalid message set...

Sadly, this is not at all surprising.

The IMAP-savvy Microsoft employees (you can look at the archives of this
mailing list) were pulled off Exchange years ago.  Their replacements are
unimaginably inferior kids.  The results speak for themselves.

Microsoft has no intention of fixing their broken implementation of IMAP.
They have said so, repeatedly.

You face an unpleasant choice: either you comply with IMAP, or you comply
with Microsoft.

If you comply with IMAP, you have to read the specification, and possibly
use an ABNF syntax parser to follow IMAP's at times overly-subtle syntax
rules.

If you comply with Microsoft, it's easy; just implement the small subset
of IMAP that Outlook uses.  If you have a server, send any old nonsense
for the rest of IMAP.  If anyone complains about your client, say "it
works fine with Exchange, therefore it's a bug in your server."  If anyone
complains about your server, just say "it works fine with Outlook,
therefore it's a bug in your client."

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.