On Thu, 22 Jul 2004, Derek Martin wrote:
> I first ran into this issue about 6 years ago, when I noticed that I
> received a blind carbon copy from an exim user, and all the Bcc
> recipients were listed in the e-mail. Russell King recently posted a
> message to mutt-dev suggesting that this is caused by a bug in Mutt,
> but I think careful reading of RFC 2822 clearly indicates that's not
> the case.
Derek,
I am going abroad tomorrow for 2 weeks, so my time is a bit limited. I
hope you will excuse the brevity and brusqueness of some of this
response.
This issue has been thrashed out on the Exim list and on other forums in
the past.
> I told Russell that he could pass on my arguments to the Exim
> developers if he wanted to, but after considering the issue further I
> felt compelled to do so directly.
He has done so.
> After that, the RFC states:
>
> > 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."
>
> You wrote that this seems to suggest that the onus of what to do with
> the Bcc field is on the MUA.
We are talking about RFC 2822 here. That is all to do with MUAs, which
are the components that handle message content. MTAs should not be
concerned with content, other than to add Received: headers. (Of course,
some of them do stray a bit. :-)
> It is only the MUA's job to compose and view e-mail... Once a mail is
> composed, the MUA should pass the mail on to the MTA to have it
> delivered. It is the MTA's job to determine how and to whom the mail
> is delivered.
Precisely - and NOT to mess with the content.
> Therefore, if a message composed by an MUA contains a Bcc field, the
> MTA must responsibly decide how to transfer that message to its
> intended recipient.
But RFC 2822 give you several ways of handling Bcc; only the human
sender of the message can know which is wanted.
> As we have established, the RFC defines the Bcc field, and enumerates
> three methods of handling it. It states that the handling of it is
> implementation-dependent, but with a warning about considering the
> security consequences of how it his handled. But, handled by what?
> As we saw just a moment ago, we must be talking about it being handled
> by the MTA.
I'm afraid I do not agree. I don't think the intent of the RFC 2821/2822
split is to encourage message modification by MTAs, and I believe that
2822 is primarily talking about MUA actions.
> In summary, Exim should acknowledge that it may receive any of these
> three forms of Bcc fields, and it should not shirk its responsibility
> to prevent recipients from unintentionally being able to identify the
> Bcc recipients.
I do not believe that this is the MTA's responsibility. I do not think
this responsibility is documented anywhere in the RFCs.
> Exim developers have stated that the MUA must take the responsibility
> to remove the Bcc lines. If that weere the case though, there would
> never be a Bcc line in the message.
Not true. There is the case when the Bcc line contains the address of
the Bcc recipient to which the message is being sent.
I note the following in RFC 2821:
--------------------------------------------------------------------------
B. Generating SMTP Commands from RFC 822 Headers
Some systems use RFC 822 headers (only) in a mail submission
protocol, or otherwise generate SMTP commands from RFC 822 headers
when such a message is handed to an MTA from a UA. While the MTA-UA
protocol is a private matter, not covered by any Internet Standard,
there are problems with this approach. For example, there have been
repeated problems with proper handling of "bcc" copies and
redistribution lists when information that conceptually belongs to a
mail envelopes is not separated early in processing from header
information (and kept separate).
It is recommended that the UA provide its initial ("submission
client") MTA with an envelope separate from the message itself.
However, if the envelope is not supplied, SMTP commands SHOULD be
generated as follows:
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
--------------------------------------------------------------------------
This describes the -t case for Exim, and Exim does precisely that.
There is no other reference to removing or otherwise processing Bcc in
RFC 2821. There is, however, in RFC 2822. I contend that 2822 is talking
about MUAs when it 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. 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.
--------------------------------------------------------------------------
I believe the "is prepared to be sent" applies to what the MUA does.
This is a "religious" argument that will probably rage forever. There
was a thread about mutt back in 1998 on the Exim mailing list:
http://www.exim.org/pipermail/exim-users/Week-of-Mon-19980810/008770.html
I have not changed my view from what I wrote then:
--------------------------------------------------------------------------
I argue that Exim is not broken, because of this paragraph in RFC 822:
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.
I interpret that as giving the user (via the MUA) the option of leaving
in the Bcc or not for certain recipients. I don't think the MTA should
interfere with the message that the MUA gives it. The primary business
of an MTA is indicated by the T - to transport messages, not to fiddle
around with them. [In fact, I don't really like the -t option, but have
to support it for compatibility. When it is set, the MTA is performing
an MUA function, namely, constructing an envelope. It can't interrogate
users to see if they want Bcc left in for Bcc recipients, so the only
thing it can do is remove Bcc lines. I consider this to be a special
case.]
Of course, like a number of other things, if the implementors of the
MUAs don't see the world in the same light, I could implement an option
always to remove Bcc lines in messages submitted locally. This would
(a) Remove the possibility of leaving Bcc in for some recipients.
(b) Not work for messsages submitted from an MUA running on a personal
computer, unless I implemented options for listing hosts and nets for
which Bcc removal was applied. This all seems to me to be a huge amount
of effort for small gain.
--------------------------------------------------------------------------
It is nowadays perfectly possible to do (b) on Exim by writing a
suitable system ACL or filter. Indeed, if you want to, you can configure
Exim to remove Bcc: from all the messages it processes.
One way to get some "authoritative" opinions would be to ask on the
ietf-822@??? mailing list. There seems to be an archive of this
list, but a search for "bcc" doesn't find anything. Sorry, I have no
more time now to seek other references.
Regards,
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
