Freron MailMate

Comments and changes to this ticket

• 

  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.

• You flagged this item as spam.
  

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

• You flagged this item as spam.
  

  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 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 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 September 22nd, 2017 @ 12:54 PM

  • State changed from “fixcommitted” to “fixreleased”

  [bulk edit]