Re: Private copies of list replies (Was: Re: buildd and experimental)
On Thu, Mar 02, 2006 at 10:12:58AM +0000, MJ Ray wrote:
> Glenn Maynard <glenn@zewt.org> [...]
> > Just as a thought, I wonder if it's possible for the list software to
> > automatically add an MFT header, if it's missing, indicating that only
> > people not subscribed to the list, or explicitly in the CC list, should
> > be CC'd. [...]
>
> I'm sure it's possible, but I think encouraging that broken
> non-standard header is a bad idea. It is not that hard for
> people to control their mail clients correctly IMO.
You say "broken header" without explaining why, as if this is common
knowledge, but I've never heard of any problems with it; you're the
only person I've ever heard call it "broken".
It's currently the only common way for a sender to express his preference:
"copy me on followups" or "don't copy me on followups". Without it,
it's impossible for people to "control their mail clients correctly"
so people who want copies get them and people who don't want copies
don't get them, unless they manually track individuals (unreasonable).
> Also, the above behaviour would encourage many people to jump
> through hoops to follow the list code of conduct as soon as
> only one person fails and puts someone in the CC unwanted.
When I reply to a mail to a list with a CC to a third party, I maintain
that CC (unless I specifically know that the person is on the list).
Those CC's are usually to people not on the list, and *should* be
preserved. This wouldn't change if MFT was added automatically.
It's even worse with complex cross-posting, where several lists and several
individuals are being copied. Neither list-reply nor group-reply does the
right thing: list-reply will only copy known lists and the MFT (typically
losing people), and group-reply will mail everyone (even those who don't
want a copy, such as the sender of the mail being replied to). This
encourages people to use group-reply (which is closer to correct).
Anyway, I'm all for caution when trying to do anything "smart" to headers,
since these things can get complicated and break things in unexpected
ways. It just seems like things could be improved a bit. When you have
an unusual policy, and lots of people break it because it's unusual, then
the problem may not lie *entirely* in the user ...
--
Glenn Maynard
Reply to: