Laird Breyer wrote:
I do accept that the possibility is there, but am yet to be convinced that
it happens so frequently to render inadequate the default behaviour of
sending list responses to the address that was subscribed.
What exactly is that supposed to mean? Responses go wherever the
respondent sends them.
Is it not true that in this scenario, the author still depends on the
cooperation of any respondents to honour his specification, rather
than reply to the list regardless?
You mean recommendation, not specification. A respondent always
has the prerogative to send responses wherever he pleases.
For example, I use Mutt, and have a
key for list replies and a key for ordinary replies. When I press the former,
my reply always goes to the list, I believe.
I have no idea what version of mutt you're using; the version I've
seen (1.5.6i) has a group reply function and a reply function. I
believe that you may be mistaken in your beliefs.
If such cooperation is required now for your example, then the same
would be true with an "intelligent" list. Namely: if I want
respondents to not reply through the list, I must communicate the
requirement to their MUA and I still depend on them to follow my
wishes. Or am I missing something?
You're missing something fundamental. List expanders don't work
that way. Any proposal for a solution to the issue of communicating
authors' response preferences that is dependent upon replacing all
mailing list software is a non-starter.
Or he might copy one list on a message of potential interest to that
list based on the topic of a discussion taking place on a different
list, with responses directed to the list on which the discussion is
taking place.
Why would the members of the copied list follow this recommendation
and respond on the primary discussion list?
Because that's where the discussion is.
I understand that is
probably desirable, but what mechanism will actually enforce this
behaviour now?
There is no enforcement of recommendations. That's why they're
recommendations and not absolute requirements.
Is it Cc: ?
No, the standard place for an author to indicate response
recommendations is the standard Reply-To field. The Cc field has
nothing to do with response recommendations.
Also, this may be my inexperience with mailing list issues talking, but
I don't see anything wrong with each list treating non-member addresses
uniformly according to its nonmember rules (chosen by each list
administrator).
If such hypothetical rules for such a hypothetical piece of list
software included sending multiple unsolicited messages to a
non-member, that non-member would probably (and justifiably)
regard that list software's operator as a spammer.
But I think this discussion is becoming very technical, and I'm getting lost.
Can you perhaps recommend some review document which describes mailing list
problems and various historical solutions, if there is one?
Start with RFC 1958 for the Internet Architecture, then RFCs 821
and 2821 which describe list expansion. See RFCs 2369 and 2919
for list-specific message header fields. RFC 3834 regarding
automatic responses. See RFC 3117 for some advice regarding
application protocols. Some historical information exists in
RFC 1429. RFC 1211 deals with administrative issues.
This makes no sense to me. On the one hand, you seem to oppose mail
propagation decisions by mailing lists because they may differ from
what the author wants, but on the other you fully accept the
prerogative of respondents to do as they please.
mailing list software != human respondents
If the prospective respondent makes a configuration choice directly
with the mailing list, and empowers it to alter the propagation of
received messages destined for himself, surely that's his prerogative?
Fine, but that affects what he receives from the list, not what he
sends to wherever he sends it to. In particular, it does nothing
to address communicating his recommendations for responses to messages
that he authors.