[
https://issues.apache.org/jira/browse/JAMES-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3642.
---------------------------------
Resolution: Fixed
Merged
> Buggy behavior with Android Email mobile application
> ----------------------------------------------------
>
> Key: JAMES-3642
> URL: https://issues.apache.org/jira/browse/JAMES-3642
> Project: James Server
> Issue Type: Improvement
> Components: IMAPServer
> Affects Versions: 3.6.0
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. Actual behaviour
> GIVEN Samsung Email mobile application
> AND connected to an IMAP account located on an IMAP James server
> AND load you emails (swap down if needed)
> WHEN Refresh your emails (swap down a second time)
> THEN the email account is rendered empty, only emails received since are
> displayed
> Another refresh restores the original email list....
> h3. Explanation
> The second refresh uses QRESYNC SELECT command with the last known
> modification sequence modifier.
> Thus James needs to compute the vanished responses (messages deletes since
> the last known modseq).
> As James do not store expunges, we should interate the supplied range and
> identify the missing items, for which we will send vanished responses.
> But James specifically filters out old messages from the liveness search,
> which results in all messages prior to the last known modification sequence
> to be considered deleted, effectively removing them from client cahe.
> h3. The fix
> Remove this buggy modseq condition: we should not answer that all old
> messages are deleted!
> Also to avoid a full scan we can detect the deletions from the UID <-> MSN
> mapping of the mailbox we just selected (yeah).
> h3. Alternative
> We could add a projection table tracking expunged messages - along with the
> modseq.
> However we should store all the history of deletions - otherwize some values
> as last known modseq would be rejected, and no client behaviour is specified
> in the spec if so.
> Also storing even more data have a bitter-sweat taste to me...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
