[Mailman-Developers] Reply-To munging considered *carefully*

[Michael B. Trausch]

On Wed, 2009-10-14 at 08:41 -0400, Barry Warsaw wrote:
> On Oct 14, 2009, at 4:19 AM, Michael B. Trausch wrote:
> 
> > * MLs that require "reply all" instead, and instead of sending _one_
> >   message in threading context, send N number of messages where N is
> >   however many people are listed in various headers.
> 
> This is not a bug in mailing list software, it's a bug in the MUAs.   
> Despite, as Stephen says, *decades* of complaints such as this, very  
> few MUAs support the mailing list RFCs that have exists for at least a  
> dozen years.  Fix the MUAs first please.

As I mentioned in the post you replied to, this is impossible because
the List-* headers won't be received at all in many normal operating
circumstances.

> It's actually easy too.  An MUA need only recognize List-Post and add  
> a Reply to List button which would strip all the recipients and put  
> the List-Post value in the To header.  Problem solved.

And therein lies the rub.  There are several ways to make the system
work more deterministically overall (the list style that seems to be on
the side opposite me here is _rarely_ deterministic, though it often
kind of works).  There are means by which accidental leakage can be
avoided on lists that use the Reply-To header as I have already
suggested, while not breaking what a non-technical end-user perceives to
be expected behavior.

I'm talking about user experience as it pertains to mailing lists and
everything that there is to them.  I cannot consistently reply without
making something incorrect, nor can I consistently filter mailing list
posts, because when posts arrive without a header to filter on (as is
the case when I recieve someone's reply directly, and not from the
mailing list) the filter breaks.  Such breakage should be the exception,
not the rule.  Furthermore, such breakage cannot be fixed in a system
where there isn't a single component to be fixed.  Suggesting that this
can be done MUA-side fails to address several issues that I raised in
the post that you replied to that are programmatically impossible to
solve consistently.

I was unaware of RFC 5322's clarifications.  That does change what I
understand to be current standard a bit, but it does not change what I
think is proper behavior in terms of how users interact with mailing
lists.  While both approaches can have inconsistencies about them, there
are less of them in a system that uses reply-to with a sane default and
does things like I discussed in the parent of your reply, and if any of
the mechanisms were adopted that would virtually kill the "Oh, I posted
stuff I shouldn't have" problem.  I can think of many situations where
it'd also be beneficial---say, in a flamefest, where someone sends off a
message that they wished they could take back (impossible normally), or
accidentally press Send by accident before finishing message composition
(such as I did earlier in this thread), or in those few minutes just
after someone hits Send and goes "Oh, I _really_ oughtn't to have done
that."

It is technically possible to solve these problems.  What I don't
understand is why there seems to be a large active disinterest in doing
so.  The mechanisms I mentioned earlier would all solve those problems
for all but a very small subset of users---it'd fix the mailing list
"user interface" for more users than the current methods do.

Again, I think that _what is_ is being ignored for what is perceived to
be _what ought to be_.  I'm more interested in the practical concerns at
play.  Though, it seems that doesn't matter.  That said, if mailing list
software _did_ choose to modify/remove/replace/append to the reply-to
header (mere creation of the header is _not_ munging) it's entirely
possible that the ML software could be configured to handle such things
gracefully.  If the mailing list posts always go through the ML server,
it _is_ possible to fix nearly every imaginable use-case, but for that
to work, there would have to be some level of interest.  IMHO, it's more
important to Just Work regardless of what sort of MUA the user has than
it is to be pedantic and play the blame game.

If there is a technical solution that can be reliably implemented in an
MUA-independent fashion that doesn't depend on any of the things I
mentioned in this post's grandparent, I'd be interested in going after
it.  However, programmatically speaking, I don't see it being possible
without saying, "MUAs, these are the standards that you must adhere to,"
in a separate standards document, describing exactly what sort of
behavior is expected to make things transparent and just work, and also
sending duplicate messages such that MUA software can recognize the
duplicate and show them as a single message.  I think that trying to fix
it in the currently apparently accepted architecture, though, is
terribly much more complex than it needs to be.

What I am proposing is that depending on the MUA to be anything more
than a program to send and receive messages is fundamentally flawed, and
it doesn't fit in with the UNIX philosophy of program design.  The job
of managing the mailing list should be on the mailing list management
software, no part of it should depend on the MUA.  The MUA _should_ be
able to provide help in doing so, but everything that the MUA is capable
of doing automagically for its users should also be able to be done
without depending on the MUA for extra help, in such a way that even
very ancient MUA software that still exists out there (albeit in very
rare usage) can provide the functionality, using nothing but messages to
manage the flow of things.

Maybe what I need to do to really show what I'm talking about is to
create an implementation that does what I am talking about so that it
can be looked at and discussed?

	--- Mike

-- 
Blog:  http://mike.trausch.us/blog/
Misc. Software:  http://mike.trausch.us/software/

“The greater danger for most of us lies not in setting our aim too
high and falling short; but in setting our aim too low, and achieving
our mark.” —Michelangelo