On Thu May 26 2005 09:35, Paul Jakma wrote:
I'm interested in solving the problem of a new reply context, "list
reply", which many MUAs offer now, for which context there is no good
way for originators to indicate a preference of "copy me directly on
replies".
AFAICT, all MUAs implementing such reply contexts default to "email
the list", where the list mailbox is either statically configured or
else deduced from the post-822 List-* headers. All these MUAs
(afaict), ignore reply-to in this context, some will allow themselves
by influenced by a non-standard Mail-Followup-To header.
There are several largely separate but intertwined issues:
1. What a message originator wishes to indicate as a preference
2. Where a respondent wishes to direct responses, which may be
different from #1
3. What capabilities are present in a particular MUA
4. How MUA capabilities are labeled and what they actually do
5. What specific list management software does to a message's content
when processing a list message
6. How specific list management software processes delivery of list
messages for particular list recipients
The standard way to handle #1 is via the Reply-To field. Sometimes
that's screwed up by #5, sometimes particular UAs screw it up (#3,4)
A respondent can choose where to send responses, and he might choose to
ignore or override the original message originators expressed preference.
if any. Obviously, if a respondent chooses a "send only to list"
response option (if supported by #3, #4), that's where the response
will go, regardless of the original message originator's preference.
If a particular MUA doesn't provide an option to honor the original
message originator's expressed preference (#3,4) a respondent is left
with some other response choice (#2). Some MUAs support non-standard
fields; most do not. Given the fact that some MUAs do not support
standard functionality, an assumption that all MUAs support non-standard
fields would be ill-advised.
There is no standard for labeling or functionality of MUA implementation
response options (#4), and the IETF doesn't generally attempt to impose
such restrictions on implementations. There might be some use for a
glossary of terms and/or a non-binding informational "white paper" for
MUA developers, but ultimately, MUA developers will do what they want
in this area (and some MUAs would change very slowly, if ever, even if
there were a "white paper" making specific recommendations). Any
assumption on the part of a message originator about the features or
capabilities of recipients' MUAs is likely to fail for some subset of
recipients.
Some list expanders screw up originators' expressed preferences; that
is discouraged, and most lists don't do that.
Some lists have per-subscriber options (#6) to suppress list messages
sent to that subscriber if the subscriber's mailbox is listed verbatim
in a message To or Cc field. Obviously, a subscriber who wants both
list and individual message copies can't set that type of option.
Slightly less obvious is the fact that a list subscriber who is known
to have such an option set can be prevented from seeing a message
(maliciously or otherwise) by including that subscriber's mailbox in
the To or Cc message header fields (those fields of course have nothing
to do with actual message delivery).
That's the problem statement I'm concerned with, no more :).
It sounds like you're starting from #1, but are getting hung up on
issues associated with #2-#4. About the best you can do is to indicate
your preference with a standard mechanism, and hope that that will be
honored by respondents who are able to do so. You might try
supplementing that with non-standard fields, but as you have already
found out, those fields are not widely noticed and result in different
behavior with different implementations which do notice them. They
can also interact badly with the standard mechanism, defeating your
intent.
What I really want is a List-Copies-To type header...
List-Copies-To: paul(_at_)jakma(_dot_)org
The List- convention is usually used for fields related to mailing lists
and added by list expanders. You might want to choose a different name
to avoid stepping on that convention.
Which MTAs should retain in replies.
MTAs play no direct role in responses; perhaps you mean MUAs?
Which would clearly indicate my
preference to be copied on list replies. That would allow my problem
with how "list reply" context works in several recent MTA
implementations to be solved.
And what happens if a respondent wants a different set of preferences
for responses to *his* message? Should he change the field? Or not?
If not, then how would he indicate his preferences? What about 3rd
generation responses, etc.? When a discussion veers off track, as
many do, how do you propose stopping the copies (or don't you care?)?
How many decades are you willing to wait for widespread deployment of
your proposal (some people still use /bin/mail)?