Re: The Bcc Issue
2004-08-13 08:45:31
As one who has always despised the whole concept of bcc's, everything I
say should be taken with a large grain of salt. However...
The essence of a "bcc" is "I want a copy to go to this person, but I
don't want the 'real' recipient to know it." Given that
motivation/intent, writing it down in a header field is a somewhat
dubious concept to begin with. Anyone who puts in a "bcc" field
pretty obviously intends for it to be taken out before it reaches the
ultimate recipient. This suggests, however, an obvious way to handle
such headers: Take them out of the headers and (probably) inject them
into the SMTP recipient stream as soon as you possibly can!
In other words, a conservative default would be that *any* software
that received a message with such a field should feel very free to take
out the field, and should probably send the bcc as well. The nastiest
failure case is when the message is delivered with the bcc field
intact, so it seems to me we should try to err in the other direction
and pre-empt a faux pas if we can.
Thus, I would argue ever-so-impartially that mutt and exim are both
broken and should both be fixed. Exim might be easier to fix, since
it's just a matter of changing the default setting. Mutt's objections
might be more philosophical (see my PS) but physicians need to treat
patients who haven't followed their advice, and Mutt should do its best
to protect its users if they send bcc's. -- Nathaniel
PS -- Aside from the ambiguities in their
interpretation/implementation, I despise bcc's as Temptations to Sin.
While a few situations (e.g. fyis to celebrities) clearly justify
bcc's, more often bcc's promote poor communication and bad behavior.
The Puritan in me thinks you should have to type "~b" at an absolute
minimum in order to send a bcc, and probably something even more
obscure. :-) But it's still the software's job to try to minimize the
harm that happens to you once you use the feature, which is why I
argue for implementing this at more or less *every* protocol hop. --
NB
On Aug 13, 2004, at 6:24 AM, Philip Hazel wrote:
The Bcc Issue: posted to the exim-users, exim-dev, and ietf-822
mailing lists
-----------------------------------------------------------------------
------
The issue of who handles Bcc: header lines has again been raised, and I
am seeking opinions as widely as I can. The requirement is
straightforward: non-Bcc recipients of a message should not see the
addresses of any Bcc recipients, that is, their copies of the message
should not contain Bcc: header lines.
The dispute is over who achieves this end by removing Bcc: lines when
they should not be present. Is it the MUA or the MTA? This is what I
know about current behaviour:
1. Exim (which I maintain) removes Bcc: lines if, and only if, it is
called with the -t option. In that case, it is constructing an
envelope from the header data, and IMHO in doing so it is fulfilling
an MUA function. In all other cases it leaves Bcc: lines alone.
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).
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.
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).
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.
The RFC permits several different behaviours in connection with Bcc
recipients. For copies of the message that are sent to Bcc recipients,
the Bcc: line may be absent, or contain just the address of the single
recipient, or contain the addresses of all the Bcc recipients. For
copies sent to non-Bcc recipients, there should be no Bcc: header line.
If the MUA handles this, it is possible for it to allow any of the
alternative behaviours, as the sender of the message wishes. An MTA has
no means of distinguishing what the sender wanted. If it is to handle
the Bcc: header at all, the only choice is always to remove it. Thus,
an
MTA that always removes Bcc: header lines will frustrate the wishes of
someone who wants them included in copies to Bcc recipients. (I found
one posting on the www that complained of exactly this problem.)
Of course, it is possible for MTAs to have configuration options to
change their behaviour. (It is easy to configure Exim always to remove
Bcc: lines, for instance.) However, only clueful sysadmins who are
aware
of the issue will investigate such options. Thus, it is important for
the default behaviour to be "correct" in the sense that it is what the
RFCs and the community experts generally agree on.
So .... please vent your opinions and I will try to pull together a
summary in due course.
I am posting this separately to the three list mentioned above because
the Exim lists are subscriber-posting only, and a cross-post might
cause
problems with replies.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10(_at_)cus(_dot_)cam(_dot_)ac(_dot_)uk Cambridge, England. Phone: +44
1223 334714.
|
|