Problem: read receipt doesn't send sometimes | MDaemon Technologies, Ltd.
  1. Forum
  2. MDaemon
  3. Problem: read receipt doesn't send sometimes

Problem: read receipt doesn't send sometimes

  • J

    Hi

    I have a user1 who have problems with the read receipts in mails send from another user2. Both of them are mdaemon's users.

    User2 send (forward, in fact) mails to user1 and, often, user2 marks the requesting a read receipt. When user1 opens the mail, she is asked for send o not send the mail with read receipt, then she always clicks on accept the read receipt. But, sometimes the read receipt mail arrives on user2's inbox and other it doesn't arrive.

    I've checked one mail sent by user2 and it obviously contains the header "Disposition-Notification-To".

    Also I've checked the logs and I see notifications of return with receipt sometimes, but other there aren't notifications.

    We have a video (unluckily with low quality) where the user1 accepts two ask read receipt, but neither of them is received by user2.

    How we can resolv this problem?

    Thank you and best regards

     

    Jorge

    0 likes
  • A

    What version of MDaemon are you using?

    What email client is User2 using?

    What email client is User1 using?

    What is the value of the Disposition-Notification-To header when the sender requests a read receipt? 

    Are there any other headers added by the client for the read receipt?

    What do the logs show is happening when user1 chooses to send a response to the read receipt but user2 does not receive them?  

     

    --
    Arron Caruth

    0 likes
  • J

    Hello Aron

    The version of Mdaemon is 24.5.2

    The email client of User2 is Thunderbird

    The email client of User1 is Worldclient with lookout theme.

    The value of the Disposition-Notification-To header when the sender requests a read receipt is:

    =?UTF-8?Q?Maria_Jes=C3=BAs_MXXXXXX_PYYYYY?=
     <user2@our.domain>

    I've changed the real data of the user2

    Yes, there other headers like:

    In-Reply-To:

    X-Forwarded-Message-Id:

     

    In the logs don't show any mail sent as response to the read receipt

    If you need the file of real mail, I could send it to you, but out of this forum

    Thanks

     

    0 likes
  • A

    So far I have not been able to reproduce the issue.

    Can you upload a MSG file from User1's mailbox where a read receipt was requested, the user1, choose to send a read receipt but it was never received?

    If you go to the WC folder in the user's mailbox and open the User.ini file, what value is set for "SendReadConfirmations"?

    If you look at the Domains.ini file in the MDaemon\WorldClient directory, is "SendReadConfirmations" in any of the sections?  If it is, what section and what is the value that is set?

    If you can upload the MSG file, copies of the user.ini, domains.ini, and the webmail log that includes the time period when user1 acknowledged the read receipt to https://mdaemon.sharefile.com/r-rc3922c1eed334d4dbf5e34f0bd04ccd6 I would greatly appreciate it.

     

     

    --
    Arron Caruth

    0 likes
  • J

    So far I have not been able to reproduce the issue.

    Please, notice that the problem unluckily happens only sometimes, not always, but the error occurs very often. Also, when user2 sends mails to others users requesting read receipt, the error still has not been detected yet.

     

    If you go to the WC folder in the user's mailbox and open the User.ini file, what value is set for "SendReadConfirmations"?

    There isn't any "SendReadConfirmations" directive in the user.ini file



    If you look at the Domains.ini file in the MDaemon\WorldClient directory, is "SendReadConfirmations" in any of the sections?  If it is, what section and what is the value that is set?

    Yes, it appears two times. Both of them with the same value: "SendReadConfirmations=Prompt". One in "[Default:UserDefaults]" section and the other in "[Default:UserOverrides]" section

     

    I've uploaded the next files:

    • message_from_user2.eml : message send by user2 (from her sent box). The mail correspondient to "message_user1.msg"
    • message_to_user1.msg : message received by user1 (from her inbox). The mail correspondient to "message_user2.eml"
    • message1_of_video.eml : message received by user1 which is appears first in video where the user accept the read receipt.
    • message2_of_video.eml : message received by user1 which is appears second in the video where the user accept the read receipt.
    • video.mp4 : the video where you can  see the user1 accepting the read receipt of "message1_of_video.eml" and "message2_of_video.eml" mails.
    • user.ini : "user.ini" file from WC folder of user1
    • domains.ini : from Mdaemon\WorldClient folder
    • Webmail-2025-02-03.old : webmail log  that includes the time period when user1 acknowledged the read receipts at about 14:00 h.

    The username of user1 is "adl"

    I hope you have all you need. If you need more information, please ask it to me.

    Thanks

    0 likes
  • A

    I was able to reproduce the issue and have submitted a bug for the development team.

    --
    Arron Caruth

  • J

    Ok, can we do anything to work around the problem while the bug is fixed?

    Thanks

    0 likes
  • A

    We have not found a way around it yet, but if we figure something out we will let you know.

    --
    Arron Caruth

    0 likes
  • J

    Ok Arron

    Thank you very much

    Best regards

     

    0 likes
  • A

    This has been fixed for the next MD 25.0.0 beta which we plan to release in the next few days.  We are planning to release MDaemon 25.0.0 to the public in March.

    We found that if the message was marked as read before the user choose to send the read receipt, then the read receipt would not be sent.  If you are using the message preview, you can reduce the frequency of this issue by not marking messages as read immediately.

    --
    Arron Caruth

    0 likes
  • J

    @Arron 

    Ok, thank you very much

    0 likes
Please login to reply this topic!