On Thu, Jul 22, 2004 at 10:54:02AM +0100, Philip Hazel wrote:
> I argue that Exim is not broken, because of this paragraph in RFC 822:
>
> 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.
>
> I interpret that as giving the user (via the MUA) the option of leaving
> in the Bcc or not for certain recipients.
I should have addressed this more thoroughly, rather than just
dismissing it out of hand, because it actually strenthens my case.
This RFC, just like 2822, also states that "The contents of this field
are not included in copies of the message sent to the primary and
secondary recipients." This is the part that Exim ignores, and this
is why it is broken.
The additional processing that I'm suggesting does not take away the
user's capability of "leaving in the Bcc or not for certain
recipients." It only ensures that those who clearly aren't meant to
receive it don't.
> Of course, like a number of other things, if the implementors of the
> MUAs don't see the world in the same light, I could implement an option
> always to remove Bcc lines in messages submitted locally. This would
This is not at all what I have suggested, and in fact I have stated
several times that I think this is the wrong approach.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
