If sending a receipt failed, how can I retry sending it?
When I read a message that requested a receipt and click on "send receipt" but I get the error "send failed, cannot contact SMTP server" (this can sometimes happen in my setup, since I use a tunnel to reach the smtp server to avoid smtp port blocking in some networks - but in principle it can happen to everyone occasionally) the "send receipt" button disappears even though no receipt was sent. I think this is a bug, as it should only disappear if the sending was successful. Is there any way for me to recall the "send receipt" button and retry sending it?
I would also find it good if there was a display "you have sent a read receipt for this message at <timestamp>" (replacing the message "<sender> has asked to be notified when you read this message" and button choice, instead of it just disappearing) - is this information stored internally and just not displayed? Somehow Thunderbird must know which mails have already nbeen receipted? If so, how can I access it? And/or can I configure to have receipts copied to Sent like other outbound mail?
Izabrano rješenje
kede81 said
The correct behaviour in my opinion would be that if sending the receipt failed, i.e. nothing happened, the received message must retain the choice of "Send Receipt" just as the composed message remains open for sending again.
You are probably correct there. Have you tried filing a bug report? https://bugzilla.mozilla.org/
Pročitajte ovaj odgovor sa objašnjenjem 👍 0All Replies (7)
This link does not relate to any of my questions at all. It primarily describes the view of the sender requesting a receipt, and what it says about "Thunderbird 3.*" requiring add-ons for what is part of the client today, it appears to be wildly out of date.
Izmjenjeno od strane kede81
the receipt is an email, so it should be in your outbox.
I reproduced the scenario. Outbox is only filled while Thunderbird is in offline mode. In that case, when writing mail, instead of "Send" it says "Send Later" and no connection to the SMTP server is attempted. My scenario is that Thunderbird is online, i.e. the IMAP connection is established. A SMTP connection is only established when a mail is actually being sent. If I try to send a regular mail, the popup error message in attached picture appears, and the mail I am trying to send remains an open compose window, i.e. as if I had not pressed Send at all, and I can re-do that after ensuring that the SMTP server is reachable. But if I click on the "Send Receipt" button in a received mail, after the same popup appears, the "Send Receipt" button is gone, nothing is in Outbox (or anywhere else I am aweare of) so I do not see any possibility to resend. The correct behaviour in my opinion would be that if sending the receipt failed, i.e. nothing happened, the received message must retain the choice of "Send Receipt" just as the composed message remains open for sending again.
Izmjenjeno od strane kede81
Odabrano rješenje
kede81 said
The correct behaviour in my opinion would be that if sending the receipt failed, i.e. nothing happened, the received message must retain the choice of "Send Receipt" just as the composed message remains open for sending again.
You are probably correct there. Have you tried filing a bug report? https://bugzilla.mozilla.org/
I checked bugzilla and there is already a bug filed, https://bugzilla.mozilla.org/show_bug.cgi?id=640644 updated two years ago with the exact same scenario I described (before, it was not very specific). December 2017, a duplicate was merged into it. Status new, unassigned. Is there any method to confirm/endorse a bug or otherwise raise awareness? Does it help to submit a duplicate? I see there is a vote count, but the wiki (https://wiki.mozilla.org/BMO/UserGuide/BugFields#votes) says developers don't care about that.
Izmjenjeno od strane kede81
I am marking this as solved. Of course the problem persists, but the scope of "Community Support" ends when a product bug is confirmed, the rest is a development issue and tracked in bugzilla. Let's hope that the bug will not just be kept on record for another couple of years but fixed soon.