Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Anton Shepelev <anton.txt@g{oogle}mail.com>
Newsgroups: comp.mail.headers
Subject: Bcc: according to RFC 5322
Date: Thu, 25 Jul 2024 17:59:47 +0300
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <20240725175947.ec0c6aab9964a00f7301992b@g{oogle}mail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 25 Jul 2024 16:59:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2ff382c0b6e2cff677ce7b628cdca430"; logging-data="2456298"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18nxziVzq+x9lMbvwPF5eS2ntPICVIYB4M="
Cancel-Lock: sha1:IDknLKuYsMUS2MfqXXxMoNnXgi0=
X-Newsreader: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Xref: csiph.com comp.mail.headers:37

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