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.
After seeing Russell's post, and thinking about it further I believe
that the way Exim (and probably other MTAs) handles Bcc lines extant
in an SMTP message is a security problem serious enough to warrant
posting about it on Bugtraq. Below is my response to Russel on
mutt-dev, which I will probably post in some form or other on Bugtraq
later this week.
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.
On Wed, Jul 21, 2004 at 03:18:25PM +0100, Russell King wrote:
> Hi,
>
> I'm seeing a problem running mutt 1.2.5i and mutt 1.4.1i with exim 4.33.
> When a mail is sent with Bcc recipients, each recipient sees the complete
> BCC header in the message, which makes Bcc pointless.
Sure seems that way to me... As others point out, Mutt has a solution
to this problem. But IMNSHO it's not the right solution. The right
solution is to fix the MTA.
[SNIP]
> Too late for 4.40, but in any case, I doubt that it is a bug because
> this comes up as an FAQ very frequently. This is the FAQ entry:
The very fact that it comes up as a FAQ suggests the possibility that
the behavior may need to be reconsidered. Of course, often there are
valid reasons why something comes up as a FAQ but should not be
changed... However I don't think this is the case here.
> Q5004: I've recently noticed that emails I send with a Bcc: line are being
> delivered to their final destination with the Bcc: line still present.
>
> A5004: Exim removes Bcc: lines only if you call it with the -t option (i.e.
> when it is acting partly as an MUA). It does not remove Bcc: lines that
> are present in incoming SMTP mail or command-line mail that does not
> use -t. Indeed, it should not remove them, because only the
> initiating software (i.e. the MUA) can tell what to do with Bcc:
> lines; any MTA software has to leave them alone. This is what RFC 2822
> has to say about Bcc:
I think this response by Exim's development is ill-conceived, and
maybe even a little irresponsible. I'll attempt to form a cohesive
argument as to why that is. If you find it persuasive, you may feel
free to forward it to them.
> "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 think we're all clear on this part... The point for Bcc to exist is
that we want some people to receive a copy of the mail, but we don't
want the primary recipients to know about it. This is obvious.
The RFC goes on to delineate three possible ways "implementations" may
use the Bcc field. I think that for purposes of this discussion,
exactly what the three methods are is irrelevant; it is only important
that they exist. 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. But I don't see how it's possible to
come to that conclusion. 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. 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. I will demonstrate
that this can ONLY be done by the MTA, and not by the MUA nor by the
MDA.
First, another exceprt from this same RFC:
This standard specifies a syntax for text messages that are sent
between computer users, within the framework of "electronic mail"
messages. This standard supersedes the one specified in Request
For Comments (RFC) 822, "Standard for the Format of ARPA Internet
Text Messages" [RFC822], updating it to reflect current practice
and incorporating incremental changes that were specified in other
RFCs [STD3].
[Much irrelevant material omitted]
This specification is intended as a definition of what message
content format is to be passed between systems. Though some
message systems locally store messages in this format (which
eliminates the need for translation between formats) and others
use formats that differ from the one specified in this standard,
local storage is outside of the scope of this standard.
Note especially the first line of each of the two paragraphs I quoted:
"This standard specifies a syntax for text messages that are sent
between computer users..." and, "This specification is intended as a
definition of what message content format is to be passed between
systems." RFC2822 describes the format of mail IN TRANSIT. What part
of the mail system are we talking about here? Which part of the mail
system concerns itself with messages being passed between systems?
Well that would be the MTA. This RFC refers to the format of messages
as they are being passed between SMTP-compliant MTAs. What else could
it possibly be?
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.
What about those security concerns? Here's what the RFC says on that
[in section 5, Security Concerns]:
Many implementations use the "Bcc:" (blind carbon copy) field
described in section 3.6.3 to facilitate sending messages to
recipients without revealing the addresses of one or more of the
addressees to the other recipients. Mishandling this use of
"Bcc:" has implications for confidential information that might be
revealed, which could eventually lead to security problems through
knowledge of even the existence of a particular mail address. For
example, if using the first method described in section 3.6.3,
where the "Bcc:" line is removed from the message, blind
recipients have no explicit indication that they have been sent a
blind copy, except insofar as their address does not appear in the
message header. Because of this, one of the blind addressees
could potentially send a reply to all of the shown recipients and
accidentally reveal that the message went to the blind recipient.
When the second method from section 3.6.3 is used, the blind
recipient's address appears in the "Bcc:" field of a separate copy
of the message. If the "Bcc:" field sent contains all of the
blind addressees, all of the "Bcc:" recipients will be seen by
each "Bcc:" recipient. Even if a separate message is sent to each
"Bcc:" recipient with only the individual's address,
implementations still need to be careful to process replies to the
message as per section 3.6.3 so as not to accidentally reveal the
blind recipient to other recipients.
It is very clear from this that the point of the Bcc field is to allow
delivery of the message to some recipients, without allowing other
recipients to see that they are recipients. Since it is defined by
the RFC, and its implementation unspecified, compliant MTAs should
expect to receive messages which contain all three methods, and to
process them responsibly, keeping in mind the purpose of the Bcc
field, and the above security considerations.
That is, if the Bcc field is missing, as in the first case, then the
MTA need do nothing, except deliver the mail as-is to the recipients
specified in the message envelope. But since stripping the Bcc fields
removes a potentially vital piece of information from the e-mail (the
fact that the recipient was Bcc'd), the MTA should NOT remove the
recipient's name from the Bcc feild.
In the second case, the Bcc is present in the message, but when it is
passed on, the Bcc is removed when transmitted to "normal" recipients,
but a seperate copy is sent to recipients named in the Bcc field.
This is the best possible way to handle the Bcc field, and IMO the
only responsible way to handle it. Whenever possible, MTAs should do
this in order to safeguard the sender against recipients
unintentionally being revealed.
The third case includes a blank Bcc line. This is ok, but doesn't
tell the user that they were named on the Bcc line. So it doesn't
address the blind recipient copy concern raised by the RFC in secton
5. It does safeguard the sender, at least. Obviously the MTA should
pass on a blank Bcc line.
[In my original post, I neglected to mention that the MUA rightly
should include the Bcc lines in the message, so that the MTA can pass
them on to the recipients they were intended for. Or, alternately, if
the MUA decides not to use a Bcc line, then the MTA should ADD one
when it delivers the message to a Bcc recipient, in order to address
the security concerns in section 5 of the RFC.]
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. 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. RFC2822
explicitly permits this header, IN TRANSIT, and therefore the MTA must
handle it responsibly. The MDA can not be trusted to do it, because
in today's internet, the MDA must be assumed to be malicious and/or
compromised. So whenever possible, the MTA MUST handle the Bcc field.
Failure to do so may (and in the case of Exim, will) result in
recipients named in the Bcc line being revealed unintentionally. That
constitutes a security problem which could potentially have very
serious consequences for the sender and/or blind recipients.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
