Keith Moore wrote:
Okay, I dug out the "reply problem list" I had written as part of the
DRUMS discussions, and edited it slightly.
I've tried to define these problems in terms of observed behavior[...]
Many of these problems are very similar to one another[...]
I have listed them as separate problems because some proposed
solutions will solve one problem while failing to solve a similar one.
By listing so many separate problems, I don't mean to imply that they're
all of equal severity.
I separated the original list into two sections. List A consists of the
problems that aren't related to lists munging Reply-To.[...]
My reason for compiling this is to help clarify arguments of the form
"proposal X doesn't solve problem Y". It appears that any solution to
the _set_ of problems is likely to involve several changes: perhaps a
new header field or two, along with (perhaps) recommendations to MUA
authors about their user interfaces, modifications to various kinds of
software, and maybe some user education. With this list we can compare
various _sets_ of solutions to this _set_ of problems.
My comments below are from the perspective of what is available to
message authors and respondents using only standard (RFC 822/2822)
message header fields, with widely-available MUAs. Consequently,
to the extent that the comments represent any sort of a solution
at all, that solution falls primarily into the "some user education"
category, with a smidgen of "recommendations to MUA authors". The
comments specifically do not advocate adding new header fields or
modifications to any specific software or class of software.
As noted, the basis of the discussion of this list is that authors'
header fields (especially Reply-To) are not modified by mailing list
software.
List A: REPLY problems not involving modification of message headers by
mailing lists:
A1. Given the vast number of MUAs that implement a "reply all" command
where the Reply-To address only replaces the From address from the
original message, there's no good way for the author of a message to say
"please reply only to these addresses", or (almost equivalently) "please
don't reply to these addresses". The author can use Bcc for all
recipients who should not receive the reply, but that doesn't inform the
"non blind" recipients that the other recipients were also sent copies
of the message.
If the author sets Reply-To to the list of desired response recipient
addresses, leaving out the To and Cc fields (or setting them to empty
groups) and specifying original message recipients via Bcc (which is my
understanding of the first sentence plus the first clause of the second
sentence), then there aren't any "'non-blind' recipients". The Comments
field could be used to indicate the Bcc recipients, who would not receive
responses (without explicit action by a sender). For that matter, a note
could be placed in the message body (presumably for the benefit of users
afflicted with user-hostile MUAs that make it difficult to see message
headers). As for the authors of such user-hostile MUAs, I would recommend
a one-way trip to beautiful Guantanamo Bay (advice to such authors would
likely fall on deaf ears).
A2. If a message contains a Reply-To field, but the person composing the
reply isn't aware that Reply-To is being used, the reply may go to
somewhere besides where the reply author thought it should go. The
result may be surprising or embarrassing (as when a personal reply gets
sent to a list), or the reply author may think he has sent the message
to a list when it has really only gone to one particular recipient.
Caveat sender. Most MUAs display the recipients. I can't say that I
know of any that do not. If there are any, then caveat emptor.
A3. A few MUAs implement only one kind of reply -- which uses Reply-To
if present and From otherwise. Users of such MUAs have difficulty
participating in group discussions on mailing lists (unless the list
mungs Reply-To).
Caveat emptor. There are plenty of MUAs that do not have that
limitation, many of them available at no cost and for a variety of
platforms (e.g. Mozilla, pine). Senders could manually ("manually"
including mechanisms as simple as cut-and-paste) include other
recipients on responses -- unless the MUA is so featureless as to
prevent even that. Such an MUA is likely to be a problem under any
"set of solutions".
A4. If a message is sent to a mailing list, and someone does a "reply
all" to that message, the author often gets two copies - one sent to the
From address and another sent to the list address (which presumably
appeared in the To or Cc field of the subject message).
If the author does not wish to receive a separate (duplicate)
response, he can set Reply-To to the mailing list address (as
is the case with this message).
A5. If a user is subscribed to multiple mailing lists, and a message is
sent to more than one of those mailing lists, the user will get multiple
copies of the message. This might not be so bad, but the same user will
also get duplicate copies of the message every time someone does "reply
to all" to the original messages or any of the replies to that message.
Again, the author can set Reply-To to one or more of the mailing list
addresses. There may still be multiple copies sent to recipient who
subscribe to multiple lists, but as you say, that's not so bad.
A6. On many MUAs, if the sender specified Reply-To, the recipient is
stuck with that - he cannot easily edit it to reply to From or
From+To+CC (especially if he cannot see the original headers while he's
editing the reply recipient list). The author of the reply thus
sometimes has difficulty sending the reply to where it needs to go.
"Stuck" would be appropriate if the MUA provides no ability to edit
the recipient list; I would be amazed if that's the case with any
MUA that is actually in any appreciable use. That there may be
some minor difficulty in directing a response to a place other than
that indicated by the original author via Reply-To is hardly
surprising -- that is as it should be.
A7. If someone responds to a list message and CCs themselves in the
response, everyone who does a "reply all" to that message will also Cc
that person...even if he's on one of the lists. Alternatively, if
multiple recipients (often lists) get CCed on a message, every "reply
all" goes to all of those recipients, even if the discussion topic
wanders and it's no longer appropriate for many of those recipients.
Self-copies can be sent via Bcc or saved as a local file copy to
avoid the first situation. Continuing copies via reply-to-all is
an inherent characteristic of Internet mail -- there is no easy
and reliable way for a message recipient to "opt-out" of receiving
some message(s); if there were, spam wouldn't be a problem. There
have been proposals that might offer a communications system that
does not have that characteristic, but they either introduce serious
problems in their own right or are a fundamentally different type of
system. In the specific case of multiple lists, see discussion of
A10 below; a responsible author should be able to resolve the
situation.
A8. Many people have multiple mailboxes, or regularly send mail from
some account at which they don't want to receive mail. If they use
Reply-To to point to their preferred mailbox, it will prevent some
recipients from doing "reply to all". Also, since there's no indication
as to why the author used Reply-To (it could be "please don't mail to me
at my From address" or it could be "please tell my secretary, not me,
whether you'll be at the meeting"), it's easy for a reply to go to the
wrong place.
"Prevent" is too strong; there may be some inconvenience. Many MUAs
provide the ability to set the From field appropriately, in which case
there is no need to use Reply-To for the stated purpose.
A9. Mailing list subscribers who don't understand the reply functions of
their UA or who have UAs with severely limited reply functions often
send replies to the author of the message when they should go to the
list. This causes discussions on the list to suffer and perhaps die out.
Again, setting Reply-To to point to the list will result in replies
going to the list, whether individual respondents use reply or
reply-to-all. If the original message author wishes responses to go
to the list, he should set Reply-To to the list address.
A10. Mailing list subscribers who don't understand the reply functions
of their UA, often send replies to the mailing list when they should go
to the author of the message. This causes prolonged discussions on a
list on which such discussions are inappropriate.
If the original author detects that condition and is responsible, he
will most likely send a message requesting that the discussion be
continued off-list (and he will probably set Reply-To appropriately;
moreover if he wishes to copy the list on that message, he will
probably use Bcc rather than To or Cc so as to prevent reply-to-all
responses from going to the list).
Summary, including some limited discussion of recent proposals:
A1 could possibly be helped by addition of a Cc-noreply (or similar)
field to indicate recipients who should not receive responses. But
that won't work for the user-hostile MUAs, which brings us back to
a note in the message body (to the extent that authors wish to
cater to users of user-hostile MUAs...). A2 seems to be solvable
by user education, along with advice to MUA authors if there are
any that seem to have missed the boat on display of recipients.
Ditto for A3. A4, A5, and A9 seem to be easily handled by appropriate
use of Reply-To -- again probably primarily a user-education issue.
A6 seems to be a description of intended operation rather than a
problem. Part of A7 can be handled via Bcc or local file copies;
the remaining issue is unlikely to be solved without a fundamental
mail system redesign or without introducing a "cure" that is worse
than the symptoms. A8 seems to be solvable via advice to MUA
authors. A10 is another user-education issue.
It appears that user-education and MUA author education may be
warranted, and would solve nearly all of these problems without any
changes to message format or the mail system. The one difficult
issue is the "opt-out" part of A7 in the absence of a responsible
party who is willing and able to redirect future responses.