Re: "proper" handling of BCC
John C Klensin wrote:
Handling Bcc by copying the Bcc header to the envelope,
then deleting the header is fine, though I wouldn't trust any
MUA that relied on that functionality.
Yes. The difficulty with this --and what caused the "add the
comment/warning" behavior-- is that the recipients cannot easily
tell "received a blind copy" from "received from a mailing
list". If they then reply, copying the explicit distribution,
the result is a privacy compromise relative to the intentions of
the original sender. If the original sender were really worried
about that, the only safe action I know of is to avoid use of
bcc entirely, instead, for example, forwarding a copy of the
message with the explicit recipient listed to the bcc recipient
only. That message could well be structured with the warning as
a first body part followed by the original as message/rfc822 or
message/global. But it is a little hard to automate.
When I don't use our MUA which have the special BCC feature to split
the streams and add the special top posted notification, and instead
I'm using an MUA like Thunderbird, whenever I need to do this, I will
either CC or BCC myself, and with my copy, just forward it the the
special private address with a top posted FYI "Keeping you in the
I am also very careful of not BCCing someone that is know to
reply/response and will just BCC a person will never get involve -
they just wants to be keep in the loop. I do this almost daily with
technical support communications to keep the sales team in the loop of
whats going on.
So IMV, we should also take into the account that people who generally
need to use a BCC, most likely don't do so blindly themselves.
The way I look at it, due to what is today, the MUA is responsible and
if the MUA author is going to offer a BCC feature, it needs to do so
responsibly knowing full well how the backend works which never came
with an backend expectation to do BCC processing, stream splitting,
privacy cleanup. If it exist, its a proprietary MUA/MSA concept.
IMV, if we are looking to move this MUA duty to the backend with a
standard methodology, then we need a IETF I-D/RFC proposal and SMTP
extension that defines rules for the router to do this BCC splitting.
But I wonder if its worth it because on the original mail creation
side with the OFFLINE MUA, they are all already doing it. The MSA
router does not need to currently worry about it. So it seems the
issue is only for the receiver MUA to consider and off hand only
because of the modern expectation of MIME based mail. If the BCC is
passthru, then it should be more aware from the display rendering
standpoint the special meaning it has to convey to the blind recipient.