At 11.56 -0500 01-01-23, Keith Moore wrote:
> I read the RFC 822 very carefully but I was not able to read
something about
a limitation in the BCC Field. Is there such a thing as a maximum number of
characters that can be written in the BCC field?
no. and since Bcc processing is done by the submitter's user agent
(or in some cases the submitter's MTA acting on behalf of the user agent),
length of Bcc fields matters even less than length of other fields.
Most mailers seem to remove "Bcc" fields from a message before
sending it to the first MTA, or else the first MTA removes
this field. This means that most "Bcc" recipients will receive
messages without their name in any of the recipient fields
in the message header.
I am not sure if this is really correct, according to RFC822
each Bcc recipient should see its own name (and possibly also
other Bcc recipients) in a "Bcc" header in the mail.
The reason why most mailers handles this in this slightly
incorrect way is that they need only send one copy of the
message. If some or all Bcc recipients should have their
name in the header, at least two different messages have
to be sent, one with and one without Bcc recipients, and
preferably N+1 versions of the message if there was N
Bcc recipients, so that each Bcc recipients gets the
message with only him/herself in the Bcc header, and so
that the non-Bcc recipients do not see the Bcc recipients
at all.
This is rather complex processing, which most mailers
skip by just removing the Bcc recipients from the message
header before sending it, and only specifying the Bcc
recipients on the envelope.
---
Below is the text in RFC822 on the Bcc field, and which
explains the procedure which many mailers do not adhere to:
4.5.3. BCC / RESENT-BCC
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 reci-
pients. 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.
---
The new msgfmt standard, which soon will replace RFC822,
accepts the existing practice by allowing it as one new
way of handling the "Bcc" header. Below is the text in
the new msgfmt standard:
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. There are three ways in
which the "Bcc:" field is used. In the first case, when a message
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
removed even though all of the recipients (including those specified in
the "Bcc:" field) are sent a copy 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.) Finally, since a "Bcc:" field may contain no
addresses, a "Bcc:" field can be sent without any addresses indicating
to the recipients that blind copies were sent to someone. Which method
to use with "Bcc:" fields is implementation dependent, but refer to the
"Security Considerations" section of this document for a discussion of
each.
--
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/