Re: Private copies of list replies (Was: Re: buildd and experimental)
On Mon, Mar 06, 2006 at 09:35:36AM +0000, MJ Ray wrote:
> > I read them, and they seem to say "it's not an annointed standard" (not
> > relevant) and "it's a header, put it in the body instead" (which is
> > naming a poor alternative, not naming a problem with MFT).
>
> Sorry, I still think you seem not to have
> followed the references. There are reasons why
> draft-ietf-drums-mail-followup-to-00.txt wasn't accepted. I
> will not present them again here, because we are already a bit
> tangential. The bottom line is that MFT is not good enough.
I read the messages at the links you provided. They provided no insight
into why you don't like MFT; your (rather insulting) assertion that I
must not have read it doesn't change that. The closest I can guess is
that there's some strange notion in both of those posts that MFT is
supposed to be handled by the user, manually, which is not the case; the
repeated "it's hidden by default!" complaints are irrelevant.
> Cross-posting should be discouraged and harder than the default,
> don't you think?
No, cross-posting should not be made artificially difficult and harder
to do correctly. Don't make *me* spend extra time messing with headers
every time I want to reply to someone else's cross-posted thread.
> You called my description of the encourages-dumb-automation
> argument silly, yet here you seem to call on it. Users often
> won't check MFT, as shown by lists that munge Reply-To getting
> accidental public replies, so there's scope for much mischief.
I expect my mailer to fill in reasonable headers automatically. That's
not dumb automation; that's basic functionality--it's my mailer's *job*
to do that for me. I never check MFT myself; that's up to my mailer. I
do glance over the resulting To/CC: headers, to make sure nothing strange
has happened; it *is* my job to verify the results--but it's certainly
not my job to copy a dozen recipient addresses around on a complex cross-
post, when things are behaving properly.
> Terseness is a function of time available to write the reply. The
> (IMO obvious) implication was that it is not my job to set MFT
> just because your mailer implements it.
>
> In other words: you are wrong that it's my job to hint to your mailer,
> if that means guessing how it implements which non-standard headers.
It is your job to set MFT if you want my mailer to treat you differently
than everyone else, such as if you want to receive CCs on list posts.
If you don't, and instead just say "CC me on replies" in the message,
you're pushing the work to handle your exceptional case onto everyone else
on the list, which is unacceptable. That's why, as I said, I only comply
with such requests once, to point people to MFT (at least, unless I really
want to talk to that person).
(Of course, I have no problem with doing both--setting the header and
asking for it in English for those whose mailers don't support it.)
> > Nobody is "expected" to use software that supports the header. If you
> > don't, you're still expected to follow list policy and you'll have to
> > continue doing it in other ways, but you're no worse off for the presence
> > of the header.
>
> Clearly, we are. There are repeated threads where arrogant users
> of non-standard MUAs flame others for not following MFT. Does
> this get better or worse if there are more MFTs around?
There are repeated threads on Debian lists for people not following list
policy. That's sometimes phrased in terms of MFT, but I've never seen a
"you didn't CC me even though my MFT said to" flamewar, only the inverse;
and I've never seen one at all on a non-Debian list.
> Further, MFT exacerbates that accidental-cc problem.
Setting a CC that shouldn't be there is saying "copy this person on
followups" when they don't want copies. That's an error.
Not retaining CC lists on followup is usually an error, at least on Debian
lists; you're probably dropping people from the discussion.
These two errors, when they happen simultaneously, cancel each other out.
Your argument is that since MFT reduces the probability of the second
error, it reduces the chance of the two errors cancelling out, so it
"exacerbates" the first; and therefore MFT is bad. I hope you can see
my problem with that rationale ...
> What possible automated values would you set in MFT which
> would include only mailing lists? The only ways I can see that
> lists.debian.org could add your preferred MFT when none was sent
> are to either build an index of all mailing list addresses or
> to probe -request addresses. If it was only to include the list
> forwarding the request, it would just be a List-Post duplicate.
My original suggestion was that it include all addresses in the To: and Cc:
headers, except for those which are subscribed to the list.
That's imperfect, as I acknowledged from the beginning, but it does seem
like an improvement. (Of course, I suggested it with the hope that others
might be able to refine it.)
--
Glenn Maynard
Reply to: