Over on the Sypheed mailing list, we are having a discussin
about the interpretatio of RFC 5322 with regard to the Bcc:
field:

<https://www.sraoss.jp/pipermail/sylpheed/2024-July/007238.html>

Jeremy thinks that the Bcc: recipients shall be concealed not only
from the normal (To: and Cc:) recipients, but also from each other,
and that the standard wording "muddy", whereas I think the stardard
is clear in that the Bcc: recipeints shall be concealed /at least/
from the To: and Cc: recipietns, but may see one another. We need
beg educated opinions on the matter:

Jeremy Cook to Anton Shepelev:

Jeremy Cook:

RFC 5322 muddies the waters a bit by saying:

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.)

As written, this is ambiguous, and seems to suggest
that "other implementations" might actually keep the
entire BCC line with all listed addresses.

The only requirement for Bcc: is that it be absent form
the messages sent to the To: and Cc: recipients. The
standard does not regulate whether the Bcc-ers
themselves can see one another.

I strongly disagree. I think the standard makes it clear
that Bcc recipients are not supposed to see one another.
They are supposed to be secret and concealed.

The RFC says "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."

I see it this way: there are three groups of recipients:

1. To:
2. Cc:
3. Bcc:

When talking about the Bcc: group, the phrase `other
recepients' refers to recipients that are not in the Bcc:
group, and therefore in To: and Cc: . Observe also that
this interpretation of mine is the only one that makes the
entire RFC internally consistent, because below it allows
two /implementation-dependent/ usages of the Bcc: header,
quote (sans paretheses):

1. the "Bcc:" line is removed even though all of the
recipients are sent a copy of the message.

2. 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.

As you see, recipents are operated on group level, by
inclusion and removal of the entire Bcc: header, rather than
editing its contents. Then it remarks that the strict
policy you defend is /also/ allowed:

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.

Item 1, by the way, satisfies your requirement by removing
the Bcc: header altogether!

I'm sure that is not true. It nowhere says that
limitation anywhere in the RFC. BCC recipients are
supposed to be private, not disclosed to others.

Bcc recipients are not disclosed to other, non-Bcc
recipients.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor:

My long standing understanding based on personal
experience is that BCC is really an MUA construct wherein
the BCC recipient(s) will receive a copy of the message as
they are added as an SMTP envelope recipient while
expressly being excluded from the RFC 5322 (et al.)
headers.

I am surprised. What made you think it Bcc: is handled by
the MUA intead of the SMTP server?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/25/24 09:59, Anton Shepelev wrote:

Over on the Sypheed mailing list, we are having a discussin about
the interpretatio of RFC 5322 with regard to the Bcc: field:

<https://www.sraoss.jp/pipermail/sylpheed/2024-July/007238.html>

Jeremy thinks that the Bcc: recipients shall be concealed not only
from the normal (To: and Cc:) recipients, but also from each other,

My long standing understanding based on personal experience is that BCC
is really an MUA construct wherein the BCC recipient(s) will receive a
copy of the message as they are added as an SMTP envelope recipient
while expressly being excluded from the RFC 5322 (et al.) headers.

As such, BCC recipients would also not see themselves or other BCC
recipients.



--
Grant. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/25/24 17:46, Anton Shepelev wrote:

I am surprised. What made you think it Bcc: is handled by
the MUA intead of the SMTP server?

Because I speak SMTP and know that there is no concept of BCC, or CC, or
even TO in the SMTP protocol.

The SMTP envelope is where servers send / deliver messages to.

It's trivial to have the SMTP envelope have completely different
addresses than the headers in the message which is inside of the envelope.



--
Grant. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/07/2024 08:32, Grant Taylor wrote:

On 7/25/24 09:59, Anton Shepelev wrote:

Over on the Sypheed mailing list, we are having a discussin about the
interpretatio of RFC 5322 with regard to the Bcc: field:

<https://www.sraoss.jp/pipermail/sylpheed/2024-July/007238.html>

Jeremy thinks that the Bcc: recipients shall be concealed not only
from the normal (To: and Cc:) recipients, but also from each other,

My long standing understanding based on personal experience is that BCC
is really an MUA construct wherein the BCC recipient(s) will receive a
copy of the message as they are added as an SMTP envelope recipient
while expressly being excluded from the RFC 5322 (et al.) headers.

As such, BCC recipients would also not see themselves or other BCC recipients.

When I was taught to type "Blind Carbon Copies" on manual typewriters,
with real carbon paper, envelopes 9and stamps) that had to be moistened,
the idea was that named recipients of such documents would not know who
else might receive a copy.

But that's a) Common Sense, and b) Basic English.

Cheers,
Gary B-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On tor, 2024/07/25 at 17:59:47 +0300, Anton Shepelev wrote:

Over on the Sypheed mailing list, we are having a discussin
about the interpretatio of RFC 5322 with regard to the Bcc:
field:

<https://www.sraoss.jp/pipermail/sylpheed/2024-July/007238.html>

Jeremy thinks that the Bcc: recipients shall be concealed not only
from the normal (To: and Cc:) recipients, but also from each other,
and that the standard wording "muddy", whereas I think the stardard
is clear in that the Bcc: recipeints shall be concealed /at least/
from the To: and Cc: recipietns, but may see one another. We need
beg educated opinions on the matter:

It stands for "blind carbon copy" and thus should not see any recipient of
the message apart from themselves. If they start seeing everyone else on
Bcc in the message, it is no longer a "blind" carbon copy. IMHO

--
Kind regards,

/S

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sirius about the Bcc: field:

It stands for "blind carbon copy" and thus should not see
any recipient of the message apart from themselves. If
they start seeing everyone else on Bcc in the message, it
is no longer a "blind" carbon copy. IMHO

The relevant RFCs (822, 2822, 5322) allow both approaches:

1. each blind recipient can see only himself in the Bcc:
line,

2. each blind recipient can see all the other blind
recipients on the Bcc: line.

It it said with most clairyt in RFC 822, section 4.5.3:

<https://datatracker.ietf.org/doc/html/rfc822#section-4.5.3>

The latter RFCs are more liberal, but their language is more
formal. In 3.6.3 they say the copy sent to the blind
recipients may contain a Bcc: line, but do not specify the
contents of that line.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Gary R. Schmidt to Grant Taylor:

As such, BCC recipients would also not see themselves or
other BCC recipients.

When I was taught to type "Blind Carbon Copies" on manual
typewriters, with real carbon paper, envelopes 9and
stamps) that had to be moistened, the idea was that named
recipients of such documents would not know who else might
receive a copy.

But that's a) Common Sense, and b) Basic English.

Concealing blind (Bcc:) recipients from other (To:, Cc:),
non-blind, recipients as a group makes sense as well, and is
explicitely allowed in RFC 822, section 4.5.3:

This field contains the identity of additional recipients
of the message. The contents of this field are not
included in copies of the message sent to the primary and
secondary recipients. Some systems may choose to include
the text of the "Bcc" field only in the author(s)'s copy,
while others may also include it in the text sent to all
those indicated in the "Bcc" list.

And I am sure that RFCs 2822 and 5322 both only extend those
requirements by adding more options for the handling of
Bcc:, while remaining backwards compatible with 822. In the
latter two RFCs, a Bcc: line listing all of the blind
recipients is not forbidden in 3.6.3, and is also mentioned
as a possible choice in section 5:

If the "Bcc:" field sent contains all of the blind
addressees, all of the "Bcc:" recipients will be seen by
each "Bcc:" recipient.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)