--On Sunday, April 15, 2012 16:05 -0700 Steve Atkins
<steve(_at_)blighty(_dot_)com> wrote:
If I correctly understand the question, I simply put a "bcc"
field in the message as I submit it to the MUA. It removes
that field. constructs the "blind copy" warning text, and
constructs the envelope(s) appropriately (typically one
envelope for the set of To and Cc recipients and one for each
Bcc one) for handoff to the Submission server. Of course,
if one had a submission server that was smart about these
things, the MUA could hand the message, including the Bcc
field, to it and let it sort out envelopes (which it needs to
do anyway) and the warning message.
A submission server will have some difficulty adding a
warning message that'll be visible to a typical recipient
(multipart/mime, non plain-text, DKIM, PGP, S/MIME…).
Having the MUA add such comments assumes that there is a
convenient body part (probably the first one) that is text/plain
or, worst case, that it has to add the text to both/all pieces
of a multipart/alternative. Such plain-text or nearly
plain-text messages remain the typical case today. In the
absence of signatures or other integrity checks added by the MUA
or earlier, a submission server should have no more trouble
doing that than the MUA itself (although I confess to not having
a submission server do that for years). DKIM is even easier
since, at least in the cases I've seen the typical behavior is
for that signature to be added by the Submission server.
Now, clearly, if one had any of a large family of less-typical
messages (complex multipart structures; first (or maybe only)
body part not text/plain, text/html, or
text/something-else-fairly-simple-and-well-known, signatures
applied to the body part before the message can be added, etc.,
then the trick of adding a warning doesn't work. MUAs and
submission servers typically cope with those situations the way
alert MUAs that don't try to add a warning do, which is, as you
suggest below, to delete the Bcc header field (or its contents
-- that used to be extensively debated) and then construct and
appropriate envelope.
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.
john