headers
Derek Martin | 22 Jul 2004 06:34

Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

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]
(Continue reading)

Permalink | Reply | 531 comments |
headers
Derek Martin | 22 Jul 2004 07:45

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

On Thu, Jul 22, 2004 at 01:34:22PM +0900, Derek Martin wrote:
> > A5004: Exim removes Bcc: lines only if you call it with the -t option (i.e.
> >        when it is acting partly as an MUA). 

This is another point I neglected to address, though it is mostly a
semantic point and not very important.  However I think that it is
characteristic of a misunderstanding of the role of the MUA and the
MTA, and thus worth mentioning.

When called with the -t option, I think it is not correct to think of
exim as acting partly as MUA.  It is the job of the MUA to compose and 
display e-mail for the user.  The role of the MTA is to transmit
e-mail between various computers.  However, clearly before the MTA can
do that, it must have accepted in some way a message from an MUA to be
passed on, i.e. it must provide an INTERFACE for MUAs to pass on mail.
When Exim is invoked in this manner, it is not acting as an MUA, but
merely interfacing with some MUA.

As it happens, one can invoke the MTA on the command line and type in
the message directly.  However Exim should still not be considered the
MUA in this case; instead the MUA is the user's terminal, or standard
input.  Exim is only interfacing with the user's chosen MUA (his
terminal) in order to collect messages for transmission.

--

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

Permalink | Reply | 0 comments |
headers
Philip Hazel | 22 Jul 2004 11:54
Picon
Picon

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

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."
>
(Continue reading)

Permalink | Reply | 530 comments |
headers
Derek Martin | 23 Jul 2004 06:09

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

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:
(Continue reading)

Permalink | Reply | 15 comments |
headers
Derek Martin | 23 Jul 2004 06:53

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

On Thu, Jul 22, 2004 at 10:54:02AM +0100, Philip Hazel wrote:
> 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 should have addressed this more thoroughly, rather than just
dismissing it out of hand, because it actually strenthens my case.
This RFC, just like 2822, also states that "The contents of this field
are not included in copies of the message sent to the primary and
secondary recipients."  This is the part that Exim ignores, and this
is why it is broken.

The additional processing that I'm suggesting does not take away the
user's capability of "leaving in the Bcc or not for certain
recipients."  It only ensures that those who clearly aren't meant to
receive it don't.

> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Byng-Maddick | 23 Jul 2004 11:44

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

On Fri, Jul 23, 2004 at 01:09:45PM +0900, Derek Martin wrote:
> RFC 822 is superceeded by 2822; it is therefore irrelevant.

Dear Derek

| 0822 Standard for the format of ARPA Internet text messages. D.
|      Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733)
|      (Obsoleted by RFC2822) (Updated by RFC1123, RFC1138, RFC1148,
|      RFC1327, RFC2156) (Also STD0011) (Status: STANDARD)
                                                 ^^^^^^^^
| 2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format:
|      TXT=110695 bytes) (Obsoletes RFC0822) (Status: PROPOSED STANDARD)
                                                      ^^^^^^^^^^^^^^^^^

This is from the rfc index as updated today, HTH, HAND.

Personally, I happen to agree with Exim's current handling. The way that
SMTP is defined, the envelope and the headers are completely separate,
they only bear relation to each other by convention. If your MUA can't
construct the headers and envelope for transmission appropriately, and
I encourage you to look at the way that it passes mail to the MTA for
onward transmission, that would seem to be your MUA's problem. My copy
of mutt seems to cope perfectly well with using Bcc in its own construction
of the envelope, and then deleting it, and I would suggest that this is
the correct behaviour.

This is also probably the wrong list to be discussing this on.

Cheers
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philip Hazel | 23 Jul 2004 12:09
Picon
Picon

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

On Fri, 23 Jul 2004, Derek Martin wrote:

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

Well, if it is as bad as "alarm", then let's get this generally
discussed by the experts - for example on the ietf-822 list and/or any
other list where the Big Gurus live.

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

... and none of them are mentioned in RFC 2821, where I see this:

   As discussed in section 2.4.1, a relay SMTP has no need to inspect or
   act upon the headers or body of the message data and MUST NOT do so
   except to add its own "Received:" header (section 4.4) and,
   optionally, to attempt to detect looping in the mail system (see
   section 6.2).

