[Mailman-Developers] Advanced Reply-To-Munging

[Stephen J. Turnbull]

Sven Anderson writes:

 > Stephen J. Turnbull, 11.03.2007 19:34:
 > > Sven Anderson writes:
 > > 
 > >  > There is no RFC-way to set the default address for replies.
 > > 
 > > Of course there is.  For authors, it's Reply-To.  For lists, it's
 > > List-Post.
 > 
 > No, it's not. What I was referring here as the "default address" (and I
 > hoped this was clear) was the address, which is used by the normal reply
 > button/function of the MUA. There is no way to define a default adressee
 > for that function, it is always hardwired to the From header, which can be
 > overridden by a Reply-To header.

Let me note that that's false for all of the dozen or so different
(Emacs-based, so not usable for the masses, but proof of concept) MUAs
I've used over the last 15 years.

What you're missing is that the best-practice-based RFCs *presume*
your point.  *There is no way to force the recipient's MUA to do
anything.*  Therefore, the RFC headers under discussion are intended
to provide ways for *authors* and other agents (mailing lists) to
*express* their wishes.  The use of Reply-munging, and even more the
other changes you propose, subvert this expression, so that
well-designed conforming MUAs do not (and if you remove the author's
reply-to entirely, *cannot*) do what is expected by their users.

Here's a good (bad?) example:

 > That's why my proposal replaces the From by an author-set Reply-To
 > whenever it is used.

Which is again a non-conforming use of the originator headers.  From
is *not* Reply-To, it identifies the author of the message.  So you've
broken Reply-To, it no longers tells where the author wants replies
sent as it's supposed to.  Now you break From, too!  Like this:

Suppose that because I'm traveling, I set my reply-to to
careof at somewhere.net.  Then my headers will look like:

From: stephen at xemacs.org
Sender: steve at uwakimon.sk.tsukuba.ac.jp
Reply-To: careof at somewhere.net

but what you'll see is

From: careof at somewhere.net
Sender: mailman-users-bounces at python.org
Reply-To: mailman-users at python.org

That's *wrong*, it confuses both my faithful audience, and the
killfiles of those who never want to hear from me again.  Furthermore,
it identifies me as being "at" an address that is evidently temporary.

You simply can't get this right.  I really don't think attempts to do
so should be included in the Mailman distribution at this point in
time.

 > I don't get the point in referring to another software, while Mailman
 > offers 95% of what that use case needs and is installed already. All these
 > fuzzy classifications like CRM shouldn't prevent a software to cross the
 > border, if it easily can do.

I don't want to "prevent" anything.  And couldn't if I wanted to!  You
have the source, you can do what you want.  I'm saying if you want
something that violates the RFCs, use something that has no stake in
being seen to be a conformant implementation of them.

I see the use case.  But what I don't see is a body of experience to
point out best practice.  Your proposed facility will be used in
contexts you don't expect, and it *will* break, in ways that you (or
I!) cannot predict.  I don't think it's a good idea for Mailman to
accept that maintenance burden, until best practice starts to be
understood.

Also, Mailman 3 will involve substantial refactoring as I understand
it.  It will be much more friendly to such experiments.