As one who has always despised the whole concept of bcc's, everything I
say should be taken with a large grain of salt. However...
The essence of a "bcc" is "I want a copy to go to this person, but I
don't want the 'real' recipient to know it." Given that
motivation/intent, writing it down in a header field is a somewhat
dubious concept to begin with. Anyone who puts in a "bcc" field
pretty obviously intends for it to be taken out before it reaches the
ultimate recipient. This suggests, however, an obvious way to handle
such headers: Take them out of the headers and (probably) inject them
into the SMTP recipient stream as soon as you possibly can!
This IMO completely misses the point of the bcc field. The reason the
field is there is not to notify all the recipients that a blind copy
was made. That would be silly. Rather, the point is to notify the
bcc recipient that his or her copy is a bcc and should be handled
accordingly.
In other words, a conservative default would be that *any* software
that received a message with such a field should feel very free to take
out the field, and should probably send the bcc as well.
This approach actually presents something of a security exposure, as it results
in someone getting a copy of message without any indication it was done as a
bcc. This is the reason that some UAs have started stuffing "This is a bcc"
text into the message body (often without regard to things like MIME,
unfortunately).
The nastiest
failure case is when the message is delivered with the bcc field
intact, so it seems to me we should try to err in the other direction
and pre-empt a faux pas if we can.
The nastiest case is when a MUA incorrectly assumes that bcc will
be deleted somewhere down the line and it isn't. But the case where
the MUA assumes that bcc will be carried through and it isn't also
can lead to exposures, albeit less directly.
Ned