[Top] [All Lists]

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

2005-05-26 09:34:21

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


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).


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 ;)

Paul Jakma      paul(_at_)clubi(_dot_)ie        paul(_at_)jakma(_dot_)org       
Key ID: 64A2FF6A
If God had meant for us to be in the Army, we would have been born with
green, baggy skin.