Summary of the Bcc discussion: posted to exim-users, exim-dev, & ietf-822
There were a few responses on the exim-users mailing list. There was a
longer discussion on the ietf-822 mailing list, to which a number of
people who have worked in email protocol development for many years
contributed. These included Keith Moore (author of several RFCs), Dave
Crocker (author of RFC 822), and Tony Hansen (another RFC author).
Some more data points were posted: Smail-3 behaves like Exim; Elm and
Mulberry behave like Pine (they do their own Bcc: processing).
1. The substantive point
With one possible exception, everybody's opinion was that an MTA has no
business messing with Bcc: header lines. Here is a quote from Tony
Hansen:
"The MUA, however it is constituted, should handle all BCC processing,
and the cloning of messages with and without the Bcc: header."
This confirms my belief that Exim's default behaviour is the correct
one. I hope this particular issue is now laid to rest once and for all.
I have saved all the responses just in case it arises again in the
future.
The possible exception was a post containing this paragraph:
The /usr/[s]bin/sendmail interface is a proprietary interface
introduced by Sendmail. So all other applications providing this
interface should be as close to Sendmail's behaviour as possible, i.e.
they should remove Bcc headers.
This is the "my country, right or wrong" argument. There was one
response that added "... when -t is specified", and that is also my
feeling. A call to /usr/sbin/sendmail without -t is not guaranteed to be
a submission. Indeed, the post continued:
Philosophically, the mailers are still doing the MUA's job by
sanitizing the message and (finally) handling it over to the message
router (MTA). It just happens that that part of Unix MUAs is usually
shipped along with the MTA.
and I would argue that without -t, you cannot, and indeed should not,
assume that the sending entity is an MUA that is submitting a new
message (see further discussion below).
2. Other discussion
Some interesting points of clarification came up in the discussion. The
functions of mail handling are now seen as split into four distinct
parts, as follows:
MUA -> MSA -> MTA -> MDA -> MUA
(user agent, submission agent, transfer agent, delivery agent). There is
nothing to say that each of these functional distinctions has to be
implemented by a different program. Thus, it is generally agreed that a
program handling a local incoming message using the "-t" command line
option is acting partly as an MUA (constructing the envelope) and partly
as an MSA (accepting a new message submission). If it goes on to deliver
the message over SMTP it is performing an MTA function. If it delivers
into a local mailbox it is performing an MDA function.
There was some opinion expressed that an MSA might be somewhere that
Bcc: header lines could be processed. As this is not sanctioned by RFC
2476 (for MUA->MSA delivery over a network), it would be necessary to
define an extension to the SUBMIT protocol so that the MUA could request
the MSA to do that processing. In the case of a submission via the
command line, the -t option is already available for this purpose.
When -t is not used, a general-purpose MTA such as Exim cannot guess
that it is being called as an MSA. It has to be configured as such, for
example by testing conditions such as "submitted from a host on the
local LAN" or "submitted via port 587". If an extension to SUBMIT were
defined, another test could be "requested by the SUBMIT protocol". (It
is quite easy to implement such tests in Exim and (for example) remove
Bcc: lines based on the result, but this has to be an explicit
configuration setting; it cannot be defaulted.)
Note that "submitted via the command line" (in the absence of -t) is not
good enough as a test for an MSA. Such messages may have come from
another email regime (e.g. UUCP - some people do still use it) or from a
virus scanner or a mailing list exploder.
3. Uses of Bcc
As part of the discussion, a list of uses of bcc was enumerated. There
are at least four major ones:
(a) As an instruction from the end user to the MUA to send a copy of the
message to one or more addresses, without telling the To: and Cc:
recipients.
(b) When present in a copies sent to bcc recipients, to inform them why
they received the message (and, if more than one bcc recipient is
listed, to inform them about additional bcc addressees). This should
alert bcc recipients to take care when replying.
(c) To prevent unwanted group replies where the sender wants to send a
copy of a message to someone (whether or not the other recipients
should know about this), but not subject that person to lots of
replies from the other recipients who blindly "reply-to-all".
(d) When saved in the sender's sent-mail folder, a Bcc: header acts as a
record of who the message was sent to.
Is that overloaded or is that overloaded? :-)
Regards,
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
