On Thu, Feb 5, 2015 at 6:33 AM, Jasen Betts <[email protected]> wrote:
>
>
> that will work for CC and BCC addresses too, but only on the
> originating server
>
> BCC can only be checked on the originating server
>
That's a bit imprecise.
I would say that the contents of the original Bcc field is ultimately only
known by the originating MUA, and not even the originating server.
Bcc is a message format thing, not an SMTP thing, but there is defined (but
unpredictable) behaviour for how the Bcc contents may affect SMTP.
What is listed in From, To, Cc, and Bcc is independent of what is used as
envelope-sender and envelope-recipient.
The originating server can ONLY see the Bcc field if the MUA put it there
or left it in place.
The receiving server can ONLY see the Bcc field if the previous server in
the chain put it there or left it in place.
But it is possible for even the receiving MUA to see a Bcc field.
RFC 2822:
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.
Resnick Standards Track [Page 22]
RFC 2822 Internet Message Format April 2001
When a message is a reply to another message, the mailboxes of the
authors of the original message (the mailboxes in the "From:" field)
or mailboxes specified in the "Reply-To:" field (if it exists) MAY
appear in the "To:" field of the reply since these would normally be
the primary recipients of the reply. If a reply is sent to a message
that has destination fields, it is often desirable to send a copy of
the reply to all of the recipients of the message, in addition to the
author. When such a reply is formed, addresses in the "To:" and
"Cc:" fields of the original message MAY appear in the "Cc:" field of
the reply, since these are normally secondary recipients of the
reply. If a "Bcc:" field is present in the original message,
addresses in that field MAY appear in the "Bcc:" field of the reply,
but SHOULD NOT appear in the "To:" or "Cc:" fields.
Note: Some mail applications have automatic reply commands that
include the destination addresses of the original message in the
destination addresses of the reply. How those reply commands behave
is implementation dependent and is beyond the scope of this document.
In particular, whether or not to include the original destination
addresses when the original message had a "Reply-To:" field is not
addressed here.
RFC 2821:
7.2 "Blind" Copies
Addresses that do not appear in the message headers may appear in the
RCPT commands to an SMTP server for a number of reasons. The two
most common involve the use of a mailing address as a "list exploder"
(a single address that resolves into multiple addresses) and the
appearance of "blind copies". Especially when more than one RCPT
command is present, and in order to avoid defeating some of the
purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
the full set of RCPT command arguments into the headers, either as
part of trace headers or as informational or private-extension
headers. Since this rule is often violated in practice, and cannot
be enforced, 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.
There is no inherent relationship between either "reverse" (from
MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
transaction ("envelope") and the addresses in the headers. Receiving
systems SHOULD NOT attempt to deduce such relationships and use them
to alter the headers of the message for delivery. The popular
"Apparently-to" header is a violation of this principle as well as a
common source of unintended information disclosure and SHOULD NOT be
used.
Appendix B, Generating SMTP Commands from RFC 822 Headers
1. Each recipient address from a TO, CC, or BCC header field SHOULD
be copied to a RCPT command (generating multiple message copies if
that is required for queuing or delivery). This includes any
addresses listed in a RFC 822 "group". Any BCC fields SHOULD then
be removed from the headers. Once this process is completed, the
remaining headers SHOULD be checked to verify that at least one
To:, Cc:, or Bcc: header remains. If none do, then a bcc: header
with no additional information SHOULD be inserted as specified in
[32].
--
Jan
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
