Re: mail-followup-to / mail-copies-to

Hi Bruce,

On Thu, 26 May 2005, Bruce Lilly wrote:

> There are several largely separate but intertwined issues:
> 1. What a message originator wishes to indicate as a preference
Right.

You indicated previously 'reply-to' should be used, however it has 
problems (and is ignored completely in the "list context" reply mode 
of some MUAs - where the non-standard MFT is not).
> 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.
Right, but it most definitely has problems. (It's not fine-grained 
enough to distinguish between public and private replies).
> 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.
Send to list sends only to list because there is no good way for the 
originator what their preference is on list-replies. The majority of 
people today prefer not to receive a direct copy - this leaves the 
minority of people who /do/ want a direct copy high and dry.
> 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.
What MUAs do and dont do is not directly in the hands of the 
standards, but we can learn from it as to whether there is a need for 
further standard specification, and if so what.
"list reply" functionality in MUAs has come into existence, IMHO, 
because of weaknesses in the standards. And unfortunately has 
degraded functionality (for a minority of odd-balls who subscribe to 
/lots/ of lists, but degraded none the less).
> 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.
Sure. I agree.

There is nothing one can do about problems in existing 
implementations.
However there is no hope of influencing future implementations to do 
'the right thing' without some attempt to standardise what this 
'right thing' is. (To be specific, this "right thing" for me 
currently is a way to allow me to specify my unusual preference to be 
included in list replies).
> 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.
Yes. Unfortunately, this doesn't solve my problem as more and more 
MUAs implement 'list reply' functionality, and do not reply to 
originator.
> 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).
Right.

> It sounds like you're starting from #1, but are getting hung up on 
> issues associated with #2-#4.
Yes, #1 is my only concern.

I very much wish to avoid getting stuck in #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.
That would be ideal.

I'm not concerned about current implementations. My concern is that 
in X years time there still will be no standard way of indicating 
this preference (once a standard exists, MUA implementors can be 
asked to implement it, and maybe one day majority of implementations 
will support it).
> 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.
Indeed, I'm not at all happy with my MFT. But it's only way to deal 
with Mutt (it adversely affects users of other MUAs, which implement 
MFT strictly according to DJB spec, ability to reply to me and list - 
but those MUAs are /tiny/ group compared to mutt users)
> 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.
Ok. It can't be 'Mail-Copies-To' unfortunately, because it's already 
in use in (i think) NNTP, can it?
> > Which MTAs should retain in replies.
> MTAs play no direct role in responses; perhaps you mean MUAs?
Urr, yes :)

> > 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?
The header can be additive, surely? As References are.

> Should he change the field?  Or not? If not, then how would he 
> indicate his preferences?  What about 3rd generation responses, 
> etc.?
Any user who would be like to be included in a discussion can simply 
add their mailbox to the header (or mailbox of any other party they 
think may be interested).
> When a discussion veers off track, as many do, how do you propose 
> stopping the copies (or don't you care?)?
You wouldn't be able to, without replying and removing your mailbox 
from the header and asking respondents to ensure same in other 
further replies of that thread. Same deal as with giant Cc lists 
really, but less of a problem because the "copy me" person took a 
/positive/ step to try influence others to copy them directly. They 
*want* to be copied. Other than that it's a netiquette problem.
Does that sound reasonable? (And should this supercede existing 
ad-hoc definition of Mail-Copies-To, or should that header name be 
used?). If so, I'll download xml2rfc..
> How many decades are you willing to wait for widespread deployment 
> of your proposal (some people still use /bin/mail)?
Try help a standard be formulated to address this problem and 
accepted, then wait a decade for implementors (possibly gently poking 
them), I can do.
Sit around for another decade doing nothing and just *wishing* 
someone else would try push for a "copy me please" header to be 
standardised and implemented, I can't any longer ;)
regards,
--
Paul Jakma      paul(_at_)clubi(_dot_)ie        paul(_at_)jakma(_dot_)org       
Key ID: 64A2FF6A
Fortune:
If God had meant for us to be in the Army, we would have been born with
green, baggy skin.