Open Bug 380399 Opened 13 years ago Updated 3 years ago

Return receipt status is only stored in .msf file and not in mbox file


(Thunderbird :: Folder and Message Lists, defect, major)

Not set


(Not tracked)


(Reporter: intendentedelleacque, Unassigned)


(Whiteboard: [dataloss?])

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; it; rv: Gecko/20070309 Firefox/
Build Identifier: 

If you receive a mail with a return receipt request, after the prompt the x-mozilla-status2 is not updated and it remains at the value of 0x0400000 instead of 0x0800000.
The return receipt status is stored just inside the msf file: in fact if you delete, with TB closed, the msf file, in that folder for the mails with the RR request the prompt is showed again, also if you've got it before.

Reproducible: Always

Steps to Reproduce:
1. create a new mail folder
2. receive a mail with a return receipt request
3. select it and click "Cancel" at the request prompt
4. see the source: the x-mozilla-status2 is still 0x0400000
5. close Thunderbird
6. delete the msf file for that folder
7. reopen Thunderbird
8. select again the mail

Actual Results:  
The request prompt is showed again and the X-Mozilla-Status2 is still 0x0400000

Expected Results:  
The prompt shouldn't be showed a second time and the X-Mozilla-Status2 should be updated at the value of 0x0800000 after the request prompt

Tested on Thunderbird 1.5.10 and on Linux and Windows XP
Post scriptum: notice that if I mark the mail as not read and the X-Mozilla-Status2 is updated at 0x0800000
I'm using SeaMonkey Mail 1.1.1 (on a Windows XP box) and experiencing the same problem. I only work with IMAP accounts.

Say I have a mail for which I have already answered the question if I want to send a return receipt. Then I'm asked again if I have moved this message to another folder then try to open it there. And I'm asked again when I try to read the same message on another computer. If I use the option "rebuild the summary file" in the folder options (in my german localization this is named "Zusammenfassungsdatei neu erstellen") the question is asked again, too. I assume that this last case is the same as deleting the msf file like the reporter of the issue explained.

I assume that the state for the return receipt is currently not saved in the mail itself (on the server) but this should be the standard case.
If your imap server supports the $MDNSENT keyword (or user defined keywords in general), then we do store this information on the server.
Assignee: mscott → nobody
IntendenteDelleAcque are you still able to reproduce this issue with latest TB release?

What you think about comment #3?
Component: General → Folder and Message Lists
QA Contact: general → folders-message-lists
Whiteboard: closeme 2009-11-13
Yes, it's still present in 20091005 version.
The comment #3 is not pertinent to my report, that concern POP3 accounts (sorry for having omitted that).

I repeat: with a POP3 account the  x-mozilla-status2 is not updated at 0x0800000 after the user cancels the RR request.

A workaround to force this is marking/unmarking "read" or "flagged" the message: in this way the  x-mozilla-status2 is updated at 0x0800000 (i use this workaround in my extension NEW RETURN RECEIPT HANDLER)
Whiteboard: closeme 2009-11-13
If someone has the time to test this, this bug should be confirmed based on comment #5
preetham, tony, can you reproduce?
Whiteboard: [dataloss?]
In reply to comment #7:

Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111127 Firefox/11.0a1 SeaMonkey/2.8a1 ID:20111127003001

All my mail accounts are POP3 (except RSS feeds and one Linux Movemail account for internal mail e.g. from cron to root).

In one mail folder I have messages from a mailing list where one poster always requests return receipts which I usually cancel. I usually leave the preview pane open when browsing that folder.

The latest five messages (all read) from that user all have "X-Mozilla-Status2: 10800000".

If this check is not enough, please be more specific about how to confirm or refute the problem.
intendentedelleacque, do you disagree with comment 8?
Hmmm, I think this problem is still around.


1 send yourself a test msg with Options > Return receipt checked (which adds Disposition-Notification-To: <> header)
2 When viewing msg with TB, before acting on the return receipt prompt:
Ctrl+U to see and save source as source-before.txt
3 on return receipt info bar, click "Ignore"
4 Ctrl+U to see and save source as source-after-ignore.txt
5 Repair folder containing the msg (folder list, right-click, properties, repair folder)

Actual result

4) source-before.txt and source-after-ignore.txt are identical;
above-mentioned flag remains unchanged:
X-Mozilla-Status2: 00000000
5) after repairing (reconstructing msf file), the return receipt prompt is shown again

Expected result

Reporter expects return receipt status to be saved in mbox file as X-Mozilla-Status2: 08000000 (not in msf file only);
repairing folder (reconstructing msf file) should preserve return receipt status
Ever confirmed: true
Severity: major → normal
Actually, this is datalossy (at least) and can be a major annoyance for pop users repairing their msf file which will lose all return receipt status information and bother them with return receipt prompts again.
Severity: normal → major
Hardware: x86 → All
Product should be MailNews.
You need to log in before you can comment on or make changes to this bug.