In <1455634002(_dot_)20040813145245(_at_)brandenburg(_dot_)com> Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> writes:
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 that case, it would be reasonable for an MTA to remove a Bcc header
that did not agree with the envelope address. Whether that would be
expressed as a MAY, SHOULD or MUST is another matter of course :-( .
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.
Nice, but not so easy to implement.
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!
Indeed so. With the understanding that any MUA which uses the '-t' option
of its MTA is simply subcontracting part of its MUA activity, and it had
better be aware of exactly what the MTA has been subcontracted to do
(actually, use of the '-t' option of an MTA is more likely to occur in
special-purpose mailing scripts than in regular general-purpose MUAs).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5