Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
Yes, that is a Good Question. Ideally, the Reply-To-List command should
reply to every list to which the message was sent. The problem is how
does it know this?
To beat Dan's drum for him, in a world that fully implements it,
Mail-Followup-To solves this problem.
Only if authors use MFT only for a very narrow purpose - to distinguish
lists from ordinary addresses. However, it's not the case that everyone
wants to redirect "reply to all" to go to only lists. Nor is it the
case that everyone would want to limit their use of MFT to this purpose.
Treating "reply to MFT" as equivalent to "reply to lists" would overload
MFT almost as badly as Reply-to is currently overloaded.
Right. MFT isn't meant to contain only mailing lists address. It is
intended to contain the followup address that users supply. Often
this is mailing list addresses, but viewing MFT as a header for
mailing list address is incorrect.
Generally, it seems MFT is useful in those situations where the
recipient trust the sender reasonably well to let the sender specify
the default value of where the recipient should post his followups.
In other words, if a sender has gone through to trouble of specifying
a Mail-Followup-To -- which MUST NOT be added without the user
requesting it -- then the recipient pay back with the courtesy of
following the Mail-Followup-To (by default).
In communities with co-operative people this scheme appear to work.
It takes malice (or buggy software) to add an incorrect MFT. I don't
recall seeing flame wars about people having "bad" MFTs.
That's not in itself an argument against MFT - just an argument against
the notion that MFT provides a reliable "reply to list" feature.
Right. Thinking of MFT as a "reply to list" feature is misleading.
But when you have it set
up, it works well as advertised among people who all use supporting mail
clients (even if the other person hasn't taught their own mail client
about their mailing lists, it works for the first person).
It's easy to define something that works well among a small group of
like-minded people. The challenge is to make something that will work well for
an extremely large and diverse user community. It's unwise to assume
that everyone will want to use a feature in the same way.
Well, mail doesn't work well in extremely large and diverse user
communities. Spam and virii are killing mail for that use. I don't
buy that because something isn't right for everyone, it should not be
done at all, if that was implied. If MFT help some people, and (of
course) do not harm others, it is useful. I haven't seen any
arguments that MFT is harmful, only that it might not be useful enough
or that it has bad legacy behavior. Which are much weaker arguments.
I can imagine a smart MUA that would handle this for you by using the
List-* headers.
I can imagine that also. And the first thing I imagine is that it would
have the same problem that Apple's MUA for MacOS X has. It gets its
idea of people's names from random message headers. So if someone
sends me mail with a Cc to "Big Idiot
<my(_dot_)friend(_at_)example(_dot_)com>"
then any time after that when I try to type in
"my(_dot_)friend(_at_)example(_dot_)com"
the MUA will automatically fill in "Big Idiot" for me. And so far I
haven't found a way to stop it.
No thank you. I don't want MUAs trying to infer information about
addresses from random messages. (and I don't see how else an MUA
can automatically discover which addresses are associated with lists)
How about looking at List-Post: and using those addresses as mailing
list addresses? The MUA should allow the user to override things, of
course.
Populating MFT automatically based on what is gleaned from List-Post
is just a bad idea though.
Thanks,
Simon