ietf-822
[Top] [All Lists]

Re: The Bcc Issue

2004-08-18 09:02:26

Excellent summary, Philip!

Just for completeness, here is an excerpt from the sendmail man page, describing the -t option.

     -t    Read message for recipients. To:, Cc:, and Bcc:  lines
           will  be  scanned for people to send to. The Bcc: line
           will be deleted before transmission. Any addresses  in
           the  argument list will be suppressed. The NoRecipien-
           tAction Processing Option can be used  to  change  the
           behaviour when no legal recipients are included in the
           message.

Note that this strictly affects how the sendmail program is used from the command line and reading from standard input, and does not affect how it works when reading input using the SMTP protocol. (There is NO sendmail option which tells it to look at To/Cc/Bcc when it is using the SMTP protocol.)

        Tony Hansen
        tony(_at_)att(_dot_)com

Philip Hazel wrote:


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



<Prev in Thread] Current Thread [Next in Thread>