Emails marked as read despite "keep unread"

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • bakvik
    Junior Member
    • Mar 2021
    • 22

    Emails marked as read despite "keep unread"

    My users are complaining this morning about that there emails are being marked as read in outlook immediately when EspoCRM fetches the email. They are using outlook connected via IMAP to a server. EspoCRM is polling the same server via IMAP (once per minute) to fetch new emails. The "keep fetched email unread" setting is checked. This happens for both group and personal emails.

    Was working normally last week. Upgraded to 7.0.0 over the weekend.
  • bakvik
    Junior Member
    • Mar 2021
    • 22

    #2
    Correction: Personal emails is ok.

    Only with a group emails the "keep fetched emails unread" setting seems to have no effect (emails are always marked as read). I confirmed this by connecting directly to the IMAP server on the command line and typing IMAP commands. Immediately after EspoCRM fetches the email it gets the \Seen flag.

    Anyone else seeing this? Bug?
    Last edited by bakvik; 10-04-2021, 09:28 PM.

    Comment

    • bakvik
      Junior Member
      • Mar 2021
      • 22

      #3
      I noticed a difference in the "keep fetched email unread" functionality in Services for personal email (starting line 488 in EmailAccount.php) and group email (starting line 399 in InboundEmail.php). Specifically, in InboundEmail.php (for group email) on line 401 "count($flags)" is in the condition, but it's not there in EmailAccount.php (for personal email). This means that if there are no flags on a message the if-block will run for personal email but not for group email. I can't really see the reason for this difference, so I thought maybe this a hint for the differing behaviour...
      Last edited by bakvik; 10-05-2021, 06:53 AM.

      Comment

      • bakvik
        Junior Member
        • Mar 2021
        • 22

        #4
        Well, after much labour with Wireshark watching IMAP protocol over the, that was it. I commented out the "count($flags)" condition in InboundEmail.php and it started working properly. Some IMAP servers will use other custom flags and with those "count($flags)" will always be true, but some servers don't use any flags except the standard ones, so with a new message there are no flags and that if-block won't execute. It should execute however to restore the flags to the state before reading the message via IMAP which implicitly sets the \Seen flag.
        So a bug it seems. Would the devs be so kind as to fix it as mentioned above? (I don't know how to do GitHub a pull requests etc)

        Comment

        • esforim
          Active Community Member
          • Jan 2020
          • 2204

          #5
          Might need to post in bug report to get attentions. However, let us risk wrath by pinging yuri

          Comment

          • yuri
            Member
            • Mar 2014
            • 8442

            #6
            If I remember correctly this check was added deliberately to prevent some issue. Unfortunately, it was not logged as a bug and I can't recall the reason. Not sure what to do yet.
            If you find EspoCRM good, we would greatly appreciate if you could give the project a star on GitHub. We believe our work truly deserves more recognition. Thanks.

            Comment

            • bakvik
              Junior Member
              • Mar 2021
              • 22

              #7
              It's not there in the EmailAccount.php for personal email, so whatever the reason was there's currently an inconsistency between the two files. The effect is currently that the "keep fetched emails unread" has no effect when new messages have no IMAP flags (they shouldn't have any of the standard ones, however some servers add custom flags - fastmail for example, however I'm sure plenty do not - Dovecot for example). I have the count condition removed in my instance where the users were complaining and it's fine now. But of course this will not last through the next upgrade.

              Comment

              • yuri
                Member
                • Mar 2014
                • 8442

                #8
                Added the fix to 7.0.2: https://github.com/espocrm/espocrm/c...2a0830c4ef855d
                If you find EspoCRM good, we would greatly appreciate if you could give the project a star on GitHub. We believe our work truly deserves more recognition. Thanks.

                Comment

                Working...