Keld Jørn Simonsen wrote:
On Wed, Sep 29, 2004 at 05:14:45PM +0100, Philip Hazel wrote:
Er, you wrote this: "it is presumptuous to assume ... that the recipient
reads the list traffic in the same way that he reads other traffic."
My point is that it is equally presumptious to assume the opposite.
Quite. Guessing tends to result in failed expectations.
I think it is clear that there are several netiquettes here, and it
seems like some people are very opiniated on this. I am administrating a
number of email lists, and just yesterday one participant left one list
because I do not employ reply-to headers for the list, and another
stopped working because receiving two copies of responses to his mail
was destroying his work happiness (it annoyed him tremendously).
I think the appropriate question is "what steps did those message
authors take to clearly indicate their desires?".
I think we need some guidance on how to handle lists. That is, some best
practice RFC or some RFC on which headers to employ and how.
This should include
1. various scenarios of email list usage:
closed, open with whitelist and moderator, open with moderator, open with
a news gateway, and more. Different header use may apply to differnt usages.
Other than List-* fields, I'm not convinced that list-specific usage
would change (obviously, an authors indicated preference that responses
be directed to a (closed) list will affect any non-list recipients, but
that is specific to the recipient(s) rather than the list per se).
2. different scenarios of user behaviour and perferences,
some prefer to have two copies, some prefer to have just one copy.
Some may want to sort it in folders, other have just one big inbox,
others have a separate inbox that they do not want list mail in.
We cannot do everything, but a number of common scenarios should be
investigated.
Filtering (into folders, etc.) pretty much has to be handled at or
near the receiving end, though an author can have some influence (e.g.
use of a local-part hack which aids filtering of responses). Clearly
presumptions on the part of authors in the absence of any clear
indication of preferences doesn't work; different authors have
different preferences, and in the absence of any indication of
author preference, respondents may make different guesses about
authors' preferences. Therefore it is in everybody's interest for
an author to clearly and explicitly state his preferences. That can
be done with standard message header fields, with no change to long-
established syntax or semantics, and without requiring any wholesale
modifications to UAs or MTAs. I've gone through this analysis many
years ago (and nothing recent has changed the essential facts); I'll
examine these scenarios in detail below.
3. recommendations to MUA handling
which commands to offer in the MUA: sender-reply, group-reply,
reply to list, maybe reply to everybody except sender .
Tony had some suggestions about limiting the number of choices to
two or three; I think there ought to be at least two provided by an
MUA, viz. a "narrow" response to the original message author(s) and
a response to the original message author-indicated response
preference. Beyond those, some sort of catch-all which can be edited
to suit the respondent's purpose is probably useful, and I see no
reason (other than confusing the ignorant) why an MUA shouldn't
provide other options if its software author feels there is a need
(respond to Sender, respond to envelope sender mailbox, respond based
on List-* fields, respond to a preconfigured set of addresses, etc.).
Maybe a recommendation to MUAs on how to handle duplicate mail, maybe
they should only show one instance of it.
That should include security issues (e.g. if message-ids are used to
detect duplicates, and message-id sequences can be predicted, a
miscreant can hide legitimate traffic).
How folders may be handled
with the new functionality we propose. There could be both
considerations for sending MUAs and receiving MUAs.
Probably getting too deep into user preferences, possibly based on
a model that is not universally supported by UAs and message stores.
4. recommendations for list exploders
Which headers to set for each different list type, maybe some per-user
settings of preferences.
That would depend on the model used for list expansion/explosion.
RFCs 821/2821 speak of Alias vs. List. There are also individual
message remailers vs. digests, etc. A list expander that sends
individual messages should not alter message address fields; the
envelope sender address should be set to the list maintainer so
that automatic responses (non-delivery notices, etc.) go to the
list maintainer.
Back to how an author can indicate response preferences and how that
can assist respondents; I'll use shorthand rather than full mailbox or
address syntax -- it should be understood that all standard fields
conform to standard syntax unless explicitly noted otherwise:
Scenario 1:
As Nate Leon said:
On the contrary, I consider it careless if you copy me directly on your
reply to my posting, unless I explicitly request that you do so in the
posting.
Explicitly requesting copies:
From: F
To: T
Cc: C
List-Post: L
Reply-To: L, F
A respondent using what has been described as a "middle" response would
send responses to the author (F) and a list (L). A respondent who wishes
instead to communicate with the author only could use a "narrow" response
to F. A respondent who explicitly wished to include others could use a
broader type of response (implementation-dependent as noted in RFC 2822,
and probably involving some hand-editing).
Scenario 2:
Discouraging duplicates:
From: F
To: T
Cc: C
List-Post: P
Reply-To: L
Middle response goes to the list (the author may be "on" list L, may
prefer to peruse that list via a web archive, or may be directing
responses to a different list from the one that his original message
is being sent to). Narrow and broad responses as above, if/when desired.
Scenario 3:
Explicitly requesting responses to the author alone:
From: F
To: T
Cc: C
List-Post: L
Reply-To: F
Narrow and middle responses go to F alone. Broad responses are still
possible if/when desired by a respondent.
Scenario 4:
Delegation:
From: F
To: T
Cc: C
Reply-To: C
Middle responses go to C, per the authors request. A narrow response is
still possible if/when desired by a respondent, as are broad responses.
Scenario 5:
Author wants responses filtered:
From: F+foo
To: T
Cc: C
List-Post: L
[Reply-To: F+foo, L
or Reply-To: F+foo
or Reply-To: L
or Reply-To: C
depending on preferences]
Note that several response preferences are accommodated in accordance
with earlier scenarios. Filtering is really an orthogonal issue.
Scenario 6:
Author gives no indication of response preference. This is where
presumptions come into play, and cause all sorts of problems:
From: F
To: T
Cc: C
List-Post: L
Blurfl-Farkle-Grimble: BFG
A narrow or middle response would go to F alone. That is not usually
what is desired on a mailing list. Therefore for the typical case,
where a response should at minimum be sent to the list, neither the
narrow or middle type of response available to a recipient is
suitable. A broad response will typically include F, T, and C; a
respondent cannot tell whether any individuals' mailboxes therein are
included in any list expansions which might take place if any of those
mailboxes are list expanders, and respondents certainly cannot determine
whether any of those individuals do or do not want individual copies.
In short, the original message author is being uncooperative with his
recipients (including any lists). A non-standard field such as
Blurfl-Farkle-Grimble is unlikely to have any meaning to a significant
fraction of recipients or their UAs, whether or not the original author
thinks otherwise. The original message author's uncooperative behavior
is clearly a problem for recipients (who are forced into playing guessing
games, who are unlikely to be able to use either a narrow or middle
type of response) and may be a problem for the original message author
if he finds that the inevitable broad responses result in him receiving
unwanted duplicate copies. It may also be a problem for other (To and Cc)
recipients of the original (uncooperative) author's message; they too are
likely to receive copies of the (necessarily broad) responses, regardless
of their individual preferences; the uncooperative author has forced a
shotgun response, and there may well be collateral damage.
Note that in all of the scenarios where the author has indicated a
preference that no change to any response protocols is required, no new
message header fields are required, syntax and semantics of existing
fields is unchanged, no MTA changes are required, and no new MUA
functionality is required or precluded. In most cases, To and Cc
fields can be ignored except where a broad response is explicitly
desired, as is also the case for List-* fields (i.e. it matters not
whether list expanders insert List-* fields).
Which brings me to a final point: the failure of authors to indicate
preferences for responses (scenario 6) essentially forces broad
responses, which in turn tends to result in propagation of To and
Cc addresses for a long time, particularly in cases where large
numbers of list participants fail to indicate preferences. It
tends to happen regardless of whether those authors want or do not
want individual copies of list messages. It is a direct result of
failure to indicate preferences, resulting the the frequently
observed case in this discussion that respondents tend to be forced
into using "reply-all" (i.e. a broad response). That can be avoided,
and *is* avoided when authors indicate their preferences, allowing
respondents to use a "middle" response. Consider the following
series of messages:
From: A
To: L
List-Post: L
Reply-To: L
A middle response goes to the list only, in accordance with the authors'
indicated preference. Note that with standard response protocols
(habitual?) broad responses also go to the list only. Such a response:
From: B
To: L
List-Post: L
Reply-To: B, L
Here B has indicated a preference for a copy. A middle response does
what the author requests, as does a broad response as above. Four
examples:
From: C
To: B, L
List-Post: L
Reply-To: L
From: D
To: B, L
List-Post: L
Reply-To: D, L
From: E
To: B, L
List-Post: L
Reply-To: B, L
From: F
To: B, L
List-Post: L
Reply-To: F, B, L
The first two of those three are similar to the two cases above. In
the third and fourth, E and F have indicated that responses should
go to B and to the list (hopefully because B explicitly requested
that he be copied on further correspondence; this requires explicit
action on the part of subsequent respondents); F clearly also wants
to receive copies of responses to his (F's) message.
Note again that List-* fields are not required, no changes to MTAs,
MUAs, syntax, semantics, or protocols. All that is involved is the
common courtesy of clearly and explicitly informing others of one's
preferences (instead of forcing them to play guessing games, then
jumping down their throats if they guess "incorrectly"). Also as
above, either middle or broad responses can be used; however there
is now a difference in the case of responses to messages authored
by C and D regarding whether or not B is also copied. As neither C
nor D indicated that responses should be copied to B, middle
responses do not directly reach B. However, a respondent who recalls
B's explicit request to be copied can use a broad response to include
B. It is the case that there is no current mechanism to keep B on
subsequent response preference lists; that is a feature, not a bug.
This works quite well (and unsurprisingly, once one analyzes the
scenarios); when correspondents provide explicit response preference
indication, either a middle or broad response works in typically
encountered cases, the unusual case of a request to keep somebody
involved in copies is handled by broad responses on later messages
but can be accommodated by manual action to facilitate inclusion in
middle responses to subsequent messages.