On Mon October 18 2004 17:09, Keith Moore wrote:
I think there are some problems with the very notion of a
sender-settable _default_ recipient list - one that encourages the
reader to use that list for replies without thinking about it. This is
equally a problem for MFT or Reply-To, and probably for other ways of
setting that default. And while it's certainly possible to build MUAs
that don't treat MFT or Reply-To or whatever as a "default" but instead
do something else with it - let the user choose it explicitly, insist
that the user make an explicit choice, whatever
Reply-To is an author-settable suggestion for responses. Whether
or not an rMUA has a default type of response, and if so whether
or not that uses that field are separate issues. There is nothing in
the Reply-To specification that requires or encourages a default
type of response in rMUAs; in fact RFC 2822 is quite explicit in
stating that behavior of reply commands is implementation-
specific and outside of the scope of the message format
specification.
I wonder if it will
violate the sender's expectation if recipients consciously choose to
reply to somewhere else.
Given the defined semantics, the author's expectation for his
use of Reply-To should be that he has provided a suggestion;
no more.
Both MFT and Reply-To seem to expect repliers to understand, via
out-of-band information, the relationships between the specified
recipients and the other recipients of a message
[...]
They don't say _why_ the replies are being
redirected that way,
The (Reply-To) field simply provides a mechanism for authors
to provide suggestions for responses. There are in-band
mechanisms (parenthesized comments, display names, "Comments"
message header field, body text) that are also provided for
authors to indicate such additional information to (human)
recipients.
or give any guidance about what to do if the
replier wants to change the default.
Again, the concept of a "default" is an rMUA issue, not a
characteristic of a Reply-To field. Neither an author nor
his oMUA can tell what defaults might be in effect at any
single recipient's rMUA; when multiple recipients are
involved -- explicitly, via list expansion, or via forwarding
or resending -- those multiple rMUA defaults, where such
rMUAs have defaults, may well differ.
Because I'm looking at how to make email more effective, one of the
things I'm concerned about is the rarity of conscious choice when
replying to emails. So I'm wondering if there are ways that MUAs can
be improved to encourage conscious choices without being too annoying.
One rather obvious way would be to present multiple choices
equally (and correctly labeled) rather than a default (with or
without other alternatives which are less accessible). I notice
that you use Sylpheed, and it provides a way for you to
configure the toolbar (Configuration -> Other Preferences ->
Customize Toolbars -> Main Window). The default configuration,
at least in the version "0.9.1claws" that I have here, seems to
be to provide icons for three types of responses: "Reply" (which
uses Reply-To if present), "All" for a reply-to-all function, and
"Sender" (which is actually a reply-to-author, ignoring Sender
and Return-Path). Many other GUI-based rMUAs have similar
capabilities to customize toolbars (and menus).
And because I want to encourage conscious choices if it is possible to
do so (and I'm not sure that it is), I'm wary of new header fields which
seem to assume that users will not make conscious choices. I think such
fields could even discourage conscious choice, by creating a wider
expectation that the recipient will do what the sender said (thus
negative feedback if the recipient does something different even when he
had a good reason); and because, lacking information as to _why_ the
sender set MFT, the recipient might decide (again, without much
justification) that the sender's judgement is better than his own.
All good points.