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: David Harris <David.Harris@pmail.gen.nz>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:43 -0000
Message-ID: 4C058BF2.22215.5F102940@David.Harris.pmail.gen.nz permalink / raw / eml / mbox
Hi all,

I think the answer to this is reasonably obious, but there's a slight 
ambiguity in RFC3501 that makes me want to check for sure.

Here's the scenario:

*   User moves a message from inbox to another mailbox.

*   User moves the same message from the other mailbox back to the 
    inbox.

The question is, does IMAP expect that the message will have the 
same UID after being moved back into the inbox?

To me, the answer to this question looks like it MUST be "no": there 
are too many scenarios where it becomes difficult or impossible, most 
notably if the UIDVALIDITY on inbox changes between the moves. 
There's also the fact that you'd have to have some kind of means of 
keeping a list of all the UIDs the message ever had in all the 
mailboxes it resided in at any time. In my view, when the message 
moves back to the inbox, it is effectively a different message.

The "ambiguity" I'm referring to in RFC3501 is in section 2.3.1.1, note 
4:

-------------------------- Cut here ----------------------------
         4) The combination of mailbox name, UIDVALIDITY, and UID
            must refer to a single immutable message on that server
            forever.
-------------------------- Cut here ----------------------------

It is possible to read this as meaning that once any specific message 
has been assigned a UID in a folder, it should always have that UID 
any time it is replaced in that folder, until such time as UIDVALIDITY 
changes.

I'd appreciate guidance on this.

Cheers!

-- David --

------------------ David Harris -+- Pegasus Mail ----------------------
Box 5451, Dunedin, New Zealand | e-mail: David.Harris@pmail.gen.nz
           Phone: +64 3 453-6880 | Fax: +64 3 453-6612

Real newspaper headlines from US Papers:
   "Milk drinkers are turning to powder".
Reply
E-mail headers
From: mrc+imap@panda.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:43 -0000
Message-ID: alpine.OSX.2.00.1006011543010.77397@hsinghsing.panda.com permalink / raw / eml / mbox
On Wed, 2 Jun 2010, David Harris wrote:
> *   User moves a message from inbox to another mailbox.
> *   User moves the same message from the other mailbox back to the
>    inbox.
> The question is, does IMAP expect that the message will have the
> same UID after being moved back into the inbox?

No.

Once a message is expunged from a mailbox its UID is gone forever (at
least as long as the UIDVALIDITY last).

Now, if the "move" was implemented as copy+delete WITHOUT expunging the
message in the source mailbox, then that message could be undeleted and
thus retain the same UID.  But in this case, it wasn't "moved back"
(except perhaps in a users GUI); it was never expunged.

However, that kind of "move" and "move back" would be a client-side
implementation.  A server has no latitude to make that kind of decision.

> It is possible to read this as meaning that once any specific message
> has been assigned a UID in a folder, it should always have that UID
> any time it is replaced in that folder, until such time as UIDVALIDITY
> changes.

Fortunately, that reading is incorrect.

Perhaps the text should have said "single immutable instance of a message"
instead of "single immutable message".

The incorrect reading would make sense in a world with global UIDs.  IMAP
does not have global UIDs.  If it did, it would require the invalidation
of either the property of strict ascendency of UIDs or the property that
new messages always are appended to the mailbox sequence space (instead of
inserted).

-- 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.
Reply