ietf-822
[Top] [All Lists]

Re: The Bcc Issue

2004-08-13 15:28:56

It sure would have been good if we had defined this about 20 years ago.

It was not my intention to imply that you shouldn't leave the bcc header in for the viewing of the person named in it, merely that it be removed from the view of anyone *else* as early in the process as possible. I don't much mind leaving in the bcc that explains why you received it, although I tend to prefer "Apparently-to" for that purpose (yes, I know, totally non standard). But the bottom line is that software uses bcc for two very different functions: to tell another email transport-related entity to send a bcc, or to tell the user that he has received a bcc. I don't see how this dual use can possibly be a good state of affairs.

For me, though, the most important issue is not violating user-level expectations, particularly when they are privacy-sensitive. Maintaining the alleged purity of the email architecture is not a winning argument by comparison. -- Nathaniel



On Aug 13, 2004, at 5:52 PM, Dave Crocker wrote:


Folks,

I think Nathaniel's note does an excellent job of representing a popular
line of thinking about these issues. It's critical of that line of
thinking, rather than of Nathaniel...

We need to make sure that our assertions about human communications
issues have some relationship to the normal, non-computer range of human behaviors. Unfortunately in the world of email standards,tend to be both
arbitrary and restrictive in those assertions.


NB> The essence of a "bcc" is "I want a copy to go to this person, but I
NB> don't want the 'real' recipient to know it."  Given that

Nit pick:  The usual term is 'primary', rather than 'real'.


NB> motivation/intent, writing it down in a header field is a somewhat
NB> dubious concept to begin with.

The concept of making such a note for the author's agent, such as a
secretary, is not dubious at all.  It is the only way the author can
tell the agent how to handle the message.


NB> Anyone who puts in a "bcc" field
NB> pretty obviously intends for it to be taken out before it reaches the
NB> ultimate recipient.

In fact that did not used to be standard practise.

The benefit of having a BCC field in a message is that the recipient
does not need to guess why they got the message. (Lest anyone says 'if i
got the message but am not listed in it then i am obviously a bcc
recipient' we need to observe both the baroqueness (baroquity?) of such
a (non-)labeling technique and its potential to misbehave.)

In fact it is not unreasonable to have each bcc recipient get a copy of
the message with a bcc header that contains (only) their name in it.

In some scenarios, it would even be reasonable to have all the bcc
recipients get the same copy and have it list all of them.  This is a
way to keep a special (closed) group informed about some public
activity, and permit them to continue private discussions about it.


NB>   This suggests, however, an obvious way to handle
NB> such headers: Take them out of the headers and (probably) inject them
NB> into the SMTP recipient stream as soon as you possibly can!

NB> In other words, a conservative default would be that *any* software
NB> that received a message with such a field should feel very free to take
NB> out the field, and should probably send the bcc as well.

I am trying to imagine the meta-policy that is behind this being
generally acceptable: any software that receives a message with some
objectionable headers should feel free to take out the field?


NB>  The nastiest
NB> failure case is when the message is delivered with the bcc field
NB> intact, so it seems to me we should try to err in the other direction
NB> and pre-empt a faux pas if we can.

First of all, we are talking about the MSA or MUA.  Not 'any software'.

Second of all, Internet standards like this would do better to have no
'default' for such situations. Defaults invite problems with the
expectation differing between the creator and the consumer of the
defaulted material.


NB> The Puritan in me thinks you should have to type "~b" at an absolute
NB> minimum in order to send a bcc, and probably something even more
NB> obscure. :-) But it's still the software's job to try to minimize the
NB> harm that  happens to you once you use the feature, which is why I
NB> argue for implementing this at more or less *every* protocol hop. --

but, then, we don't do user interface standardization here.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>





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