User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Build Identifier: Thunderbird 1.0.2 Affected: IMAP accounts Concerns: INCOMMING mails with receipt requests Item: Preference settings of how to handle incomming emails with receipt requests Since when: since upgrade of Thunderbird from version 1.0 to 1.0.2. This feature still works fine with my POP3 accounts. This feature used to work fine with my IMAP accounts before the upgrade. Whenever I received a message with receipt request in the inbox of the IMAP accounts, I was prompted whether I agreed to sending a receipt. Settings: Account Settings - Return Receipts --- Customize Return Receipts for this Account ----- When sending messages, always request a return receipt - CHECKED ----- When a receipt arrives ------- Leave it in my inbox - SELECTED ----- When I receive a request for a return receipt ------- Allow return receipt for some messages - SELECTED --------- all three options are set to "Ask me" Reproducible: Always I checked with my communication partners, whether they had changed their settings, but they had not. They still receive the delivery notification from the mail server, but no receipt requests anymore. Every mail must be confirmed manually now - very tedious considering the large number of mails I receive. I tried to change the settings in various ways, within the running application, shutting down the AP, changing after restart, changing before restart, delting IMAP account and recreating it, changing its preferences, but to no avail. This functionality is gone.
Same trouble here, with both imap and pop. Since 1.0.2, no more returns receipt...
I can also confirm this bug. I sent an email from Thunderbird version 1.0.2 (20050317) to an Outlook Express client with a return receipt request & everything worked fine. But when I sent a return receipt request from Thunderbird 1.0.2 to Thunderbird 1.0.2, the recipient never got the request on the email. Several other people in our company are starting to report this problem as well.
I have carried out some testing on this bug to see if it was server related (I run my own Linux server with Sendmail and Dovecot). Using one of my clients Windows 2003 systems, I have the following observations: Sending from Thunderbird with receipt selected prompts on Outlook 2003. Sending from Thunderbird with receipt selected does not prompt on another Thunderbird. Sending from Outlook 2003 with Delivery and Read set - Delivery sent from Sendmail; Thunderbird does not flag Read. Sending from IMP 4.02 with Read and Delivery set - Outlook 2003 prompts for read; Thunderbird does not.
Can confirm it for 1.1a and WinXP
*** Bug 297123 has been marked as a duplicate of this bug. ***
I think it's a stopper for 1.1. You can't use TB in a professional environment with such a bug. Please nominate it for the list.
I see this too
Created attachment 186275 [details] [diff] [review] the fix we introduced this regression in 1.01 when we fixed MDN for global inbox, we broke it for everything else. Oops! See Bug 273356 for details. We were only getting the identity if we had a global inbox. This fix makes it so we get the first identity for the account regardless of whether we have a global inbox or not.
What about test tools like the qa-team from OpenOffice has to avoid this? ;) http://qa.openoffice.org/qatesttool/index.html What about beta-testing for the release candidates?
Comment on attachment 186275 [details] [diff] [review] the fix a=sspitzer for this regression fix.
we really should take this patch for 1.0.5 since it's functionality that worked in 1.0 and we broke in 1.0.2.
I've just installed 1.0.5 and return receipts don't work for IMAP accounts, was this fixed in 1.0.5?
Installed 1.0.6 Return receipts don't work for IMAP. And My boss is not amused about this regression.
I have the same problem. In the header there is the line Disposition-notification-to: firstname.lastname@example.org but that's all. There's no popup window, nor an automatic response. It' doesn't work niether with POP, nor with IMAP. When i send a mail from Thunder to Outlook Express with "return receipt", there's no problem, the notification comes back perfectly.
I'm not quite sure why this was refused for 1.0.6. The flag may have accidentally been removed. adding to the 1.0.7 flag (if we ever have a 1.0.7) Otherwise folks may have to wait until Thunderbird 1.5 comes out.
Using 2005-09-23-15-aviary1.0.1/ on the Mac, this works as expected. I confirm that with the settings set in the initial STR, I receive the "return receipt" prompt, and when I sent it back to the account I sent it from I do receive the return receipt confirmation. Awaiting verification on Windows and Linux.
I've verified on the official windows candidate build (2005-09-23-16-aviary1.0.1) Changed my account setting to always request a return receipt. Sent an e-mail to one of my accounts. I confirmed that I was prompted to issue a return receipt when I read the e-mail. I then got the return receipt in my sending account.
(In reply to comment #17) > I've verified on the official windows candidate build (2005-09-23-16-aviary1.0.1) > > Changed my account setting to always request a return receipt. Sent an e-mail to > one of my accounts. I confirmed that I was prompted to issue a return receipt > when I read the e-mail. I then got the return receipt in my sending account. With Thunderbird version 1.0.7 (20050923) on Windows XP Pro, I don't have the return receipt popup dialog. For me, this bug isn't fixed...
But i don't see a final 1.0.7 release yet... am i wrong? let's wait for it.
same trouble with 1.0.7 on imap... This function doesn't work since 1.0 :-(((
*** Bug 323203 has been marked as a duplicate of this bug. ***
Reopening because it has been seen on 1.5 from report of Bug 323203
Return receipts are working well for received IMAP messages in TB 1.5 for me
My apologies - inadequate testing on my part. Return receipts are indeed working in TB 1.5, although not with messages sent to oneself (which is how I was testing them before). This bug can be closed.
reclosing as fixed.