[ On Friday, August 13, 2004 at 11:21:12 (+0100), Philip Hazel wrote: ]
> Subject: [Exim] The Bcc Issue
>
> 2. It has been reported to me that OpenWave InterMail, MS SMTP, MS
> Exchange, and qmail behave in the same way as Exim for incoming SMTP
> messages (i.e. they leave Bcc: lines alone).
Smail-3 behaves the same way, and always has done so, as per this
comment in the source:
/*
* Bcc: fields are removed only if we are processing the header
* for addresses, otherwise we assume that the user agent would
* have removed them if it didn't want them passed along
*/
I don't think it can be said any simpler or more succinctly, though I'll
expand upon this line of reasoning below.
> 3. I have also been told that Sendmail, at least in some configurations,
> always removes any Bcc: lines from any message that it handles. The
> same is apparently true of Postfix and Lotus Notes 5.
There doess indeed appear to be a way to make modern Sendmail always
delete the BCC header, but I'm reasonably certain it normally behaves in
the same way as Smail and Exim et al -- or at least it did so up to some
point fairly recently. I base this claim on the fact that in Smail-3's
early days there was a great deal of pressure from many fronts for it to
be made to behave as closely to Sendmail from the user's perspective as
we possible and sane to do (and there are still lots of notes to this
effect spread throughout the code). BCC header behaviour was a far
hotter topic back in the '80s too and so any differences on this front
would almost certainly have been documented and widely discussed.
Note also that there was considerable discussion at the time as to
whether or not Smail should use the silly "apparently-to" header as
Sendmail did/does. Currently Smail only does this if the message did
not originate locally, as per this comment from the code:
/*
* Sendmail inserts Apparently-To: fields because RFC822 people
* complained about it being against the rules to add a To:
* line. We cheat. If the letter is not originated locally,
* use the Apparently-To: convention. Otherwise do it the
* right way.
*
* We'll see if anybody complains
*/
I've been tempted several times to rip this out completely and always do
it "the right way", but so far I've resisted.
Also related to BCC handling with '-t' is that Sendmail seems to have
pioneered the use of an empty mailbox list in a group address with the
display name "undisclosed-recipients" whenever it was forced to add a
non-empty recipient header due to BCC processing (though see below about
similar behaviour in MH). Smail doesn't do this yet, but I have been
considering implementing it. Nobody's complained loud enough about the
missing recipient headers yet though. :-)
> 4. Among the MUAs, I think that Pine never sends Bcc: lines, but Mutt by
> default does, assuming that the MTA will deal with them (Mutt does
> not use the -t option).
MH traditionally used RFC 934 encapsulation to forward copies of the
message to BCC headers but also had its own "DCC" header (Distribution
Carbon Copies) which didn't encapsulate the original but still hid the
distribution list from any normal "to" or "cc" recipients. If all the
recipients are blind MH replaces the entire BCC header with a "Bcc:
Blind Distribution List: ;" header, but otherwise I think it simply
removes the BCC header. This is safe with BCC in MH because of the
encapsulation (the recipient clearly sees that it was a BCC to them).
> The (re-)discussion of this issue arose because the combination of
> (default configured) Mutt and Exim does not behave the way people
> expect. Mutt sends Bcc: lines, and Exim lets them through to all
> recipients.
Mutt is broken (though as you say only by default as it apparently has a
configuration option which can and should be used to correct is
behaviour). Since Mutt does not use '-t' it _must_ deal with the
{Resent-}BCC headers all by itself.
Having now skimmed through the discussion related to the Mutt bug report
bout this on the(a?) Mutt list I'm amazed and astounded that those
involved have such a narrow view of the issue and that they have also,
initially at least, singled out Exim as the lone culprit.
Unfortunately it seems Mutt still fails to follow the advice of RFC 2822
even when it is configured properly as IIUC it will always completely
omit the BCC header in that state. The RFC makes it quite clear that
the entire header _should_ never be deleted without trace, at least not
in the copies of a message sent to the BCC recipients since that would
leave them with no indication that their copy was "private" and thus it
would be almost certain that they would reveal their presence on the
full recipient list if they were to reply to the message. (RFC 2822
3.6.3 contains other instructions on how MUAs should address replies to
messages containing BCC headers.)
Mutt _should_ probably use '-t', though on second thought having had
fairly deep experience with trying to unravel Mutt's hand-made address
list parser (to fix its many bugs for a user who refused to use a less
buggy mailer) suggests to me that perhaps it's best that Mutt not use
'-t' since that might result in messages being sent to a completely
different set of addresses by the MTA than Mutt would have presented on
the command line and thus the result may confuse and frustrate the user.
> An MTA has
> no means of distinguishing what the sender wanted.
Precisely. By implication of the RFC requirements it's only sane to
allow the MTA to deal with the BCC headers IFF it is also doing part of
the MUA's job in parsing out the list of intended recipients (i.e. IFF
it has been invoked with the Sendmail-compatible '-t' option).
In _all_ other cases the MTA _should_ ignore the headers (especially all
the "recipient headers") and just act only as an MTA and deliver only to
the envelope-specified recipient addresses. The MTA has no business
mucking with the headers behind the MUA's back Without being explicitly
told to do so via '-t' , even if one MUA's implementors have made
mistaken assumptions about where the responsibilities lie.
Clearly the command-line invoked MTA has no way to identify whether its
caller is an MUA or some transport subsystem such as UUCP. I.e. I think
it's safe to generalize that an MTA which running in a mode where it has
not been told to parse headers (i.e. when running without the sendmail-
compatible '-t' command-line option) should behave in exactly the same
regardless of where the envelope information comes from and it should
ignore all the (recipient) headers regardless of whether it's accepting
a message by way of SMTP, or by way of UUCP via the rmail command line,
or whatever. I.e. Mutt invokes the mailer as it it were also another
MTA and it provides all the necessary envelope information on the
command line so the MTA must not process the recipient headers at all.
If an MUA wishes to push some of its responsiblity for header parsing
and management onto the MTA than it may do so _only_ by using the
equivalent of the Sendmail '-t' command-line option.
I always thought the only major controversy was over the potential
leaking of BCC recipients into the 'Received' headers seen by other
users.... :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
