Re: Private copies of list replies (Was: Re: buildd and experimental)
Glenn Maynard <glenn@zewt.org>
> On Sun, Mar 05, 2006 at 11:06:46AM +0000, MJ Ray wrote:
> > Neither? So you still didn't bother with the reference?
> >
> > The problems are cited: maybe you don't agree they are problems.
>
> 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.
> > The reasonable default behaviour is to send list replies to the
> > List-Post address, off-list replies to Reply-To||From and group
> > replies to all original recipients.
>
> This behavior fails to handle cross-posting, forcing people to use
> group-reply and then manually tweak the recipients. For those of us who
Cross-posting should be discouraged and harder than the default,
don't you think?
> pay attention, it forces us to spend undue time adjusting recipients
> when such details should be handled by the mailer. It encourages people
> to use group-reply all the time, copying everyone. MFT fixes this cleanly:
> list-reply fills in correct recipients; in the typical case, I only need
> to glance over the result to verify it.
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.
Yes, users ought to behave, but MUAs ought to support the List-*
RFCs and mutt didn't, last I checked. The world doesn't ought.
> > > and it's your job
> > > to hint my mailer if you want it to treat you atypically, such as if you
> > > want CC's on followups to Debian lists.
> >
> > It should not be my job to work around bugs in your mailer.
>
> Please don't offer replies which are so terse as to not convey a clear
> meaning. You seem to be implying that to *not* send you a copy on a list
> followup is a bug in my mailer. However, I'm pretty sure that's not
> your belief, so I have no idea what you were actually trying to say.
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.
> > No, expecting people to use broken software that implements
> > non-standard mail headers is unreasonable. In any case, explicit
> > requests are another common way, so your "only" was false.
>
> 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?
> > Thank you for agreeing that MFT does nothing to help solve one of
> > the most common problems on debian lists. I guess we'll just differ
> > on the desirability of supporting a non-standard header in the
> > listserver or hiding cc requests in headers.
>
> The fact that MFT does not solve an unrelated problem (user error in
> specifying who should receive copies of replies) is irrelevant. I
> agree, as well, that MFT does not solve world hunger.
Further, MFT exacerbates that accidental-cc problem.
> As far as I can see, you've not named any problems that would be caused
> by list software automatically creating MFT headers indicating the list's
> policy. I could hypothesize some, but they're along similar lines as list
> software that sets "Reply-To" automatically: it may override explicit uses
> of it. I'm not sure if that'd be a problem. But, I can think of no problems
> along the lines you're talking about.
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.
I've cited several problems with it, as well as correcting some
errors in the MFT advocacy. I'm sorry you seem not to have
learnt from the references, but that's not my fault.
Finally, I'm in disbelief at advocacy of munging yet another
header. lists.d.o is very well-behaved and doesn't even mangle
Subject today, unlike many. Long may that continue!
Best wishes,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: