4 ms·
I generally avoid bcc, since it's too easy for the blind recipient to hit "respond" and cause havoc. I wish that email clients instead had a "blind forward" fe
by pcl 5y ago
I generally avoid bcc, since it's too easy for the blind recipient to hit "respond" and cause havoc.
I wish that email clients instead had a "blind forward" feature, which would simply send a second email after sending the first, to the blind recipients.
Such a scheme would presumably not suffer this leak, either.
- macintux 5y agoI agree that using Bcc in combination with public recipients is perilous. Using it for all recipients is, however, quite desirable and I wish more organizers used it.
- raverbashing 5y agoEdit: ah yes I see what's the idea now. > I generally avoid bcc, since it's too easy for the blind recipient to hit "respond" and cause havoc So what's your proposed alternative?
- Cthulhu_ 5y ago> I wish that email clients instead had a "blind forward" feature, which would simply send a second email after sending the first, to the blind recipients.
- dogma1138 5y agoI only use BCC when I need to remove a distribution list or people from the main thread and I mention that in the email response. Basically I only use it when someone sends out an email with too many recipients and I want to reduce the audience because I know it will get out of hand.
- bombcar 5y agoExactly - I use it for “these two people and I are sending this group an email” where the other two are cc: and the group is bcc so replies are routed to me or to my team and not the entire group.
- dvfjsdhgfv 5y agoIn the past I loved Mutt's bounce feature (bound to the 'b' key by default) which basically allowed me to Bcc anyone for any email I already received. I don't believe it works anymore today because of common anti-spam measures but it was a great way to deal with misdirected mail (by accident or on purpose).
- inopinatus 5y agoIt’s often important that the BCC’d folk can see who the overt recipients were, though. I think the proper solution to this is using the Reply-To header.
- t0mas88 5y agoThat works fine with the solution proposed above: Forward the message after sending, it will include all details on date/subject/recipients just not cause a reply-to-all to actually go to all.
- inopinatus 5y agoWe already have that, it is the existing commonplace forward; not the blind forward suggested above, which by definition would strip the original To and Cc fields.
- addicted 5y agoThere's no reason the blind forward cannot include the original email's recipient list as well. The OP's point is that it should be a simple 1 step process instead of a multi step process. I suspect they are further suggesting that email clients should modify their behavior so that when someone enters recipients in the BCC list, instead of BCC'ing the recipients, it auto forwards the mail to them (if they do that it would also make sense to pick a different title than BCC to avoid further confusion).
- inopinatus 5y agoThere is a reason why not, and it’s that mail clients reply based on the header fields, not the envelope recipients. A separate “blind forward” field in a mail client could be a nice addition, but it too falls apart because drafts might be started in one client and completed in another. In practice, deviating from existing MTA and MUA behaviour as specified in RFCs - included the handling of the Bcc header - produces innumerable edge cases and interoperability gotchas, which is why we try not to fuck with them much. The worst case scenario being, all too commonly, some well-intended script installed by a frustrated sysadmin that tries to fix an impedance mismatch and ends up inadvertently creating either a software laser or an open relay.
- addicted 5y agoThat's a really good idea. It's what I do manually in practice whenever I want to "BCC" someone.