[Top] [All Lists]

Re: "proper" handling of BCC

2012-02-28 17:59:25

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.


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.


Hector Santos
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net