Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-3642

Buggy behavior with Android Email mobile application

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 3.6.0
    • 3.7.0
    • IMAPServer
    • None

    Description

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

      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.

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

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

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              btellier Benoit Tellier
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 50m
                  50m