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

Paul Jakma <[email protected]>
Newsgroups gmane.ietf.rfc822
Message-ID <[email protected]>
On Fri, 27 May 2005, Bruce Lilly wrote:

> On Thu May 26 2005 19:27, Paul Jakma wrote:
>
>> I think by looking at what MUAs do, one could define that context.
>
> Depending on what you look at, you may get a different impression
> (a corollary to "if the only tool that you have is a hammer, everything
> looks like a nail").

There seems to be broad consensus among MUA designers on the first 
two of these contexts (personal and public), and a slow consensus 
evolving on providing a "list reply" context for users.

There is clearly a /perceived/ need for such a context, at least.

>> The fact that already several MUAs (popular ones at that,
>> thunderbird, apple mail, and mutt) /do/ do see fit to provide a "list
>> context"
>
> I see nothing resembling that in Thunderbird.

Hmm, I must be confused then. Sorry. (It appears to be an extension). 
Kmail and Evolution MUAs definitely have it.

>> And it /does/ for mutt.
>
> Only if everybody uses that specific UA with its non-standard quirks.
> Not very realistic.

Why does it provide this quirk?

To be honest, while I'm not happy with the quirk, at least it gives a 
way to influence at least /that/ MUA. I'd just like a standard way to 
specify this preference of mine, so that there may one day be broader 
support for indicating a "copy me on list replies" preference.

>> "list context reply" should /not/ consider Reply-To, for if it did,
>> that would imply it should also consider "From", which obviously isnt
>> the idea.
>
> I don't see how you're making the leap to that conclusion; From and 
> Reply-To fields have very different semantics -- they are not 
> directly linked.

Fair enough.

>> However, see above, I do not (at the moment) think it would be right
>> to consider From/Reply-To in a "list reply" context.
>
> I see that you said so, but you offered no rationale.

Because MUAs which provide a "list reply" context do not wish to 
reply to the author directly, per default. That's the entire raison 
d'etre for this new list-reply context appearing in MUAs - because 
people in general appear to prefer to not receive direct copies.

We can get hung up on arguing how there isn't a scientific basis for 
this claim, but there is plenty of anecdotal evidence, from my 
personal experience and obviously the MUA maintainers perceive it is 
so, or they wouldn't feel a need to implement such a context.

>> Hence, Reply-To can /not/ be used.
>
> You're going to have to justify that claim.

Because the most likely reason for it being set are:

- The author's preferred 'receive' mailbox is not their From
   (ie to indicate preference for their personal mailbox)

- The author set it to direct replies to the list

The latter case is, ime, rare.

> As long as standard mechanisms are used, and implementations comply 
> with those standard mechanisms, it doesn't matter which 
> standards-conforming implementation is used.

Grand.

There is no way to achieve what is wanted though - A way to indicate 
"My preference is to be copied on list replies". List netiquette has 
evolved where people actively strip out all but list mailbox on 
replies, and further several popular MUAs offer "list reply" context 
to make even that step unnecessary.

That's all within standards. Fine.

The only thing which is missing in this changed list culture is a 
good way to indicate "I /do/ want copies of list replies".

> No, you're conflating separate things; use of Reply-To means "where 
> the author suggested" whereas use of From means "directly to the 
> author(s)".

Ok.

I don't see how that affects list context reply which, in /all/ MUAs 
implementing it, exists precisely to *not* use either of these cues.

>> - list
>>  	To: List-Post
>
> Several problems:

> 1. RFC 2369 fields are not mandatory; many lists do not use them

That's fine. "List-Post" here is meant more symbolically, as value of 
mailbox of list, derived either by explicit user configuration or 
implicitely in some fashion (eg the header by same name, if present).

> 2. Sometimes one list's expansion feeds another list, and one may
>   then have multiple sets of List-fields; one cannot in general tell
>   which list is included in another.  Sending to all directly will
>   result in duplicates in the included list.  Picking only the included
>   list (by guessing) won't copy the subscribers of the other list who
>   are not also subscribed to the included list.

That seems a problem with the definition of List-Post, and would 
affect any usage of List-Post, not just this proposed usage. Out of 
scope for what I'm proposing.

> The more serious problem is that mail doesn't have any notion of 
> "context" (other than the optional RFC 3458 field, which is 
> unrelated to your concept); it has only "recipients".  Your list of 
> proposed "contexts" ignores the type of real considerations that 
> apply to selecting recipients:
>
> o the author(s)
> o the sender
> o the reverse (delivery notification) path
> o where the author suggested
> o other recipients of the original, as indicated by the author(s) [N.B.
>  there is no guarantee that they in fact were recipients]

Fair point.

However, this conflates the information available to and suggested 
behaviour of the MUA in acting on this information, with the context 
the MUA user is presented with (which initiates the previous 
behaviour) and has chosen. The latter, the contexts the user may 
choose from, is almost uniform across MUAs, other than "list reply" 
which is restricted to a smaller subset of MUAs (though, very popular 
MUAs).

Clearly though, I need to be more careful in seperating the context 
the user initiated and the various contexts the MUA may find itself 
in. (whether carries out due to one of the few 'user contexts' or 
not).

> For example, sending a "vacation"-like response is independent of 
> any of the items you listed as "context"; such responses need to go 
> to the delivery notification path (see RFC 3834).

That wouldn't fall within the contexts I outlined.

I hadn't considered that.

> As another, not uncommon, example, consider a message posted to a 
> mailing list with a request by the author to send off-list (only) 
> responses, to be summarized by the author.  The author could easily 
> indicate that with Reply-To, and every response that is directed 
> "where the author suggested" will comply with that.  For such a 
> mailing list message, your "list context" would send a doubly wrong 
> response -- it wouldn't go directly to the author (as requested) 
> and would go to the entire list (contrary to the request).

That would be the fault of the MUA /user though, for choosing "list 
reply" context in replying, rather than "reply" context.

The MUA is but the humble servant of the user, and shouldn't be 
blamed if its user directs it wrongly.

It's no more different than the user replying using "Reply All" 
rather than "Reply" - what exactly is the MUA to do other than act on 
its user's wishes?

regards,
-- 
Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
Fortune:
Some people have a way about them that seems to say: "If I have
only one life to live, let me live it as a jerk."
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.