Re: "proper" handling of BCC

There are many angles to all this, including one that there is a major 
difference in the types of MUAs, including in how it relates to the 
headers, the managed "privacy" control required for blind copies, etc, 
and in regards to the "Inventor" of email, in that era he was using a 
ONLINE MUA, not an store and forward, offline based MUA.
That is a major distinction in all this.  In fact, if you go the 
fellows web site, there is sad and hilarious picture showing him in 
front of what appears to be a DEC VT100/102 terminal and the caption 
says something to the effect
     if you look carefully, you can see the clear From/To/BCC UI 
evidence of the
     new EMAIL system.

It was saying "huh?"  I could even come close to seeing any readable 
characters or any fuzzy screen resolution whatsoever - but then again 
it could be my failing eyes.
Any hoo, for MUAs regardless of the network, gateway, etc:

o Online

The backend handles the separation when the frontend/GUI offers fields 
for this. When the post (clicks the Post/Send button) is made, the 
backend needs to handle the distribution for privacy requirements 
before putting/moving them into system's mail transport outbound 
queues and/or local storage user bins.
o Offline

The RFC-based offline MUA is responsible for separating the targets 
before SMTP sending for the following reasons:
First, there is no current SMTP solution, such as  "BCPT TO" state 
machine command option, and second, there is no expectation for SMTP 
receivers to parse for 822/2822/5322 headers to extract distribution 
targets.
In all case, backend or offline MUA needs to  make sure the separation 
for the privacy requirements are met.
There is nothing more embarrassing, including legal, to have mistakes 
of exposing blind copies to the other non-blind recipients.

Robert A. Rosenberg wrote:
> At 13:17 -0500 on 02/28/2012, Tony Hansen wrote about Re: "proper" 
> handling of BCC:
> > I actually started writing such a doc about a year ago, but never 
> > finished it.
> > Is it worth dusting off?
> >
> >     Tony Hansen
> >
> > On 2/28/2012 12:24 PM, Dave Crocker wrote:
> > > On 2/28/2012 9:11 AM, Paul Smith wrote:
> > > > >
> > > > OK, I was wrong - but I've never seen a BCC handled in that way 
> > > > before... I've sometimes received messages with a 'BCC' field 
> > > > containing addresses who were NOT me (ie I shouldn't have known they 
> > > > existed), and most MUAs I've seen (in fact, all those I've 
> > > > investigated fully) just list those recipients in the envelope for a 
> > > > single copy of the message. So, I've never seen a BCC field in a 
> > > > message header, used 'correctly'.
> > > We have never really standardized BCC as an end-to-end construct, at 
> > > the MUA-MUA level.
> > > d/
> 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.
> In any case there needs to be some way of indicating the BCC contents. 
> Note that  there needs to be a way of triggering the insertion/display 
> of the BCC listing only the recipient in the recipient's copy of the 
> message that WILL NOT get triggered by a normal Mailing List message. 
> Options 1 and 3 above qualify since there is a indication to the MSA to 
> clone the message with a BCC. Option 2 since it triggers via a mismatch 
> between the To/CC contents and that of the RECPT-TO will be the problem 
> since there would be no difference to the MSA between a BCC and a 
> Mailing List generated message.
> Note that I am just winging it and may be missing something and I am 
> just doing some design spec thoughts above.
--
Sincerely

Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net