On Fri, 14 Aug 1998, Alexander Koch wrote:
> Hope that helps some of you. The change was in between 0.89.x and
> 0.91.x. Whether the MTA is broken or not, I don't know.
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 don't think the MTA should
interfere with the message that the MUA gives it. The primary business
of an MTA is indicated by the T - to transport messages, not to fiddle
around with them. [In fact, I don't really like the -t option, but have
to support it for compatibility. When it is set, the MTA is performing
an MUA function, namely, constructing an envelope. It can't interrogate
users to see if they want Bcc left in for Bcc recipients, so the only
thing it can do is remove Bcc lines. I consider this to be a special
case.]
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
(a) Remove the possibility of leaving Bcc in for some recipients.
(b) Not work for messsages submitted from an MUA running on a personal
computer, unless I implemented options for listing hosts and nets for
which Bcc removal was applied. This all seems to me to be a huge amount
of effort for small gain.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
