On Sun, Jul 25, 2004 at 11:30:18AM +0100, Philip Hazel wrote:
> 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.
For those who may have taken this seriously, I need to point out that
there is no contradiction here. The first was said in the context of
what SHOULD BE, whereas the second was said in the context of what NOW
IS.
> 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.
We seem to be going in circles... ;-) I've alread addressed this
comment directly. Removing all Bcc lines is not what I'm advocating,
and in fact not desireable. I think we agree on that point, also (but
differ on the resulting conclusion).
> 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:
I don't see that at all, and I think you're making much more out of it
to try to make it seem infeasable. It just isn't.
> 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?
No, absolutely not. The desired peice of information is and always
was what address was originally included on the Bcc line, so that the
recipient can see by way of what address they have received the mail.
This is, however, an example of why a new header, such as the one I
proposed, would be needed. Otherwise since the Bcc line doesn't match
the envelope, the MTA will not know to leave the Bcc line intact.
Perhaps just adding it as a parameter to the bcc field would suffice.
But probably equally difficult to get people to adopt... Sigh.
> Thank you for doing that. So at least that version of Sendmail just strips.
While I haven't specifically tested every single version I've used,
this has been my experience at least as long as I've been a Mutt user
(because mutt writes the Bcc line by default, and I haven't told it
not to, but I've never had a problem). That would be since about 1998
or so? I think Sendmail 8.9.something was what was current at that
time...
> > 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.
Well, it is optional in the same sense that if your mailer doesn't
have a feature you want, you have the "option" to hack the code to add
it... ;-)
This is not a configuration option; if you don't want this behavior,
you must edit the source code and recompile. Macros exist to make it
easy, but I still wouldn't call it optional in the normal sense of the
word.
> > > 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.
Mine does. ;-) Except that it never has the chance to, because my MTA
unfortunately removes them all. To be honest, before I started using
Mutt, I often told my MUA to display full headers. But that was
before it was common to see 3 pages of headers for everything from
spam detection to annoying MS-Windows users... These days, I'm quite
happy that Mutt let's me see only the headers I'm interested in.
Anyway, the point is that most mailers will let you see it, if you
want to. Some people want to look. In my .muttrc, I have directives
to color messages with a Bcc line in bright red in the message index,
so that I know to be careful about replying to them. Unfortunately,
since Sendmail strips the Bcc line... Well, you get the picture.
But if you manually add a Bcc line to a message in a folder, it does
show up in red! :)
> People probably just assume they have been Bcc'd.
> Which, I agree, is an argument for stripping it.
Agree with who? I don't support that idea at all... [Well, I guess I
do a little; it's better than leaving them intact when delivering to
non-Bcc recipients.]
> > 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).
Why I most likely will do, maybe next weekend, is write up a short
paper on what I percieve to be the problems as they now exist, and
post a summary with a link on Bugtraq. I'll Bcc you when I do so. No
one will know except us though, since Sendmail will strip the Bcc line
from the message. ;-)
> 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.
No worries, I found it. :)
> I will write a document (not for several weeks) and ask on
> exim-users,
As it happens, I have a short (forced, basically useless) vacation at
the end of this week. I'd intended to travel, but didn't have time to
plan anything (except maybe a day trip to Hyundae Beach in Busan), so
I'll probably have plenty of time to do it then. Perhaps you can just
pass mine along...
> > 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 too am cynical, and that has been a concern of mine all along.
However I'm also idealistic... Not a very happy combination. ;-)
> > 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.
Cheers.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
