Closed Bug 598027 Opened 14 years ago Closed 13 years ago

Thunderbird sends two read receipts every time, if "Return receipts : Always send" is set

Categories

(MailNews Core :: Backend, defect)

x86
Windows XP
defect
Not set
minor

Tracking

(thunderbird3.1 .10-fixed)

RESOLVED FIXED
Thunderbird 5.0b1
Tracking Status
thunderbird3.1 --- .10-fixed

People

(Reporter: stevel, Assigned: Usul)

Details

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Lightning/0.8 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0

We have Thunderbird set up both for internal e-mail and external. The internal is IMAP through our CentOS server and dovecot. External is POP3 through our website and our hosting service. On both profiles Thunderbird sends two read receipts when mail is read. Switching to "Ask me" for the read receipts sends only one. Other than the two read receipts everything else works just as it should. 

Reproducible: Always

Steps to Reproduce:
1. Receive mail that requests a read receipt with the auto send receipt feature on
2. Read that e-mail
3. Close the e-mail
Are you really running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) ?
(In reply to comment #1)
> Are you really running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.8.1.14) ?

I did not notice the "about screen" from Thunderbird had that data. We are using Windows XP SP3 and Thunderbird 3.1.4
As a test this morning I set up another client to use only the imap server and it also sends two read receipts upon opening mail. One other thing that may help is only one read receipt is sent if the "return receipts" is set to "ask me"
So are the delivery receipt sent exactly the same, isn't one a return receipt and the other one a delivery receipt ?
(In reply to comment #4)
> So are the delivery receipt sent exactly the same, isn't one a return receipt
> and the other one a delivery receipt ?

Both are return receipts and appear to be identical
Confirmed with Tb 3.1.4.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

(0) POP3 account-1 of Tb, mail-addr-1. SMTP-1 is used.
      mail-addr-2 is not defined as identity.
      Fetch Header Only(and Leave Messages on Server=on)
      Return receipts : Always send at any option.
    POP3 account-2 of Sm, mail-addr-2, SMTP-2 is used.
(1) Sm: Compose and send a mail with MDN=on, From:mail-addr-2, To:mail-addr-1
(2) Tb: Get Mail, view arrived mail(partially downloaded mail)
(3) Sm: Get Mail at POP3 account-2 => Two return receipts appear
(4) Tb: Get whole mail data via "Click Here" link => whole mail is shown
(5) Sm: Get Mail at POP3 account-2 => Third return receipt comes
(6) Tb: Connection timeout at SMTP-1, due to connection count limit of server.
        because I use many sessions for multiple accounts of an ISP's server
        at same time using Sm, Tb on one PC.
        It's for forth return receipt.
=>
Two return receipts for partially downloaded mail.
Two return receipts for fully downloaded mail.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed with Tb 3.1.5 when 'Allow return receipts for some messages' is set to 'Always send'. POP3 account. English and Polish versions.
Both receipts seems to be identical, except that when Polish special characters (ążśźćęłńó) are used in 'Your name' field then one receipt is correct and the other one has garbled text.
Dear Thunderbird Developers - please add 'Return receipt' to Thunderbird QA checklist as this is not the first bug that is connected with this important feature. Most of organisations depend on it.
(In reply to comment #7)

> Dear Thunderbird Developers - please add 'Return receipt' to Thunderbird QA
> checklist as this is not the first bug that is connected with this important
> feature. Most of organisations depend on it.

Dear user it is on my check list and is something I check for all releases. I just can't test all combinations. but feel free to join our beta channel (http://perso.hirlimann.net/~ludo/blog/archives/2010/09/we-need-more-user-on-the-beta-channel.html) so you'll be aware of the issue before we do releases :D 

What would be nice is to figure out when this started happening so we can figure ou what is causing this , while it wasn't happening in the past. Would it be possible for one of the reporters to follow the instructions at http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/ and give us the first version when this started happening and the last version where it worked correctly ?
(In reply to comment #8)
> Dear user it is on my check list and is something I check for all releases. I
> just can't test all combinations. 

Hard to believe as this is happening 'Out of the box' for POP3. Not to mention 'Constant receipt sending bug' luckily fixed few releases ago.

> but feel free to join our beta channel [...]
> What would be nice is to figure out when this started happening so we can
> figure ou what is causing this , while it wasn't happening in the past. [...]
> and give us the first version when this started happening and the last version
> where it worked correctly ?

Will do, as this kind of annoyances don't help to be considered 'Professional Outlook replacement' by our users (already bug 77811 is a big headache - luckily solved again recently by lookout add-on).
Confirmed in:
3.1 (there it sends receipts constantly)
3.1.1
3.1.2
3.1.3
3.0.6 not affected.
Michiel does this helps ?
Confirmed in 3.1.6.
Confirmed in 3.1.7pre (Gecko/20101116 Lanikai).
3.0.10 not affected.
Confirming this is probably teasing many users including our company, just the bug here is quite hard to find. 
It started with the Thunderbird 3.1.
One of the two return receipts doesnt have From header properly encoded and doesnt contain Message-id. 
Otherwise are the same.
Also, it doesnt happen every time, just about 90% of times. (May be due to mail server choking up with return receipts in some cases).
Confirmed in 3.1.7. As unaffected Tb 3.0.x is in EOL state this bug is not minor anymore. This should be blocker imho.
Confirmed in 3.1.8 (rv:1.9.2.14; Gecko/20110123) - thunderbird/nightly/3.1.8-candidates/build1/win32/pl.
Summary: Thunderbird sends two read receipts every time → Thunderbird sends two read receipts every time, if "Return receipts : Always send" is set
Confirmed in 3.3a2 (rv:2.0b10pre; Gecko/20110114) - both receipts have Polish national characters garbled (sender's name) .
This is affecting our entire company. All users on either 3.1.6 or 3.1.7. IMAP Mail Server. 
Sender has option checked: When sending messages, always request a return receipt. 
Recipient has: Allow return receipts for some messages > In all other cases: Always send. 
Sender receives TWO return receipt replies for each message.
Can you guys list what server you are using ?
(In reply to comment #20)
> Can you guys list what server you are using ?

Sun Microsystems PMDF
(In reply to comment #20)
> Can you guys list what server you are using ?

Ludo, server is irrelevant to this bug. This bug is Tb's real bug when Tb's option of "Return receipts : Always send" is set, and workaround is already known; "Return receipts : Always ask".
Should I do binary search of trunk nightly builds for culprit build who had started to generate this bug's problem?
Judging by the checkins from when 3.0 was released to when 3.1 was released:

http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-12-08&enddate=2010-06-24

There seems to only be two candidates for the regression window, either bug 151244 or bug 536704.

However, bug 536704 was also checked in to 3.0.x, so 3.0.6 shouldn't work if it's the cause (this contradicts comment 10).

Thus, it seems highly likely to be bug 151244, which was not in the 3.0.x versions. Thus, the patch in this bug might have caused the regression.

cc'ing mvl, bienvenu and Standard8..
I can't get auto sending of return receipts to work at all, on the trunk.
The intention of that line is to send a receipt. Does that line send two receipts, or just the second receipt? If the former, we should look into the function that is called. Otherwise, can you figure out where the first receipt is send?
(In reply to comment #26)
> The intention of that line is to send a receipt. Does that line send two
> receipts, or just the second receipt? If the former, we should look into the
> function that is called. Otherwise, can you figure out where the first receipt
> is send?

When I comment out line 1030, only one return receipt is sent...

I can't debug for the moment, but I think first return receipt is sent by line 1029 (CreateMdnMsg), and second by line 1030 (UserAgreed wich also call CreateMdnMsg function).
That sounds right. UserAgreed should be called, to remember that the receipt was already send. Otherwise, it will be send again next time you re-open the message. But indeed, line 1029 should be removed.
Anyone up to make a patch and test it? I don't have a build environment.
(In reply to comment #28)
> That sounds right. UserAgreed should be called, to remember that the receipt
> was already send. Otherwise, it will be send again next time you re-open the
> message. But indeed, line 1029 should be removed.
> Anyone up to make a patch and test it? I don't have a build environment.

m_headers->ExtractHeader(HEADER_DISPOSITION_NOTIFICATION_TO, PR_FAL     SE,                         
1030                                  getter_Copies(m_dntRrt));

This line ?
No, the line that was line 1030 when the patch was made :)
Now it is:
http://mxr.mozilla.org/comm-central/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp#1044

1044                 rv = CreateMdnMsg();
Attached patch Patch (obsolete) — Splinter Review
This needs to be push to try and tested by people having the issue.
Attachment #519721 - Flags: review?(bugzilla)
Attachment #519721 - Attachment is patch: true
(In reply to comment #31)
> Created attachment 519721 [details] [diff] [review]
> Patch
> 
> This needs to be push to try and tested by people having the issue.

If you could get me a copy I'd be more than happy to test it on a machine here I have with the issue. It is a test setup anyway the I used to verify the problem.
Comment on attachment 519721 [details] [diff] [review]
Patch

So this won't really affect the try server test, but rv should now be assigned the result of the UserAgreed() call.
Attached patch Fix standard8's comment (obsolete) — Splinter Review
rv is now assigned.
Attachment #519721 - Attachment is obsolete: true
Attachment #519743 - Flags: review?(bugzilla)
Attachment #519721 - Flags: review?(bugzilla)
(In reply to comment #35)
> Created attachment 519743 [details] [diff] [review]
> Fix standard8's comment
> 
> rv is now assigned.

This patch solves the issue for my part.
(In reply to comment #32)

> If you could get me a copy I'd be more than happy to test it on a machine here
> I have with the issue. It is a test setup anyway the I used to verify the
> problem.

see the copies at https://ftp.mozilla.org/pub/mozilla.org/thunderbird/tryserver-builds/jonathan.protzenko@gmail.com-bf87b6027e00/
I would like to test it in Windows. Win32 build anyone?
(In reply to comment #38)
> I would like to test it in Windows. Win32 build anyone?

Yes, that is what I require as well
I think you guys need to wait a little.
This build sends one return receipt, but with garbled Polish national characters when used in Your Name field. Previously two were send: one correct and other one with garbled text.
TB 3.0.10 is encoding From: email header as UTF-8, TB 3.3a4pre is using ISO-8859-1.
(In reply to comment #42)
> TB 3.0.10 is encoding From: email header as UTF-8, TB 3.3a4pre is using
> ISO-8859-1.

What does 3.1.x do?
3.1.7 sends two: one with UTF-8 and other one without any codepage (garbled text in header). See comment 7.
Comment on attachment 519743 [details] [diff] [review]
Fix standard8's comment

>+                rv=UserAgreed();

nit: space either side of the equals please.

r=Standard8 with that fixed.
Attachment #519743 - Flags: review?(bugzilla) → review+
Assignee: nobody → ludovic
Component: General → Backend
Product: Thunderbird → MailNews Core
QA Contact: general → backend
(In reply to comment #41)
> This build sends one return receipt, but with garbled Polish national
> characters when used in Your Name field. Previously two were send: one correct
> and other one with garbled text.

I've filed bug 645056 on this issue. In short your default charset or the charset of your folder is set to something that doesn't support Polish characters. If you change the charset to something that does support Polish characters, then it will work correctly.
I do not understand it, really. Bugged Tb can send correctly encoded return receipt along with the garbled one. "Fixed" Tb is sending only garbled one. 
This bug is getting insane. It forces me to stick with unsupported 3.0.10, where this problem don't exist. This version simply works without any charset or charset of inbox folder manipulations. You have pretty nasty bit rot here...
Updated patch
Attachment #519743 - Attachment is obsolete: true
Attachment #521981 - Flags: review+
Keywords: checkin-needed
Checked in: http://hg.mozilla.org/comm-central/rev/c0bb2d32c193
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a4
Comment on attachment 521981 [details] [diff] [review]
Patch with review comment addressed

I think we should be able to take this in the next security & stability release of 3.1.x.
Attachment #521981 - Flags: approval-thunderbird3.1.10?
(In reply to comment #50)
> Comment on attachment 521981 [details] [diff] [review]
> Patch with review comment addressed
> 
> I think we should be able to take this in the next security & stability release
> of 3.1.x.

Shall I prepare a patch against that branch ?
(In reply to comment #51)
> Shall I prepare a patch against that branch ?

I suspect it will apply to branch without issue - we haven't changed much there.
(In reply to comment #46)
> I've filed bug 645056 on this issue. In short your default charset or the
> charset of your folder is set to something that doesn't support Polish
> characters. If you change the charset to something that does support Polish
> characters, then it will work correctly.

Just wanted to let you know that after changing the default charset to UTF-8 all is right in this build.
Attachment #521981 - Flags: approval-thunderbird3.1.10? → approval-thunderbird3.1.10+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: