Dave Crocker wrote:
JJP> Bcc actually has two functions:
...
JP> (2) To stop replies, i.e. working as a kind of "Non-Reply-To".
While I think it would be entirely reasonable for an rMUA to take the
presence of BCC as meaning that the rMUA should not allow a reply
command to automatically include TO or CC, I do not believe that it a
common rMUA behavior. In fact, I've never heard of it.
In the earliest version of MH (pre-Rose), the posting command sent the
BCC copy separately from the To/CC copy. One of the things is did was
to make To and CC be [To] and [CC]. So they looked like normall to and
cc fields, but the reply commands did not see them present.
This got removed from later versions of MH and I haven't see anything
similar since then.
Accidentally copying to the to and cc folks is certainly an important
issue.
Dave, I think the behaviour in early-MH that you describe is different
from Jacob's suggested use of Bcc.
He's suggesting a form of To/Cc that other people cannot accidentally
reply to. These people will receive a copy of your message, but will not
see replies. He doesn't mind that the To/Cc people know that these other
people have received a copy, so Bcc isn't really quite what he wants.
Right now, the only way to achieve this type of behaviour is to use Bcc
and then put some text in the message saying "I've also bcc'd this
message to x, y and z".
If I understand correctly, your description of early-MH's behaviour is
that the copy of the message that the BCC recipients receive would have
their To/Cc headers zapped such that the BCC recipient will see who got
the message, but cannot do a reply.
Tony Hansen
tony(_at_)att(_dot_)com