Re: Understanding response protocols

> > > So please answer me. HOW is the mail expander for 'foo' supposed to 
> > > know
> > > about the totally separate mailing list 'bar' to which the author
> > > crossposted his message. And if it does not know about 'bar', how 
> > > can it
> > > possibly arrange for replies to be crossposted to both lists (by
> > > appropriate setting of Reply-To/MFT/whatever)?
> > It can't.  But that's also mostly irrelevant, for several reasons.
> > 1.  The vast majority of senders are not going to want to configure 
> > their
> > MUAs to know about mailing lists.  (and if you say that they should be
> > automatically configured, be sure you understand the security 
> > implications)
> The vast majority of senders do not regularly use mailing lists. But 
> those
> who do regularly use them (of which the subscribers to this list are
> probably typical) would surely be happy to configure their MUAs,
> especially if this would get rid of difficulties they were 
> experiencing.
Not clear.  I know a lot of list subscribers who are not sophisticated 
mail users, and who are intimidated by suggestions that they make even 
slight configuration changes to their MUAs.
I don't agree that the subscribers to this list are typical.  This list 
consists of people who have a specific interest in email.  Most of us 
are probably far more technically adept than the typical list 
subscriber.  To the extent that we are intimidated by user agent 
configuration options, it's probably because they don't use the same 
terms as the RFCs.
> > 2.  ... it's not clear what should happen when replying to multiple 
> > lists,
> > and there is a conflict between the lists' policies.
> In that case, only the author is in a position to define a policy for 
> for
> that particular communication (and hopefully for the ensuing thread).
I'd argue that this is the case for all replies.  Original authors can 
have preferences, lists can have policies, but the person composing the 
reply is the ultimate decision maker.
> > 3.  Blind acceptance of MFT when composing replies is a bad idea,
> > for the same reasons that blind acceptance of Reply-To is a bad idea.
> Nobody is proposing "blind" acceptance. By all means let there be 
> alerts
> and warnings in RED; but most recipients will be happy to follow the
> author's (or the list maintainer's) recommendation.
Actually some people are proposing blind acceptance.  They want MFT to 
be honored automagically, regardless of the content of the reply.
> > 4.  MFT doesn't fix the problem of duplicated messages anyway.
> If by "duplicated messages" you mean unwanted personal replies in 
> addition
> to replies sent to the list, then MFT does indeed solve it.
The duplicated message problem is broader than that.  And no, MFT 
doesn't solve even that subset of the problem - at least, not without 
creating other problems.
> > > Now, supposing some author wants to raise a matter which is likely 
> > > to be
> > > relevant to both ietf-822(_at_)imc(_dot_)org and 
> > > IMAP(_at_)CAC(_dot_)Washington(_dot_)EDU(_dot_) So he
> > > cross-posts to both lists, and ideally he would like all respondents 
> > > on
> > > both lists to reply to both lists. How can this be brought about?
> > a) have both list addresses appear in To or CC of the original message
> > b) recipients use "reply all" to reply to both lists.
> No, that is the current situation, and is the cause of the mess we are 
> in.
It's also the only way for the replier to respond if he wants to ensure 
that all recipients of the subject message receive the reply. The 
replier should not assume that honoring MFT will produce the same 
result.
> > What I suspect you really want is to do this without having reply
> > authors see duplicate messages.  The only way to solve that problem
> > is to have recipients' MUAs or message stores do duplicate detection.
> No, MFT applied by the author can solve it. The problem with expecting
> MUAs or message stores to solve it is that some users may have several
> MUAs and several message stores and several layers of filtering to 
> handle
> their incoming mail.
Yup, it's a problem.  But MFT has several problems also.  If an author 
has multiple MUAs he needs to configure each of them to be aware of 
MFT.
(note that _most_ users probably do not have several MUAs and several 
message stores and especially several layers of filtering on their 
incoming mail.  the more sophisticated users who do have such setups 
are probably capable of adapting to message stores or MUAs that can 
handle duplicates.)
> Moreover, direct replies and replies via the list
> tend to arrive by different routes and at different times. Much 
> simpler to
> avoid sending the duplicates in the first place.
It's simpler in some sense.  But it makes repliers responsible for 
fixing a problem that is on the sender's end.  It hides the fact that 
the replier intended for certain recipients to receive a copy of the 
message.  It makes it difficult for a replier to know whether the 
recipients omitted by MFT will actually receive that message.  If MFT 
is blindly trusted, it (and reply-to) are potentially useful to a 
message forger in seeing that the owner of the forged address do not 
receive replies to the forgery.  If MFT is not blindly trusted, it 
won't result the ease of use that its proponents desire.  (there may be 
some middle ground).
Keith