#1343 accepted
Bill Cole

\Recent message flag is improperly preserved

Reported by Bill Cole | December 7th, 2015 @ 11:07 PM

I don't have any insighton what the best approach would be for an IMAP client of MM's general design to do with the standard server-managed "\Recent" IMAP flag and I am fairly sure that there are servers which fail to manage it as described in RFC3501, but I'm convinced that MM's handling (which persists the \Recent flag on a retrieved message indefinitely, it seems, until some event causes MM to re-check flags?) is Not Right.

As you might guess, I like the idea of being able to use \Recent as a selector for smart mailboxes, despite its dubious usefulness as specified, but I have found that doing so is mostly interesting as an exercise in trying to solve the puzzle of how it is possible for similar sequential messages in the same source mailbox to have different \Recent states (according to MM) a week after they were first seen.

Comments and changes to this ticket

  • benny

    benny December 8th, 2015 @ 08:24 AM

    • State changed from “new” to “accepted”

    Yeah, I've been postponing looking into it, but I've noticed this too. I'm pretty sure it broke down after I started using the IMAP CONDSTORE extension, but I haven't verified this. Apparently, some/all/most IMAP servers do not report when the \Recent flag changes. If this is correct then I need to always explicitly check the flags of \Recent messages. That's not a performance problem. It's just yet another IMAP server workaround.

    Let me know if you think this theory is incorrect.

  • Bill Cole

    Bill Cole December 8th, 2015 @ 02:41 PM

    Apparently, some/all/most IMAP servers do not report when the \Recent flag changes.

    This is inherent in the semantics of \Recent. I think you can rely on a message no longer being \Recent the next time you SELECT the mailbox, but the status may persist for a whole session. I've looked at https://tools.ietf.org/html/rfc3501#section-2.3.2 and https://tools.ietf.org/html/rfc3501#section-7.3.2 and and am still not quite sure what a client should expect within one IMAP session, although it is clear that at least one session will see \Recent set on a message one time it looks.

    I confess that when I first tried to use \Recent I had mis-remembered its formal spec and I'm not sure that it can really be useful. It almost seems like Mark Crispin's tribute to Heisenberg and Schrödinger, particularly this bit from RFC3501 S.2.3.2:

      If multiple connections have the same mailbox selected
      simultaneously, it is undefined which of these connections
      will see newly-arrived messages with \Recent set and which
      will see it without \Recent set.
    

    So: at least one session will see it set at least once but once it is seen set, all later sessions will see it unset. How (and whether) a multi-session client should present that to users is not really obvious.

    I need to always explicitly check the flags of \Recent messages. That's not a performance problem. It's just yet another IMAP server workaround. Let me know if you think this theory is incorrect.

    Slightly: I don't think you will ever be notified of \Recent changing (e.g. in IDLE) but you shouldn't need to explicitly check for it. Instead I think you can safely assume that a previously \Recent message will no longer be so when a different session SELECTs or EXAMINEs its mailbox.

  • benny

    benny December 8th, 2015 @ 04:18 PM

    In my first reply I considered writing that I wasn't really sure \Recent was useful for offline IMAP, but I couldn't recall the exact definition (too lazy to look it up).

    Good point about assuming \Recent is cleared on next SELECT, but this relies on the server to implement \Recent as specified by the RFC. I don't think it's unlikely that many IMAP servers get it wrong and this could result in MailMate changing the flag multiple times (because it might rediscover an incorrectly uncleared \Recent flag on the server).

  • Bill Cole

    Bill Cole June 5th, 2017 @ 07:10 PM

    • Tag cleared.

    Regarding this:

    I don't think it's unlikely that many IMAP servers get it wrong and this could result in MailMate changing the flag multiple times (because it might rediscover an incorrectly uncleared \Recent flag on the server).

    A correct client-side handling of \Recent can't have that problem because RFC3501 says:

        Note: The \Recent system flag is a special case of a
        session flag.  \Recent can not be used as an argument in a
        STORE or APPEND command, and thus can not be changed at
        all.
    

    So if MM sees a message with a persisting \Recent flag, it shouldn't even TRY to remove it.

  • benny

    benny June 6th, 2017 @ 01:34 PM

    By “changing it multiple times” I did not mean that MailMate changed it, but that MailMate would reflect that it changed on the server (which could happen multiple times if MailMate assumed it was changed on the server without checking it).

    But it would probably be better if MailMate assumed it was cleared on the next SELECT as you suggest. Right now these \Recent flags make very little sense in MailMate (for some servers).

  • benny

    benny June 9th, 2017 @ 09:00 AM

    • State changed from “accepted” to “fixcommitted”

    I've added a workaround to MailMate handling the \Recent flag (when combined with CONDSTORE which is the reason it doesn't currently work well). MailMate keeps track of the smallest UID having the \Recent flag enabled. This and later messages are then always checked for flag changes when selecting the mailbox.

    (I've spotted a few persistent \Recent flags since implementing this. I think this is caused by the order of implementation, but it might also be a bug. I'll keep an eye on it.)

  • benny

    benny September 22nd, 2017 @ 12:54 PM

    • State changed from “fixcommitted” to “fixreleased”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

People watching this ticket

Pages