ietf-822
[Top] [All Lists]

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.





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