From: Anand Buddhdev <[EMAIL PROTECTED]>
Date: Mon, 6 Mar 2000 17:59:43 +0300
. . .
There is some description of how the Bcc: field is to be handled in RFC
822, but it's very ambigious. Here's the relevant section:
4.5.3. BCC / RESENT-BCC
This field contains the identity of additional recipients of
the message. The contents of this field are not included in
copies of the message sent to the primary and secondary reci-
pients. Some systems may choose to include the text of the
"Bcc" field only in the author(s)'s copy, while others may
also include it in the text sent to all those indicated in the
"Bcc" list.
At the end of the day, Bcc: is a feature of the mail client, and the MTA
does not need to bother with it . . .
The way I read this, the MTA is enjoined *not* to bother with it.
Here's my reasoning:
1. Realistically, only the MUA can document the behavior of mail
header fields such as BCC to the user, because the MUA is the only place
where the user gets to exert control over message delivery.
2. Therefore, only the MUA can make the choice describe above.
3. So "some systems" must mean the MUAs. (Or possibly the
"injector" used by the MUA, but with the same degree of user control.)
4. Therefore, and especially since the MTA may be somewhere in the
middle of a long chain of relays from sender to recipient, the MTA
cannot arbitrary change this choice by dropping a BCC header.
This seems to be the consensus of the list -- that headers are
untouchable after "injection" -- but I wanted to point out how RFC822
supports this.
-- Bob Rogers