OK, that's specifically a "relay" SMTP. I suppose this comes down to
"submission" vs "relay", and Exim behaves as "submission" only for -t.
(Note, incidentally, that there are MUAs that submit using SMTP via
127.0.0.1; Exim does not recognize that automatically as special.)
(Continue reading)

Permalink | Reply | 12 comments |
headers
Derek Martin | 24 Jul 2004 08:22

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

On Fri, Jul 23, 2004 at 11:09:55AM +0100, Philip Hazel wrote:
> How can Exim tell when it is receiving a "submission"?

If the message has no pre-existing Received: header, then it must be a
submission, musn't it?  This is not all-inclusive, I think, but it's a
start...

> 1. For -t it is obvious that it is a submission.
> 
> 2. Without -t, it is not (I contend). Consider a message that came from
>    outside, was piped to Majordomo or MailMan, and is then being
>    re-injected for final delivery. This isn't a "submission", at least
>    not from the local host.

Your contention is a fantasy.  Though it is unfortunate, many MUAs
(most notably PC-oriented ones) inject their messages into the mail
system via other means, such as connecting directly via SMTP.  You
mentioned this yourself, following this last statement.

> > For example, the MTA can re-write headers to ensure that return mail
> > will be deliverable.
> 
> It can, but SHOULD or MUST it? RFC 821 says:

My point wasn't whether it should or must, only that other reasons to
do so exist and are allowed by the RFCs, as you yourself point out.
In which case, what's wrong with adding one more reason?

> >    However, some message systems may use information from the contents
> >    to create the envelope.  It is intended that this standard
(Continue reading)

Permalink | Reply | 6 comments |
headers
Derek Martin | 24 Jul 2004 08:46

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

On Fri, Jul 23, 2004 at 10:44:50AM +0100, Matthew Byng-Maddick wrote:
> On Fri, Jul 23, 2004 at 01:09:45PM +0900, Derek Martin wrote:
> > RFC 822 is superceeded by 2822; it is therefore irrelevant.
> 
> Dear Derek
> 
> | 0822 Standard for the format of ARPA Internet text messages. D.
> |      Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733)
> |      (Obsoleted by RFC2822) (Updated by RFC1123, RFC1138, RFC1148,
> |      RFC1327, RFC2156) (Also STD0011) (Status: STANDARD)
>                                                  ^^^^^^^^
> | 2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format:
> |      TXT=110695 bytes) (Obsoletes RFC0822) (Status: PROPOSED STANDARD)
>                                                       ^^^^^^^^^^^^^^^^^

Fair enough, but it actually makes no difference whatever to my
arguments...

> If your MUA can't construct the headers and envelope for
> transmission appropriately, and I encourage you to look at the way
> that it passes mail to the MTA for onward transmission, that would
> seem to be your MUA's problem. 

As you no doubt realize, I also use mutt, and I wouldn't have a
problem were I to switch to using Exim as my MTA, NOW THAT I AM AWARE
OF THE ISSUE...  The trouble is, the vast majority of e-mail users
won't know that Exim behaves this way, or even that their provider
uses Exim, and (as you no doubt already know from other posts) are
quite dismayed to find out that a message they wrote to their
co-worker and Bcc'd to their boss clearly shows that they did so.  Or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Derek Martin | 24 Jul 2004 10:01

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

On Fri, Jul 23, 2004 at 11:09:55AM +0100, Philip Hazel wrote:
> > However, RFC 2822 DOES NOT ALLOW for the recipients named in the To:
> > and the Cc: lines to receive copies of the Bcc: lines.
> 
> Sure. But it does not make it clear whose job it is to enforce this.

With more reflection, I think what is needed is some way for the
client to tell the MTA what to do.  [I'm still operating under the
assumption that because much of the necessary code already exists in
the MTA, and there ar far fewer of them, it's much more efficient to
handle this on the MTA side.]  I suggest a Bcc-Action: header, with
the following possible values:

  As-is
  	Don't do any processing to the Bcc line.  The client is taking
	the responsibility upon itself.

  One-recipient
  	Send individual copies to Bcc recipients, with a Bcc line that
	mentions only them.

  All-recipients
  	Send Bcc recipients a copy with the entire original Bcc line

In order to safeguard the users as much as possible, if the header is
missing, the default action should be One-recipient.  The MTA would be
required to check for this header and process the message
appropriately.  Clients which really do want to provide the user with
a choice can provide a configuration option/variable and set the
header accordingly.  Those which don't bother would get the behavior
(Continue reading)

Permalink | Reply | 4 comments |

Gmane