I am in Kathmandu and will be busy teaching for the next few days, and then
offline for some more, so I shan't be contributing to this thread for a
while...
Derek,
With tongue firmly in cheek, I thought I'd start by pointing out these two
statements you made:
1.
> Sure, but see above. I don't see why that matters. Ideally, all
> parts of the mail system, from the MUA to the MDA should enforce this,
> just in case someone else along the chain got it wrong.
2.
> > But your MUA has just passed it on to those recipients!
>
> With the assumption that the MTA will handle it.
I think that #2 contradicts #1....
But that's a frivolity.
> You seem to be missing my point, so I'll state it as clearly as I know
> how:
>
> Authors of software which is intended to be used by people other
> than themselves must sometimes assume responsibilities above and
> beyond what are specified by RFCs and/or the law. These
> responsibilities come from common sense, and an assumed
> responsibility to prevent users from receiving ill as a result of
> using their software as intended.
I see that point, and I entirely agree. I don't think we are in disagreement on
principles, just on one point of detail. IF the expectation of everybody was
"no message should ever contain a Bcc:" then I would be happy for Exim always
to remove them. Trouble is, this is not the case. It it were the case, there
would be no need for the RFC even to define Bcc: would there? After all, the
RFC defines message format passing between hosts - what goes on inside a host
is not within its remit. There are, therefore, legitimate cases where Bcc: can
exist.
Now, perhaps I have not moved with the times. Perhaps these days Bcc: is
obsolete and I haven't noticed (nobody has told me) that all other software is
removing Bcc: as a matter of course. If that is true, I have no case. But I am
not yet convinced: I have what you have told me, but virtually no comments from
anybody else. That is why I suggested raising the issue elsewhere.
I tried googling, but found very little (but I did find one complaint that an
MTA had removed a legitimate Bcc from a message :-)
> 3. The MTA is in a position to detect the situation where recipients
> who have not been Bcc'd will see the Bcc line.
The ONLY possible attitudes are "always remove Bcc" or "never remove Bcc"
(excluding the -t case). Trying to fiddle with individual recpients is a mug's
game (= rathole). Consider:
To: A@domain1
Bcc: B@domain2
This message is on its way to B@domain2, with Bcc intact. At some point,
B@domain2 is redirected (aliased, forwarded) to C@domain3. Should the Bcc now
be removed by the MTA?
> I did some tests with sendmail today where I generated messages from a) my
> mailer, b) =66rom the sendmail command line, and c) by telnetting directly to
> a sendmail server and typing in SMTP commands and messages manually. In all
> cases, it stripped the Bcc header from the message. I even included a
> received: header to attempt to see if this would make a difference... It
> didn't.
Thank you for doing that. So at least that version of Sendmail just strips.
> 6.3.1. Built-in Header Semantics
> [SNIP]
> H_STRIPVAL Strip the value from the header (for
> Bcc:).
So it is optional; that suggests there are different views in the world.
> > I do not consider "always remove any Bcc lines from any message" to be
> > good enough.
>
> Well, that seems to be precisely what sendmail does. So you'll have
> to figure out for yourself what you consider "good enough."
I think I've changed my mind on that. Amazing what a long plane flight can
do...
> A user who has been Bcc'd should see that THEY have been Bcc'd, but no one
> else should. That is, each Bcc'd recipient should receive a copy of the
> message, with a Bcc line that includes only their address on the Bcc line.
It has just been pointed out to me that few MUAs ever display Bcc lines anyway.
People probably just assume they have been Bcc'd. Which, I agree, is an
argument for stripping it.
> So what if it does? The MTA will deliver it to the mailing list host,
> and the MDA will deliver it to the subscribers of the mailing list.
> The message will contain a Bcc line showing the mailing list address,
> and all the recipients will receive a copy that shows it. What's the
> problem here? The Bcc line still shows the desired information, which
> is how the user came to receive a copy of the e-mail.
Right. But now it is a "second level" effect. The Bcc no longer shows the
individual's email address. This is the start of the rathole, and is why I
think there are only two choices. Sounds like the Sendmail folk came to the
same conclusion.
> Exim is the only MTA which I have been able to specifically identify as not
> doing anything with Bcc lines,
... by default. It is easy enough to configure it always to remove them.
> I will post more general comments on Bugtraq.
I am not subscribed to Bugtraq, but would of course be interested in hearing
what views arise (in fact, I'll probably be told by friends/colleagues who do
watch Bugtraq if anything about Exim is posted there).
> My apologies for using the wrong list... I'm not an Exim user, and
> I'm not interested in how one uses Exim, per se; my concern is the
> design of the program itself. The dev list seemed to be the right
> place to discuss changes to the behavior of the program, but I could
> find only vague references to the dev list on the exim home page when
> I looked, so it wasn't clear. Actually signing up for the dev list
> wasn't so easy... I guess that's by design.
The dev list is very new (only a few months old), set up because we are in the
throes of moving to a more open development system. I am sorry that you had
difficulty in getting access. I will write a document (not for several weeks)
and ask on exim-users, but that is a VERY busy list; I would not advise an
outsider to subscribe!
> I suggest a Bcc-Action: header, with the following possible values:
Quite honestly, I wouldn't bother trying to get new header lines determined and
codified, unless you have a lot of time and a huge amount of staying power.
Nice idea, but I fear it is a non-starter, but this is just my cynical point of
view.
> Well, I'm done here...
Me too, but I would like to get this discussed by other people. Just the two of
us arguing is all very well, but would not want to contemplate a major
incompatible change of specification without hearing other views. I may raise
this elsewhere when I get back.
> But thanks for your time discussing it with me, it helped me to solidify a
> lot of thoughts about the issues.
It has had the same effect on me! Thanks for your time.
Regards,
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
