295503 - RFE: Ask for confirmation before allowing reply-all to a message I was bcc'ed on

Status: RESOLVED DUPLICATE of bug 642530

(Thunderbird :: Message Compose Window, enhancement)

Description

[Joe Gugliemino]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

If you were a bcc recipient of a message, Thunderbird does not show that fact in
either the main mail window or the individual message window.  I had an
embarrassing situation where I reply-all'ed to a list, thinking I was included
in the general discussion rather than being informed as a courtesy.

I think it would be effective to have Thunderbird pop up a confirmation with
wording along the lines of "You are doing a 'reply-all' to a message on which
you were a bcc recipient.  Are you sure?"

Reproducible: Always

Steps to Reproduce:
1.  Compose a message to somebody, with your address as a BCC
2.  Send the mail
3.  Read the mail.  There's no BCC in the header band to indicate that you
received this mail as a BCC recipient (I already entered a bug on that).
4.  Hit reply-all.  The composition window opens up with no warning that you're
about to reveal that you were a BCC recipient

Actual Results:  
Mail was sent to everybody on the TO list, causing a faux paux on my part.

Expected Results:  
I think it would be effective to have Thunderbird pop up a confirmation with
wording along the lines of "You are doing a 'reply-all' to a message on which
you were a bcc recipient.  Are you sure?"

Comment 1

[zug_treno]

Duplicate of/related to Core bug 209337 comment 1?

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to comment #1)
> Duplicate of/related to Core bug 209337 comment 1?

no - bug 209337 is about another person's mail software adding a line at the top
of the e-mail being sent to you. This bug is about (the receiver) "confirming" a
repy-all for a message already received - so it's isn't accidentally revealed
that s/he was BCCed.

confirming 

Comment 3

[Alan Dobkin]

Agreed.  As I just commented in bug #209337, I believe that RFE should be closed
with WONTFIX and this RFE should be implemented instead.

Comment 4

[Andrés G. Aragoneses]

Another interesting side-RFE mentioned here[1]:

> Maybe a complementary feature that when you ask it to “BCC” it instead
> automatically sends a separate email with the original recipient info appended
> as text. Because the person who sent the BCC would have looked just as foolish
> as you in this situation.

[1] http://tieguy.org/blog/2010/03/24/thunderbird-plugin-i-suddenly-want/

Comment 5

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

This makes me wonder if we should actually be defaulting to reply only to sender and offering to upgrade to "full disclosure" instead of warning people the other way around.

Comment 6

[Alessandro Vesely]

(In reply to comment #4)
> Another interesting side-RFE mentioned here[1]:
> 
>> Maybe a complementary feature that when you ask it to “BCC” it instead
>> automatically sends a separate email with the original recipient info
>> appended as text.

Let's not forget that BCC is useful the way it is.  For example, one can file a message to the Sent folder without doubling the transmission time (which is not negligible in case of large attachments and slow links.)  I guess this feature is not much used --see subscriptions to bug #569921

IMHO, the suddenly-wanted attachment should use a different keyword than the BCC header field name.

BTW, it would rather be convenient to have a warning when _all_ the recipients are CC or BCC, i.e. no TO is set. By setting the TO field, message authors can override the default "undisclosed recipients".  Didn't that exist in TB2?

Comment 7

[Jerry Baker]

Supposing I wanted to jump into mailWindowOverlay.js and patch the IsReplyAllEnabled() function so that when getIdentityForHeader(msgHdr).email is empty or null, IsReplyAllEnabled() returns false, would Mozilla accept such a patch? If not, how about with a pref to toggle the behavior?

Comment 8

[Jerry Baker]

If the patch to Bug 642530 is accepted, it will fix this bug.