221615 - View Before Return Receipt (Reciept)

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, enhancement, P2)

Description

[Robert Accettura [:raccettura]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925

Spamers quite often use return reciepts to confirm email addresses on their
lists.  Mozilla asks you to confirm sending a return reciept *before* you see
the email.

A good way to keep Mozilla on the "Spam Fighting" fronteer is to allow users to
see the mail, *THEN* send the reciept.  That way, if it's spam, they don't send it.

Mockups to be attached.  Based on Junkmail.

I don't think it would be very hard to do, but would be a giant enhancement on
fighting spam.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Robert Accettura [:raccettura]]

Attachment: New Confirm Dialog (mockup)

The new Confirm dialog, should default to view before sending reciept.

Comment 2

[Robert Accettura [:raccettura]]

Attachment: Mail Window (mockup)

Mail window should display that the user requested a return reciept.  Pressing
"Yes" should send the reciept.	"No", should remove the prompt.


An alternative would be if the user presses "No", to minimize it, so that it
just displays "The User requested a Return Reciept that hasn't been sent". 
This could be done to all mail viewed.	IIRC return reciept is noted by a
"Disposition-notification-to:" header.	

Would be good for historical reference, to be able to go back and quickly say
"Yes I recieved that email, and sent a return reciept on 10/2/03 @ 12:02 PM
EST"

Comment 3

[Andreas Krüger]

I would like to be able to read the message today, and send the reciept tomorrow.

And I agree with Robert, that I want Thunderbird to be able to tell me if, and
when, I did send a reciept for that one particular message.

Preferably, I'd also like to be able to get some information for many messages.
I'd like it if it were possible to sort messages in my inbox by reciept status:
  "wanted a reciept, but didn't get one",
  "wanted a reciept and got it",
  "didn't want a reciept".

For additional benefit, an additional status would be useful:
   "wanted a reciept, but I have positively decided to NOT send one for this
particular message."

Comment 4

[dolphinling]

I would prefer to cut out the dialog entirely and just use a bar like the one
for junk mail (like the mockup in comment #2)

Comment 5

[Magnus Melin [:mkmelin]]

*** Bug 332313 has been marked as a duplicate of this bug. ***

Comment 6

[Rick Yorgason]

Hell, I don't mind the dialogue pop-up, or the fact that it's modal; I just think that Thunderbird should update the message pane before asking me!

Comment 7

[Isriya Paireepairit]

#6

This can cause UI flaw, dialog popup steals focus from mail window and users can't scroll donw if message is longer than pane.

Comment 8

[Rick Yorgason]

#7

Yeah, that occurred to me, but truthfully I've never had to scroll to determine if a message is spam.

Perhaps it's only a band-aid fix (a band-aid fix that fixes 99% of the problems), but it's the easiest, and avoids the problem of people forgetting to send receipts.

But, if you insist, here's the most flexible solution:

* Update the message pane before showing the dialogue.
* Add a "Not right now" button to the dialogue.
* If the user chooses "Not right now", then we add a bar like #2 suggested.
* A "never ask me again" checkbox would also be useful.

Comment 9

[Martin Cleaver]

When using the arrow (or "N" to run through new messages, the popup window appears BEFORE you see the message - so unless you can recognise the sender from subject and name, you have no idea what it is. TB should display the message and THEN ask the question.
Rgds
Martin

Comment 10

[Tuukka Tolvanen (sp3000)]

*** Bug 361035 has been marked as a duplicate of this bug. ***

Comment 11

[Mike Cowperthwaite]

"Seamonkey" bug 151244.  (I think that bug is "Seamonkey" only because the "Receipts" component is listed under the suite, rather than under Core.)  That bug also describes a bar across the top of the message.

It also mentions the rather irritating drawback that the message pane continues to display the previously-loaded message while the Send Receipt? prompt is displayed.

Comment 13

[Fernando Fernandez]

This bug has been around for some years: https://bugzilla.mozilla.org/show_bug.cgi?id=151244

I'd really like to see the band-aid solution implemented (#7). It's simple and it would work. 

This a goof example of "optimal is enemy of good".

Comment 14

[Nikolay Shopik]

TB should ask about sending Return Receipt after you mark message as read thats what is done for. Problem is in TB you can't mark messages read unread by yourself it done automatically after whatever seconds. I'll like to let some messages unread in outlook just because I have not read it property or don't want send read notification now.

Comment 15

[David Ascher (:davida)]

I don't think this blocks tb3, but in general I think I like this.  Sending to Bryan for his thoughts. 

Comment 16

[David :Bienvenu]

marking p2, leaving wanted, but someone will need to step up and take this

Comment 17

[David :Bienvenu]

putting in b2

Comment 18

[Bryan Clark (DevTools PM) [:clarkbw]]

I have a bunch of designs for return receipts previously which includes this kind of info bar.  The designs also go further if people are interested in more.

https://wiki.mozilla.org/User:Clarkbw/Return_Receipt

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

While this would certainly be nice, unless someone signs up to do the work, I don't see this making Thunderbird 3.  Removing wanted+ and target milestone.

Comment 22

[pavel.zahradnik]

Wouldn't it be possible to make use of existing extensions?

https://nic-nac-project.de/~kaosmos/index-en.html#nrrh
https://nic-nac-project.de/~kaosmos/index-en.html#rrbutton

Comment 23

[Dan Mosedale (:dmosedale, :dmose)]

Potentially, but someone still needs to sign up to do the work of evaluating whether they're suitable, talking to the extension authors, figuring out what sort of automated testing we should require, doing ui-review and code-review, and landing any patches.  That said, if we think the extensions are suitably well done, it would cost less effort to promote them as recommended extensions via the add-on manager.

Comment 26

[Mark Banner (:standard8)]

This has been fixed by bug 151244.