<<< Date Index >>>     <<< Thread Index >>>

Re: [BUG] mutt 1.2.5 sends mail with Bcc: header

On Thu, Jul 22, 2004 at 06:27:24PM -0400, Bob Bell wrote:
> On Thu, Jul 22, 2004 at 05:17:32AM +0900, Derek Martin wrote:
> > 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.
> 
> But this isn't actually the way that mutt works.

Sure it does; just because the MUA gives the MTA an envelope initially
doesn't mean the MTA necessarily uses it.  There are a number of
reasons why it might change.  The MTA may be configured to re-write
headers (and envelope addresses).  The MTA may re-route mail to a
different host that it knows about as being a better way to deliver
the mail.  The mail in question may be forwarded to a different user
based on a .forward file or other mechanism, etc...  The reality is
that the envelope specified initially by the MUA is largely
irrelevant.

> In particular, your statement that "[i]t is the MTA's job to determine
> how and to whom the mail is delivered"  seems to be broken by mutt.

I think I just gave plenty of examples to demonstrate that's not at
all true.

> Mutt takes in upon itself to parse the Bcc header and decide to whom the
> mail should be delivered, and to give that explicit recipient list to
> the MTA.  As such, it may be the proper behavior to either remove the
> Bcc header (i.e., unset $write_bcc by default), or to change behavior
> and specify "-t" to the MTA to instruct the MTA to parse the message for
> the recipient list, in which case the MTA should be expected to remove
> or modify the Bcc header.

I don't agree...  Well, I don't exactly disagree, but what I'm saying
is that it shouldn't be neccessary, based on the RFCs.  Mutt's current
default behavior seems to be perfectly compliant.  But I've just gone
on at length with Philip Hazel, Exim developer, about why that is; so
rather than duplicate my efforts, I'll just repost my response to him
here.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.
--- Begin Message --- 
On Thu, Jul 22, 2004 at 10:54:02AM +0100, Philip Hazel wrote:
> 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.

Sure, of course.  I hope you have a good trip!

> This issue has been thrashed out on the Exim list and on other
> forums in the past.

Well, I can't say that I'm surprised.  I'm sure that this behavior of
exim has alarmed more than a few people...  And I think rightly so.
You seem to have taken the opposite position from mine, and it seems
unlikely that I'll be able to pursuade you to mine.  Nevertheless,
I'll make one more attempt.

> 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. :-)

I have to disagree rather strenuously here, on several counts.  First,
there are lots of valid reasons for MTAs to mess with headers.  For
example, the MTA can re-write headers to ensure that return mail will
be deliverable.

Secondly, I think your interpretation that RFC 2822 applies only to
MUAs is directly contradicted by the following paragraph from the
introduction:

   However, some message systems may use information from the contents
   to create the envelope.  It is intended that this standard
   facilitate the acquisition of such information by programs.

Here, I think it is clear that the term "message system" refers, at
least in part, to the MTA.  It also states that the intent of the RFC
is to make it easy for the "message system", again the MTA, to create
an envelope.  This is the purpose of the -t option which you have
stated that you don't like.

What I will grant is that upon re-reading portions of the RFC, I can
see that an interpretation that some of it seems to refer to the MUAs
is possible.  However, I will say that at best, the RFC is vague and
ambiguous in a number of ways that are important; I think it is not a
well-written RFC.

> > 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.

As stated above, sometimes it is necessary for the MTA to change the
headers to ensure proper delivery.  Define "proper" how you like, but
I will include the idea that it must ensure that at most only the
recipient named in the Bcc line receives a copy of the messge with a
Bcc line mentioning his address (and no others).

> > 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.

However, RFC 2822 DOES NOT ALLOW for the recipients named in the To:
and the Cc: lines to receive copies of the Bcc: lines.  Despite this,
Exim passes them on.  From the definition of the Bcc field:

    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.

However, the way Exim currently handles the Bcc line, precisely this
can (and does) happen, if the message contains a Bcc line.

> > 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.

