BCC handling

[gareth]

Has Fastmail changed the way it handles display of other recipients in incoming messages where the recipient is in BCC?

I think I remember a time when To and CC recipients would be invisible to a BCC addressee (although I may be confusing this with a previous provider.)

I remember a conversation years ago about how the email specifications are silent on what BCC should do in this respect so there was, I seem to recall, variation between providers.

Can anyone confirm or deny any of the above or have I imagined it?

Thanks
Gareth

[gareth]

I googled a little more and answered my own question (except as to whether Fastmail has changed incoming BCC behaviour) - so, for info:

There seems to be widespread confusion, which apparently has spread to seemingly contradictory EMAIL standards http://tools.ietf.org/html/RFC2821 & RFC2822, on top of which they warn that various email providers elect to interpret the meaning differently.

-- https://productforums.google.com/for...E/TUtA2yik3wMJ

[gardenweed]

Originally Posted by gareth

I googled a little more and answered my own question (except as to whether Fastmail has changed incoming BCC behaviour) - so, for info:

The Bcc recipient sees To and Cc.
I have been using this for many years to send a backup of every sent email - can't recall how many, but maybe 8-10 years.
So no recent change.

[gareth]

It seems to me that the current way of doing things (which seems to be common, ie showing To and CC to BCC recipients) is a "reply to all" accident waiting to happen.

Really think BCC should follow RFC2821's suggestion:

...sending SMTP systems that are aware of "bcc" use MAY
find it helpful to send each blind copy as a separate message
transaction containing only a single RCPT command.

https://tools.ietf.org/html/rfc2821 [7.2 Blind Copies]

rather than RFC2822:

The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
addresses of recipients of the message whose addresses are not to be
revealed to other recipients of the message.

...

In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, but the
recipients on the "Bcc:" line get a separate copy of the message
containing a "Bcc:" line. (When there are multiple recipient
addresses in the "Bcc:" field, some implementations actually send a
separate copy of the message to each recipient with a "Bcc:"
containing only the address of that particular recipient.)

-- https://tools.ietf.org/html/rfc2822 [3.6.3. Destination address fields]

[gareth]

Thanks gardenweed, I was writing my last post as you were replying - I suppose a strict BCC implementation would do away with some of its usefulness as a backup tool.

As for whatever variation there might be, it seems to be in sending rather than receiving.

[BritTim]

Apart from making bcc unsuitable for backup purposes, what you suggest would also eliminate the original use of bcc, which was to mimic its traditional use in business correspondence (that is, to keep certain people informed without making them a formal part of the conversation). The "reply all" issue should never apply as bcc recipients should not reply to messages. (Now, an email system that prevented replies by bcc recipients could be very useful.)

[n5bb]

I see two completely different issues being discussed in this thread:

• The sending MTA behavior. The quoted section of RFC2821 describes use of the SMTP (envelope) RCPT TO command, and suggests that BCC receipient messages get separate SMTP transactions. The quoted section of RFC2822 discusses headers, which are different from the RCPT TO SMTP commands. I suggest reading RFC2822 section 5 (Security Considerations).
• The receiving MTA, display of message headers to the recipient, and behavior of Reply-To-All in web mail or an email client.

The original question in this thread was display of headers when reading a message. FastMail (and all other email clients and web mail systems I have used) shows the contents of the To and Cc headers. Since messages can be pushed to IMAP servers by clients, there is no way to guarantee that a message was sent via BCC just by looking at the received headers.

If a sender wants to insure that a BCC recipient doesn't reply-to-all, the sender should send a separate message to that recipient rather than using BCC. The email system can't fix each case of human error.

Bill