At 15:11 -0800 on 02/28/2012, Ned Freed wrote about Re: "proper"
handling of BCC:
> > Ways it can be handled is for the MUA to submit the BCC header to the
>> MSA and have it remove the header while cloning the message to create
>> one master and one copy for each BCC listing only the Address, have
>> the MSA scan the To and CC assuming that any RCPT-TOs not there are
>> BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do
>> the cloning. Not that the first 2 alter the MSA while the last alters
>> both the MSA and MUA.
>It's certainly possible to have the MSA make the message copy, but we'd
>need to define an extension for that. No such extension exists AFAIK.
No extension needed.
Sorry, that incorrect. Without an extension how is an MUA supposed to know that
the MSA supports the extension? If an MUA assumes such an extension is present,
it actually isn't, and sends a message expecting the MSA to perform some sort
of Bcc: processing and selectively remove any Bcc: field(s) that are present,
you have just exposed the Bcc: recipient(s) to everyone.
And since no MSA out there currently does any of this stuff, this behavior will
be the rule, not the exception, until the extension actually deploys, assuming
it ever does. No MUA implementor in their right mind would implement this
So long as the MSA has the code to clone (and
inject the BCC into) a submitted message that has more RECPT-TOs than
the sum of the addresses in TO and CC (ie: So long as it is not being
submitted by a Mailing List and thus had one or more BCC'ed addresses
that only the MUA knew of) you just need to make this the default via
a parm setting (This functioning is method 2 of 3 above).
Absent an extension, the MUA has no way of knowing if this parameter even
exists in the MSA, let alone how it is set.
similar to having a MSA or MTA clone multi-addressed messages that
would normally be sent a one message with multiple RECPT-TOs going to
the same MTA by having a "DO NOT BATCH" parm. Since this is a setting
in the MSA/MTA code it just defines a default action not one that
only occurs when requested by the submitter. I acknowledge that an
extension would be better so it only occurs when the users asks.
That's another reason why you need an extension - you absolutely do need a
parameter so that the MSA only does this stuff if the MSA requests it.
I also think this is the wrong way for it to work. The problem with
this approach is that it forces the MSA to parse and modify headers,
and compare the addresses extract from those headers with the
various envelope addresses. That's inherently risky.
It's much safer to have the MUA send a message without any of these headers in
it and to have the MSA simply add the Bcc: field to message copies as needed.
This can be done with a BCC parameter on the RCPT TO:. The value of that
parameter can be the personal name phase to add to the address. This
way the only thing the MSA has to do is decode the parameter value,
concatentate some strings and add a header field containing the result.
Alternately, the value of the BCC parameter could be the entire Bcc: field
value. This would provide support for stuff like group constructs, assuming we
want to allow that. (I can argue it either way.) This is even simpler because
now all the MSA has to do is decode the parameter and stuff it into a new
Of course the bigger part of all this from the MSA's perspective is the
messge splitting. But most MSA's always have code for that to handle other
cases; this extension can simply leverage that support.
OTOH: One way to handle this is to define two MSA addresses - One
that works as now and one with this default action code. If you want
this to occur then just use a sending persona that points at the 2nd
That's far too complex for users to deal with - even now service providers
spend far too much time dealing with support calls from users who cannot
set up even one persona in their client properly.
And besides, no service provider is ever going to deploy multiple MSA just to
support such functionality. The benefits don't come even close to outweighing
Remember, the target audience here has to be more than just a bunch of
geeks or this doesn't stand a chance of deploying.