ietf-smtp
[Top] [All Lists]

Re: "proper" handling of BCC

2012-04-16 02:20:19

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 loop" note.

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.

--
Sincerely

Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net

<Prev in Thread] Current Thread [Next in Thread>