Neither is it clearly stated to be the responsibility of the MUA, in
any RFC that I'm familiar with.  Sometimes RFCs are deficient.  In
code, just as in life, we have responsibilities that are not defined
by the codified rules that govern us (laws in life, RFCs in computer
code), but exist nonetheless.  They come from practicalities and
common sense.

The fact is, the vast majority of other MTAs DO strip the Bcc lines,
and mailers exist which expect and/or rely on this behavior.  I can't
provide any besides Mutt with any certainty, but I believe others do
exist.  You'd probably know from experience better than I, having had
to respond to this issue in the past...

The point is, Exim's behavior is a departure from what the rest of the
world does and expects, whether codified in RFC form or not...  The
result is a legitimate security problem: recipients are
unintentionally revealed when exim transfers mail generated by some
RFC-compliant MUAs.  

There are three cases of Bcc lines defined in RFC 2822.

1. No Bcc line at all...  Blind recipients are named only in the
   envelope.

Exim already handles this case acceptably, by doing nothing.  Though
personally, I'd like to see MTA's ADD an explicit Bcc line to
recipients named in the envelope but not in the message headers.  This
improves the situation slighty with regard to the security concerns
mentioned in RFC 2822.

2. Bcc lines exist in the message, with one or more recipients.

This is where I think Exim fails to act responsibly.  I'll get back to
this in a second.

3. A blank Bcc line exists.

It should be passed on as-is, as I believe Exim does.

Exim is only deficient in handling #2.  The RFC states that this line
may exist in the message, and it also states that it is not to be
passed on to recipients other than those named in the Bcc line.
Logically, if it a) exists in the message, as pased on by the MUA, and
b) must not be passed on to recipients which are unnamed in the Bcc
line, then the only place where it is possible for this situation to
be remedied is within the scope of the processing done by the MTA.
Nothing else is possible.

As a practical matter, I think Exim (and any other MTA which doesn't
do this, but Exim is the only one I'm specifically aware of) must
take action to remedy this situation, regardless of whether or not any
RFC madates it.  In order to fully address the security considerations
of RFC 2822, I think the MTA must TRIM, but not REMOVE, a Bcc line
when it exist in a message it has received to be transmitted to some
other system.  To remove the Bcc line entirely is not appropriate, for
reasons previously mentioned here and stated in section 5 of RFC 2822.
The best case scenario is for the MTA to ensure that seperate copies
of the message are delivered to each of the recipients named in the
Bcc line, with a modified Bcc line mentioning only that individual
recipient.  However, failing that, removing the Bcc line is clearly
called for on the part of the MTA.

Logically, I think I have conclusively proven this at this point.  But
I'll go on to address another practical concern you raise.

> > 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.

Ok, what you're suggesting here is that the MUA generate individual
copies of the message for each Bcc recipient.  This certainly is
possible, but is not practical.  The MTA already does this as a normal
part of processing outgoing mail.  To duplicate this effort on the MUA
side is silly.  Furthermore, in cases where the outgoing MTA is
remote (i.e. such as when clients like Netscape et. al. use SMTP to
inject the message into the mail system), it increases the number of
connections from the client host to the MTA host needlessly.  The MTA
alread can do and already does this kind of processing.  Even in Exim's
case, it can do and does this processing in some cases; logically it
should do it (when called for) in all cases.  To ask the client to do
it when the MTA can (and usually will anyway) is a needless waste of
computing resources.

> 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

And some systems don't.  Exim should be robust enough to handle all
cases.  I don't think anything you quoted from RFC 2821 strengthens
your case at all.

> I argue that Exim is not broken, because of this paragraph in RFC 822:

RFC 822 is superceeded by 2822; it is therefore irrelevant.

If this argument doesn't convince you, then I expect  nothing will, so
I'll sign of here.  Peace.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

Attachment: pgpWfzxwQr5Dj.pgp
Description: PGP signature


--- End Message ---

Attachment: pgp9fZiScT5vo.pgp
Description: PGP signature