Subject: Re: reply etiquette
From: Laird Breyer <[email-masked]>
To: ietf-822 list <[email-masked]>
Date: Fri, 1 Oct 2004 12:13:03 +1000
List-Id: <ietf-822.imc.org>

On Sep 29 2004, Keith Moore wrote:

> it's very simple.  if  you reply in a public forum to a message that 
> someone sent, it's common courtesy to send the author of the original 
> message a copy of the reply.
> 
> for a variety of reasons, merely sending the message to the public 
> forum is not sufficient, unless the author has explicitly indicated 
> that this is sufficient.

I'm not sure if this was discussed in the big reply-to thread of the
past few weeks, but it seems to me that what you're asking for is
properly the mailing list software's job.

Individual list members are in no position to predict the preferences
of other list members, but the mailing list knows who's who, and 
can accept (or should accept, I think) preferences as easily as the normal
subscribe/unsubscribe commands.

Here's how a mailing list server could behave to accomodate everybody
(I don't know if some servers do this, but I would not be surprised) 

-----

>From the point of view of a subscribed list member, the server should
offer a command to select preferences such as:

1) for general incoming list messages, whether to trim extraneous
mailboxes from the various destination fields, keeping only the list
address. That would prevent MUAs from replying to any other address
but the list address, making one type of courtesy automatic.

2) for incoming list messages, whether to send a second copy to a second
address as well if the message is a direct reply to something that the
list member posted. That would make the other type of courtesy automatic.

-----

>From the point of view of a non-member of the list, who just wants to
send a single message without subscribing, the list server can have the
following default behaviour:

1) if a new list message is a direct reply to the non-member's email, it
should be forwarded to his address, possibly with instructions on
how to disable this feature if he wishes.

-----

The great advantage of keeping this functionality in the mailing list server
is that there is no need to change MUAs or people's behaviour. A mailing list
server should be able to emulate by proxy any well defined reply policy,
individually for each user of the list, whether member or non-member.

A member could choose preferences, while a non-member would get defaults
which simulate one-to-one email conversations.

Just my two cents. Flame away ;-)

-- 
Laird Breyer.

Date: Thu, 30 Sep 2004 10:44:12 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 list <[email-masked]>
Organization: Bruce Lilly
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <[email-masked]>
CC: ietf-822 list <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

Keld Jørn Simonsen wrote:
> On Wed, Sep 29, 2004 at 05:14:45PM +0100, Philip Hazel wrote:
> 
>>Er, you wrote this: "it is presumptuous to assume ... that the recipient
>>reads the list traffic in the same way that he reads other traffic."
>>
>>My point is that it is equally presumptious to assume the opposite.

Quite. Guessing tends to result in failed expectations.

> I think it is clear that there are several netiquettes here, and it
> seems like some people are very opiniated on this. I am administrating a
> number of email lists, and just yesterday one participant left one list
> because I do not employ reply-to headers for the list, and another
> stopped working because receiving two copies of responses to his mail
> was destroying his work happiness (it annoyed him tremendously).

I think the appropriate question is "what steps did those message
authors take to clearly indicate their desires?".

> I think we need some guidance on how to handle lists. That is, some best
> practice RFC or some RFC on which headers to employ and how.
> This should include
> 
> 1. various scenarios of email list usage:
> closed, open with whitelist and moderator, open with moderator, open with
> a news gateway, and more.  Different header use may apply to differnt usages.

Other than List-* fields, I'm not convinced that list-specific usage
would change (obviously, an authors indicated preference that responses
be directed to a (closed) list will affect any non-list recipients, but
that is specific to the recipient(s) rather than the list per se).

> 2. different scenarios of user behaviour and perferences, 
> some prefer to have two copies, some prefer to have just one copy.
> Some may want to  sort it in folders, other have just one big inbox,
> others have a separate inbox that they do not want list mail in.
> We cannot do everything, but a number of common scenarios should be
> investigated.

Filtering (into folders, etc.) pretty much has to be handled at or
near the receiving end, though an author can have some influence (e.g.
use of a local-part hack which aids filtering of responses). Clearly
presumptions on the part of authors in the absence of any clear
indication of preferences doesn't work; different authors have
different preferences, and in the absence of any indication of
author preference, respondents may make different guesses about
authors' preferences.  Therefore it is in everybody's interest for
an author to clearly and explicitly state his preferences.  That can
be done with standard message header fields, with no change to long-
established syntax or semantics, and without requiring any wholesale
modifications to UAs or MTAs.  I've gone through this analysis many
years ago (and nothing recent has changed the essential facts); I'll
examine these scenarios in detail below.

> 3. recommendations to MUA handling
> which commands to offer in the MUA: sender-reply, group-reply, 
> reply to list, maybe reply to everybody except sender . 

Tony had some suggestions about limiting the number of choices to
two or three; I think there ought to be at least two provided by an
MUA, viz. a "narrow" response to the original message author(s) and
a response to the original message author-indicated response
preference. Beyond those, some sort of catch-all which can be edited
to suit the respondent's purpose is probably useful, and I see no
reason (other than confusing the ignorant) why an MUA shouldn't
provide other options if its software author feels there is a need
(respond to Sender, respond to envelope sender mailbox, respond based
on List-* fields, respond to a preconfigured set of addresses, etc.).

> Maybe a recommendation to MUAs on how to handle duplicate mail, maybe
> they should only show one instance of it.

That should include security issues (e.g. if message-ids are used to
detect duplicates, and message-id sequences can be predicted, a
miscreant can hide legitimate traffic).

> How folders may be handled
> with the new functionality we propose.  There could be both
> considerations for sending MUAs and receiving MUAs.

Probably getting too deep into user preferences, possibly based on
a model that is not universally supported by UAs and message stores.

> 4. recommendations for list exploders
> Which headers to set for each different list type, maybe some per-user
> settings of preferences.

That would depend on the model used for list expansion/explosion.
RFCs 821/2821 speak of Alias vs. List. There are also individual
message remailers vs. digests, etc.   A list expander that sends
individual messages should not alter message address fields; the
envelope sender address should be set to the list maintainer so
that automatic responses (non-delivery notices, etc.) go to the
list maintainer.

Back to how an author can indicate response preferences and how that
can assist respondents; I'll use shorthand rather than full mailbox or
address syntax -- it should be understood that all standard fields
conform to standard syntax unless explicitly noted otherwise:

Scenario 1:

As Nate Leon said:

> On the contrary, I consider it careless if you copy me directly on your
> reply to my posting, unless I explicitly request that you do so in the
> posting.

Explicitly requesting copies:

From: F
To: T
Cc: C
List-Post: L
Reply-To: L, F

A respondent using what has been described as a "middle" response would
send responses to the author (F) and a list (L).  A respondent who wishes
instead to communicate with the author only could use a "narrow" response
to F. A respondent who explicitly wished to include others could use a
broader type of response (implementation-dependent as noted in RFC 2822,
and probably involving some hand-editing).

Scenario 2:

Discouraging duplicates:

From: F
To: T
Cc: C
List-Post: P
Reply-To: L

Middle response goes to the list (the author may be "on" list L, may
prefer to peruse that list via a web archive, or may be directing
responses to a different list from the one that his original message
is being sent to). Narrow and broad responses as above, if/when desired.

Scenario 3:

Explicitly requesting responses to the author alone:

From: F
To: T
Cc: C
List-Post: L
Reply-To: F

Narrow and middle responses go to F alone. Broad responses are still
possible if/when desired by a respondent.

Scenario 4:

Delegation:

From: F
To: T
Cc: C
Reply-To: C

Middle responses go to C, per the authors request. A narrow response is
still possible if/when desired by a respondent, as are broad responses.

Scenario 5:

Author wants responses filtered:

From: F+foo
To: T
Cc: C
List-Post: L
[Reply-To: F+foo, L
or Reply-To: F+foo
or Reply-To: L
or Reply-To: C
depending on preferences]

Note that several response preferences are accommodated in accordance
with earlier scenarios.  Filtering is really an orthogonal issue.

Scenario 6:

Author gives no indication of response preference.  This is where
presumptions come into play, and cause all sorts of problems:

From: F
To: T
Cc: C
List-Post: L
Blurfl-Farkle-Grimble: BFG

A narrow or middle response would go to F alone.  That is not usually
what is desired on a mailing list.  Therefore for the typical case,
where a response should at minimum be sent to the list, neither the
narrow or middle type of response available to a recipient is
suitable.  A broad response will typically include F, T, and C; a
respondent cannot tell whether any individuals' mailboxes therein are
included in any list expansions which might take place if any of those
mailboxes are list expanders, and respondents certainly cannot determine
whether any of those individuals do or do not want individual copies.
In short, the original message author is being uncooperative with his
recipients (including any lists).  A non-standard field such as
Blurfl-Farkle-Grimble is unlikely to have any meaning to a significant
fraction of recipients or their UAs, whether or not the original author
thinks otherwise.  The original message author's uncooperative behavior
is clearly a problem for recipients (who are forced into playing guessing
games, who are unlikely to be able to use either a narrow or middle
type of response) and may be a problem for the original message author
if he finds that the inevitable broad responses result in him receiving
unwanted duplicate copies.  It may also be a problem for other (To and Cc)
recipients of the original (uncooperative) author's message; they too are
likely to receive copies of the (necessarily broad) responses, regardless
of their individual preferences; the uncooperative author has forced a
shotgun response, and there may well be collateral damage.

Note that in all of the scenarios where the author has indicated a
preference that no change to any response protocols is required, no new
message header fields are required, syntax and semantics of existing
fields is unchanged, no MTA changes are required, and no new MUA
functionality is required or precluded.  In most cases, To and Cc
fields can be ignored except where a broad response is explicitly
desired, as is also the case for List-* fields (i.e. it matters not
whether list expanders insert List-* fields).

Which brings me to a final point: the failure of authors to indicate
preferences for responses (scenario 6) essentially forces broad
responses, which in turn tends to result in propagation of To and
Cc addresses for a long time, particularly in cases where large
numbers of list participants fail to indicate preferences.  It
tends to happen regardless of whether those authors want or do not
want individual copies of list messages. It is a direct result of
failure to indicate preferences, resulting the the frequently
observed case in this discussion that respondents tend to be forced
into using "reply-all" (i.e. a broad response).  That can be avoided,
and *is* avoided when authors indicate their preferences, allowing
respondents to use a "middle" response. Consider the following
series of messages:

From: A
To: L
List-Post: L
Reply-To: L

A middle response goes to the list only, in accordance with the authors'
indicated preference. Note that with standard response protocols
(habitual?) broad responses also go to the list only. Such a response:

From: B
To: L
List-Post: L
Reply-To: B, L

Here B has indicated a preference for a copy. A middle response does
what the author requests, as does a broad response as above. Four
examples:

From: C
To: B, L
List-Post: L
Reply-To: L

From: D
To: B, L
List-Post: L
Reply-To: D, L

From: E
To: B, L
List-Post: L
Reply-To: B, L

From: F
To: B, L
List-Post: L
Reply-To: F, B, L

The first two of those three are similar to the two cases above. In
the third and fourth, E and F have indicated that responses should
go to B and to the list (hopefully because B explicitly requested
that he be copied on further correspondence; this requires explicit
action on the part of subsequent respondents); F clearly also wants
to receive copies of responses to his (F's) message.

Note again that List-* fields are not required, no changes to MTAs,
MUAs, syntax, semantics, or protocols.  All that is involved is the
common courtesy of clearly and explicitly informing others of one's
preferences (instead of forcing them to play guessing games, then
jumping down their throats if they guess "incorrectly").  Also as
above, either middle or broad responses can be used; however there
is now a difference in the case of responses to messages authored
by C and D regarding whether or not B is also copied. As neither C
nor D indicated that responses should be copied to B, middle
responses do not directly reach B. However, a respondent who recalls
B's explicit request to be copied can use a broad response to include
B.  It is the case that there is no current mechanism to keep B on
subsequent response preference lists; that is a feature, not a bug.

This works quite well (and unsurprisingly, once one analyzes the
scenarios); when correspondents provide explicit response preference
indication, either a middle or broad response works in typically
encountered cases, the unusual case of a request to keep somebody
involved in copies is handled by broad responses on later messages
but can be accommodated by manual action to facilitate inclusion in
middle responses to subsequent messages.

Date: Thu, 30 Sep 2004 08:38:54 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> I'll bet it's a virus/spam filter. It's an ISP, so perhaps Spam
> Assassin? If any of you have SA handy, please test it.

I have SpamAssassin. but only use its exit code, since it is known
to badly mangle messages (for a start, it changes CRLF to LF in
the message header but not in the message body).

I don't think that ISP does spam/virus checking on outbound mail.
More likely it may be some authentication program run in
conjunction with Exim:

X-Info: This message was accepted for relay by
	smtp04.mrf.mail.rcn.net as the sender used SMTP authentication
X-Trace: P8Lg2xNl/q5fDAUYodEzlZwpyKDB79TknFKxJu+Prj0=

Now that was on a test message sent from me to me, which is certainly
not "for relay", but that's another chapter in the long sad story of
how some software authors and administrators fail to understand
certain key concepts.

Those fields were inserted between a Received field inserted by
smtp04.mrf.mail.rcn.net (Exim 3.35) and one inserted by
mx02.mrf.mail.rcn.net (also Exim 3.35).  In the case of the
original list message under discussion, the equivalent fields
appear between Received fields inserted by smtp02.mrf.mail.rcn.net
and a list mailbox' MX host, above.proper.com, which seems to be
running sendmail.

Date: Thu, 30 Sep 2004 08:22:44 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: 822 <[email-masked]>
Subject: Re: Angle brackets surrounding Content-ID
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
> 
> 
>>Charles Lindsey wrote:
>>
>>>No, I don't think that is right. An id-right, as defined by RFC 2822[...]
> 
> 
>>You have missed the critically important fact that in all cases
>>discussed, the relevant RFCs refer to RFC 822 (a full Standard),
>>not RFC 2822 (a Proposed Standard). And RFC 822 defines the
>>identifiers in question as containing a local-part and a domain.
> 
> 
> It is the clear intention that RFC 2822 is to supersede RFC 822, and that
> all standards that referred to RFC 822 are to be interpreted, so far as is
> possible, in the light of RFC 2822.

No, on all counts. RFC 2822 itself does not supersede RFC 822; at the
earliest, the successor of its successor might be a full Standard which
would supersede RFC 822.  Standards that specifically refer to RFC 822
must be interpreted in terms of RFC 822; EBNF differs from ABNF, etc.

>>RFC 2822 id-right is a problem because it changes the semantics.
> 
> 
> Good! It is an improvement.

Replacing clear, long-standing, well-understood semantics with
something which is not clearly specified, is a marked change, and
has undefined semantics is not an improvement.

> Have you heard of any cases where this change has caused a problem?

I have mentioned specific issues where RFC 2822 causes problems.

Date: Thu, 30 Sep 2004 08:07:22 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: reply etiquette
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Don't google. Tell me: Is [email-masked] a list or not?

One cannot tell from the name alone.  If you insist on a guess,
I'd guess that it probably expands to at least one list, since
both KDE and FreeBSD are open source projects with multiple
participants.  It is also possible that it is a single mailbox
accessed by one or more handlers who review messages, assign
tracking numbers in a database, and forward the message (possibly
to a list) for resolution.

Date: Thu, 30 Sep 2004 17:06:01 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Paul Smith <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: reply etiquette
Sender: [email-masked]

On Thu, 30 Sep 2004, Paul Smith wrote:

> Both of your examples are OK, but to stop the other (more likely..) examples
> you'd want to restrict people posting to the list by requiring them to
> subscribe first 

Oh, I entirely agree! I was just pointing out that there are some valid 
examples in principle.

> Also, in your examples, the person sending the message specifically did not
> want the discussion about his message to go back to him - otherwise he'd
> probably have subscribed.

Agreed again.

> If I sent a message to a mailing list (with the same sort of nature as the
> ietf-822 one), without subscribing first, I'd *expect* to have my email
> bounced with a message telling me I couldn't send a message without
> subscribing, and telling me how to subscribe if I wanted to.

The Exim list is like that, except that the message is moderated, and 
allowed through if it is reasonable (and the sender is told what is 
happening).

> I'd be suspicious of people throwing in messages without wanting to know
> about the ensuing discussion - they could be trolling, they could be giving
> false information etc etc.

Agreed again.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Thu, 30 Sep 2004 15:58:23 +0100
To: Philip Hazel <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: reply etiquette
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

At 14:15 30/09/2004, Philip Hazel wrote:
>On Thu, 30 Sep 2004, Paul Smith wrote:
>
> > I can't think of any logical, legitimate, reason why anyone would want 
> to post
> > to [email-masked]' unless they were a member of the list -
>
>"I haven't got time to participate, but you guys might like to think
>about and discuss this issue that I have come across."
>
>"Someone told me that you guys are discussing an issue that would
>benefit from some statistical information about <something>. Here's a
>reference to some work I did that might be what you want."

Or 'get your viagra here', 'my uncle died in an alien attack in Nigeria, 
please take lots of money from me', or 'look at these pictures I found', or 
even 'linux is better than Windows because...', etc...

Both of your examples are OK, but to stop the other (more likely..) 
examples you'd want to restrict people posting to the list by requiring 
them to subscribe first (or moderating the list), UNLESS your list is 
specifically for people to send to who aren't subscribed (bug lists etc).

Also, in your examples, the person sending the message specifically did not 
want the discussion about his message to go back to him - otherwise he'd 
probably have subscribed.

If I sent a message to a mailing list (with the same sort of nature as the 
ietf-822 one), without subscribing first, I'd *expect* to have my email 
bounced with a message telling me I couldn't send a message without 
subscribing, and telling me how to subscribe if I wanted to. In this sort 
of list I'd be suspicious of people throwing in messages without wanting to 
know about the ensuing discussion - they could be trolling, they could be 
giving false information etc etc.

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 30 Sep 2004 16:28:39 +0100
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

At 13:26 30/09/2004, Arnt Gulbrandsen wrote:

>Paul Smith writes:
>>If the bug reports went to a distribution list of developers, then I'd 
>>expect the *developers* to know that in *that particular instance* they 
>>should send replies back to the original sender. A bug report list is NOT 
>>the same as a mailing list discussing email protocols, it's quite different.
>
>Could you elaborate on the differences, particularly as regards reply-to, 
>mail-followup-to, group replies etc?

The difference is 'cultural' rather than technical (as I tried to indicate 
by stressing that the developers would know what to do). If I was on a bug 
report mailing list which accepted messages from a non-member, I'd KNOW (or 
be expected to know) that messages reporting a new bug are likely to be 
from a non-member. So, I could act accordingly  (eg Reply-To-All to send a 
message to the list and reporter, or Reply to send a message to the list only)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 30 Sep 2004 16:55:38 +0200
From: Martin Trautmann <[email-masked]>
To: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
Cc: Philip Hazel <[email-masked]>, Keith Moore <[email-masked]>, Tony Hansen <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

On 2004-09-29 22:54, Keld Jørn Simonsen wrote:
> 3. recommendations to MUA handling
> which commands to offer in the MUA: sender-reply, group-reply, 
> reply to list, maybe reply to everybody except sender . 
> Maybe a recommendation to MUAs on how to handle duplicate mail, maybe
> they should only show one instance of it. How folders may be handled
> with the new functionality we propose.  There could be both
> considerations for sending MUAs and receiving MUAs.

Some MUA don't forward a copy to a recipient who is within To/Cc.

Is this reasonable or should it be a user's option?

Regards
Martin

Date: Thu, 30 Sep 2004 16:51:53 +0200
From: Martin Trautmann <[email-masked]>
To: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: reply etiquette
Sender: [email-masked]

On 2004-09-30 13:01, Keld Jørn Simonsen wrote:
> I agree with Arnt that in a number of cases it is really proper that
> some submitters are not subscribed to the mailing list they send to.
> 
> Examples are:
> 1. bug report lists and customer services addresses - such as mentioned 
>    by Arnt
> 2. committee group lists, such as the list for a board in an
>    association, where eg members can submit requests to the board.
> 3. joint discussion between two or more groups.

4. some mail providers require from = user account

Thus I read mail from my common account, but as soon as I want to send
some message from home, I have to use SMTP after POP which does require
the POP user account to be used as From, while I set a 'Reply-To' in order
to receive the message again.

Thus I can't send messages from home to a list that accepts subscribed
members only.

Technically, this would require  e.g. a list server that could be
programmed to handle 'aliases' (secondary adresses).

Regards
Martin

Date: Thu, 30 Sep 2004 14:15:50 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Paul Smith <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: reply etiquette
Sender: [email-masked]

On Thu, 30 Sep 2004, Paul Smith wrote:

> I can't think of any logical, legitimate, reason why anyone would want to post
> to [email-masked]' unless they were a member of the list - 

"I haven't got time to participate, but you guys might like to think 
about and discuss this issue that I have come across."

"Someone told me that you guys are discussing an issue that would 
benefit from some statistical information about <something>. Here's a
reference to some work I did that might be what you want."

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Thu, 30 Sep 2004 14:26:04 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: reply etiquette
Cc: Paul Smith <[email-masked]>
Sender: [email-masked]

Paul Smith writes:
> If the bug reports went to a distribution list of developers, then I'd 
> expect the *developers* to know that in *that particular instance* 
> they should send replies back to the original sender. A bug report 
> list is NOT the same as a mailing list discussing email protocols, 
> it's quite different.

Could you elaborate on the differences, particularly as regards 
reply-to, mail-followup-to, group replies etc? I'd also be interested 
in your thoughts on Keld's three examples.

(During 2004 I have personally been in all three examples Keld mentions, 
so IMO they're quite realistic.)

Arnt

Date: Thu, 30 Sep 2004 12:15:00 +0100
To: Arnt Gulbrandsen <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: reply etiquette
Cc: [email-masked]
Sender: [email-masked]

At 11:10 30/09/2004, you wrote:

>Paul Smith writes:
>>If the list was set up properly, you would have received a message from 
>>the list saying that you need to subscribe to the list in order to post 
>>to it - otherwise you're inviting spammers in!
>
>It would be _proper_ to invite bug reports to an address, reject the first 
>message from bug reporters to that address, and require every reporter to 
>subscribe to a (potentially busy) mailing list? Do you really mean that?

It wouldn't be proper to invite bug reports to a mailing list...

If the bug reports went to a distribution list of developers, then I'd 
expect the *developers* to know that in *that particular instance* they 
should send replies back to the original sender. A bug report list is NOT 
the same as a mailing list discussing email protocols, it's quite different.

(FWIW, this is one of the main reasons I prefer 'closed' mailing lists to 
have the reply-to header changed to the list email address, then a simple 
'reply' will always go to the appropriate person - in the case of the bug 
report list (if it was a list), then the reply-to header would not have 
been changed, so the 'reply' would go to the original author. If the people 
running a closed mailing list want 'reply-to-all' to go back to the 
original author as well, they could change the 'reply-to' to go to the 
list, and make a 'cc' for the original author))

I can't think of any logical, legitimate, reason why anyone would want to 
post to [email-masked]' unless they were a member of the list - that'd 
be like shouting across a room and interrupting someone else's 
conversation, then running away.
Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 30 Sep 2004 13:01:55 +0200
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: reply etiquette
Sender: [email-masked]

On Thu, Sep 30, 2004 at 12:10:11PM +0200, Arnt Gulbrandsen wrote:
> 
> Paul Smith writes:
> >If the list was set up properly, you would have received a message 
> >from the list saying that you need to subscribe to the list in order 
> >to post to it - otherwise you're inviting spammers in!
> 
> It would be _proper_ to invite bug reports to an address, reject the 
> first message from bug reporters to that address, and require every 
> reporter to subscribe to a (potentially busy) mailing list? Do you 
> really mean that?

I agree with Arnt that in a number of cases it is really proper that
some submitters are not subscribed to the mailing list they send to.

Examples are:
1. bug report lists and customer services addresses - such as mentioned 
   by Arnt
2. committee group lists, such as the list for a board in an
   association, where eg members can submit requests to the board.
3. joint discussion between two or more groups.

Best regards
keld

Date: Thu, 30 Sep 2004 12:10:11 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: reply etiquette
Sender: [email-masked]

Paul Smith writes:
> If the list was set up properly, you would have received a message 
> from the list saying that you need to subscribe to the list in order 
> to post to it - otherwise you're inviting spammers in!

It would be _proper_ to invite bug reports to an address, reject the 
first message from bug reporters to that address, and require every 
reporter to subscribe to a (potentially busy) mailing list? Do you 
really mean that?

Arnt

Date: Thu, 30 Sep 2004 09:26:06 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: reply etiquette
Sender: [email-masked]

On Wed, 29 Sep 2004, Russ Allbery wrote:

> I think this thread is a wonderful example of why many of us would like to
> have something like MFT so that people can indicate their preferences
> clearly and software can do the right thing without provoking these sorts
> of flamewars coming out of culture clashes.

Hear! Hear!

> I don't care if what we get is MFT or something else workable, but I think
> it's clear that the current situation is less than ideal.

Hear! Hear! again.

You've encapsulated nicely the points I've been trying to make.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Wed, 29 Sep 2004 17:35:01 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

At 16:26 29/09/2004, Arnt Gulbrandsen wrote:
>Paul Smith writes:
>>I don't think it's unreasonable to assume that if someone sent a message 
>>to the list, that they are on the list!
>
>A week or three ago I built KDE on my freebsd machine at work. 
>"portinstall -Rr kde". The build failed and the error message directed me 
>to send mail to [email-masked]. That was the first time I'd heard of that 
>address.
>
>Don't google. Tell me: Is [email-masked] a list or not?
>
>I sent a patch; can't remember receiving any reply. Perhaps there was one, 
>but the sender was, ah, courteous enough to remove my address.

If the list was set up properly, you would have received a message from the 
list saying that you need to subscribe to the list in order to post to it - 
otherwise you're inviting spammers in!

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

To: =?iso-8859-1?q?Keld_J=F8rn_Simonsen?= <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 29 Sep 2004 17:56:43 -0700
Sender: [email-masked]

Keld Jørn Simonsen <[email-masked]> writes:

> 1. I think the best way is just to have the MUA not display the
> diplicate mail, if that is what the user wants. I think the extra
> traffic and the extra diskspace needed is negliable. Anyway the MUA
> could delete duplicate mail too.

I'm afraid previous messages to the list have explained why this doesn't
really do what many people want.

> 2. Another way could be for the list exploder software to recognize that
> a member of the list is also in the To: or Cc: fields, I think this test
> is commony already done for the From: field. (metoo) in MTA's. just an
> idea. Maybe some people really want to get two copies.  If so,
> preferences could be set in the list exploder's membership lists.

Likewise, while this has already been implemented in Mailman, this doesn't
do what people want.

The problem is that the people like myself who don't want to receeive the
duplicates generally also want the one message that they receive and see
to be properly sorted with the rest of the mailing list mail, which means
that (in order to do this reliably) it needs to be the copy sent through
the mailing list, possessing all of the apporopriate List-* headers.  This
cannot be done reliably using either of the two methods, since they will
both normally suppress the list copy and retain the personal copy, which
is then filed in the person's normal inbox instead of the mailing list
folder (unless they are using less-reliable and less-convenient filtering
methods that don't take advantage of the standardized List-* headers).

I wish it were as simple as just configuring MUAs to suppress duplicates;
anyone who can run procmail can do that trivially, and many MUAs,
including Gnus (which I use) already have that capability.  The problem
really is more fundamental -- I don't *want* a personal e-mail message,
and I *do* want the message from the mailing list.  Those two messages
differ more than just cosmetically -- consider, for example, that I may be
on the mailing list in digest mode and not want to get even personal
replies until I receive my next scheduled digest.

The mailing list version is the one I want to receive, and it may have
undergone various transformations based on my preferences recorded with
the mailing list management software.  I can come up with more examples of
how they may differ if people are interested.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Thu, 30 Sep 2004 00:22:14 +0200
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Philip Hazel <[email-masked]>, Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, Sep 29, 2004 at 11:44:21AM -0400, Keith Moore wrote:
> 
> Now if recipients had suitable MUAs we could define ways by which 
> senders could provide hints to recipients about what the senders think 
> is the "right thing", and the MUAs could make it easy to comply with 
> the sender's wish if the recipient chose to do so.  But as soon as 
> recipients' MUAs try to use those hints to automate decisions that need 
> to be explicitly made by the recipient _on a per-message basis_ when 
> composing a reply, we will have a worse mess than we have now.

I see your points, Keith, but I think it is in practice not feasible.
I don't want to look every time at who the receivers will be. 
If at all possible I want to have my MUA do the right thing for me.

Generally I think there are 3 possible reply types I want to do:

1. reply-to-all - reply to all receivers of the original message, 
   that is - the people and lists on the To: and Cc: headers, plus the
   sender in the From: header . The reply-to-all would be a good
   candidate for a general reply commend, as it also would be fine
   for an individual reply - except that I don't want to get a copy of my
   own reply in my inbox - which would be an easy thing to avoid for a MUA.

2. reply-to-sender - reply to the From: header address
   This is a special case when I know that I only want the author of the
   original message to see my answer.

3. Reply-to-list - this is when I do not want to reply to the sender 
   or people on the cc: list. This is not the general discussion list
   response, but a special usage case e.g. when a group gets a message from
   an outsider, and want to discuss a potential answer to the outsider
   amongst themselves before releasing the agreed answer.

On top of that it should always be easy to modify the default receivers,
add new receivers etc.

Then for eliminating duplicate mail:

1. I think the best way is just to have the MUA not display the
diplicate mail, if that is what the user wants. I think the extra
traffic and the extra diskspace needed is negliable. Anyway the
MUA could delete duplicate mail too.

2. Another way could be for the list exploder software to recognize
that a member of the list is also in the To: or Cc: fields, 
I think this test is commony already done for the From: field. (metoo)
in MTA's. just an idea. Maybe some people really want to get two copies.
If so, preferences could be set in the list exploder's membership
lists.

Just my 2 eurocent.
best regards
keld

Date: Wed, 29 Sep 2004 15:01:13 -0700
To: ietf-822 list <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

I agree that it would probably be a good thing to have some sort of 
mechanism to indicate how to reply to a list, and perhaps whether or 
not an individual sender would like an individual reply to a given 
message.

But not all problems can be solved by technology.  Etiquette is very 
definitely one of them.  There really is no substitute, 
etiquette-wise, for each one of us personally to adopt the old saw: 
"Be liberal in what you accept and be conservative in what you 
generate."

As a very early poster in this thread said, sometimes even very 
decent people Just Have a Bad Day.  (I remember I had one once.)  On 
those days, anyone and everything into which they come into contact 
will be woefully deficient in their eyes.  This doesn't mean that 
everyone and everything should be changed.

Similarly, as the net has grown large, all sorts of people have been 
added to it who pretty much permanently have bad days.  These people 
will complain loudly and often about things, or willfully and 
persistently fail to understand basic concepts.  Again, that doesn't 
mean the things should be changed.

Remember there is only so much change even a standard can produce. 
We could promulgate a nice standard set of headers and semantics via 
some RFC's or BCP's, and we could be sure that ten years from now, 
less than half the instances of software out there will be paying 
attention to them.

I don't mean there's no point in trying to clarify standards.  I do 
mean that we shouldn't run to grease every wheel that squeaks.

Date: Wed, 29 Sep 2004 22:54:01 +0200
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: Philip Hazel <[email-masked]>
Cc: Keith Moore <[email-masked]>, Tony Hansen <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

On Wed, Sep 29, 2004 at 05:14:45PM +0100, Philip Hazel wrote:
> 
> Er, you wrote this: "it is presumptuous to assume ... that the recipient
> reads the list traffic in the same way that he reads other traffic."
> 
> My point is that it is equally presumptious to assume the opposite. It 
> seemed to me that you were saying "I can't assume the recipient will 
> read list traffic like other traffic, therefore I will send him some 
> other traffic, _presuming_ that he will read other traffic more
> quickly". Apologies if I misinterpreted what you were saying. (And I 
> pointed out that I, for one, will _not_ read your other traffic to me
> any faster than I will the list posting.)

I think it is clear that there are several netiquettes here, and it
seems like some people are very opiniated on this. I am administrating a
number of email lists, and just yesterday one participant left one list
because I do not employ reply-to headers for the list, and another
stopped working because receiving two copies of responses to his mail
was destroying his work happiness (it annoyed him tremendously).

I think we need some guidance on how to handle lists. That is, some best
practice RFC or some RFC on which headers to employ and how.
This should include

1. various scenarios of email list usage:
closed, open with whitelist and moderator, open with moderator, open with
a news gateway, and more.  Different header use may apply to differnt usages.

2. different scenarios of user behaviour and perferences, 
some prefer to have two copies, some prefer to have just one copy.
Some may want to  sort it in folders, other have just one big inbox,
others have a separate inbox that they do not want list mail in.
We cannot do everything, but a number of common scenarios should be
investigated.

3. recommendations to MUA handling
which commands to offer in the MUA: sender-reply, group-reply, 
reply to list, maybe reply to everybody except sender . 
Maybe a recommendation to MUAs on how to handle duplicate mail, maybe
they should only show one instance of it. How folders may be handled
with the new functionality we propose.  There could be both
considerations for sending MUAs and receiving MUAs.

4. recommendations for list exploders
Which headers to set for each different list type, maybe some per-user
settings of preferences.

Some similarities with news could also be pondered upon, and what to
learn from that.

Best regards
Keld

To: [email-masked]
Subject: Re: reply etiquette
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 29 Sep 2004 12:10:27 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Yes. Personally I don't care, but I see the problem.

> For example, some people sort mail into folders on delivery. If replies
> to a message from me contains header fields such as "To: ... arnt" or
> "Cc: ... arnt", that means I could file them where I'll notice them.

> The same thing could be achieved with a little bit of references parsing
> and a database lookup, but the software people use now can't do
> that. (procmail and various sieve implementations are typical examples.)

I think this thread is a wonderful example of why many of us would like to
have something like MFT so that people can indicate their preferences
clearly and software can do the right thing without provoking these sorts
of flamewars coming out of culture clashes.

I don't care if what we get is MFT or something else workable, but I think
it's clear that the current situation is less than ideal.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Wed, 29 Sep 2004 18:28:02 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: reply etiquette
Sender: [email-masked]

Charles Lindsey writes:
> Does anyone else on this list see a problem?

Yes. Personally I don't care, but I see the problem.

For example, some people sort mail into folders on delivery. If replies 
to a message from me contains header fields such as "To: ... arnt" or 
"Cc: ... arnt", that means I could file them where I'll notice them.

The same thing could be achieved with a little bit of references parsing 
and a database lookup, but the software people use now can't do that. 
(procmail and various sieve implementations are typical examples.)

Arnt

Date: Wed, 29 Sep 2004 18:23:47 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey writes:
> Yes, using "LIST" a keyword in group syntax is not the most perfect 
> solution, but then we are not living in a perfect world.

We're also not living in a monoglot world.

Arnt

Date: Wed, 29 Sep 2004 17:14:45 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Tony Hansen <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

On Wed, 29 Sep 2004, Keith Moore wrote:

> > > to see multiple copies of a message.  That's a valid concern, but it is
> > > presumptuous to assume that a recipient is on the list, and that the
> > > recipient
> > > reads the list traffic in the same way that he reads other traffic.

> nope.  I don't presume anything about how recipients file their incoming mail.

Er, you wrote this: "it is presumptuous to assume ... that the recipient
reads the list traffic in the same way that he reads other traffic."

My point is that it is equally presumptious to assume the opposite. It 
seemed to me that you were saying "I can't assume the recipient will 
read list traffic like other traffic, therefore I will send him some 
other traffic, _presuming_ that he will read other traffic more
quickly". Apologies if I misinterpreted what you were saying. (And I 
pointed out that I, for one, will _not_ read your other traffic to me
any faster than I will the list posting.)

> What I presume is that if I reply to a message that someone sent, it's simple
> courtesy to ensure that he reliably gets a copy of the reply.  It's also
> simple courtesy to explicitly notify other recipients of the message that the
> author of the subject message was sent a copy of the reply - so that they know
> he was not snubbed.

And unfortunately it seems that your courtesy is different from several 
others'. That's the problem with culture. What's the solution? I can see 
none other than providing sufficient switches/knobs in the software so 
that people can configure it to suit themselves.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

To: LIST: [email-masked];
Xref: clerew local.mime:3755
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 29 Sep 2004 11:37:33 GMT
Lines: 60
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Charles Lindsey wrote:

>> The only place where it is known that a crosspost is occurring is at the
>> original sender.

>Not true, on at least two counts:

>1. an author might not know that a particular mailbox expands to a list.

Sure, the author might not know all sorts of things, but mostly a decision
to crosspost to two distinct mailing lists is a deliberate decision by the
author. But for sure if the author is not aware of it, then agents further
down the chain will be even less aware of it.

Hence the original sender is that latest point at which there is any hope
of preserving the fact that there is a crosspost so that subsequent agents
can arrange to reply to both. The fact that it may not work in all such
cases is no reason not to take advantage of the possibility when it can.

Unless, of course, you have a better solution to propose.

>2. In the case of a mailing list expander where one of the expansion
>   mailboxes is a list submission mailbox, the maintainer of the
>   first list expander might indeed know that another list is being fed.

In that case, the first list expander is in the position of the author in
case #1. He is in a position to know that he is generating a new crosspost
and to enshrine that information using whatever technique we eventually
come up with.

>> Therefore, any information to inform subsequent agents
>> that crossposting is afoot HAS to be placed in the message by the original
>> sender.

>Bad conclusion based on a false premise.

And you have a better solution?

>> The MFT proposal at least provides a possibility for the original sender
>> to specify such information.

>Which proposal? I haven't seen one that states that MFT "indicates that
>a crosspost is occurring".

It can be arranged that MFT includes all the crossposted lists, which will
at least get replies sent to all the lists. If the MFT can also indicate
which of its addresses were lists, that would be even better.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST: [email-masked];
Xref: clerew local.mime:3754
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 29 Sep 2004 11:16:59 GMT
Lines: 45
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Charles Lindsey wrote:

>> I see nothing in RFC 2822 to indicate how that display-name is intended to
>> be used. Clearly it is useful to display it for the edification of users
>> (and that is actually all that is needed in this case to indicate to users
>> which of the various mailboxes in evidence is/are lists and which are
>> humans). But there is nothing to preclude MUAs from using that information
>> for any purpose, and there is no reason why the convention of using it
>> should not be enshrined in some future standard or BCP.

>Try RFCs 1958 and 2277, paying attention to the difference between
>protocol elements and text.

Yes, using "LIST" a keyword in group syntax is not the most perfect
solution, but then we are not living in a perfect world.

It has the great advantage that it can be used in To:, Cc:, Reply-To: and
MFT headers without introducing any new syntax, and most present UAs will
copy it from Reply-To (and from MFT for those that do it) into To: and/or
Cc: without further ado.

I don't think we are in a position seriously to consider new syntax for
To:, Cc: and Reply-To. We might just be able to consider new syntax for
MFT. Otherwise, the only new syntax would have to be a brand new header
for mailing lists somewhat equivalent to the Newsgroups: header in News
(which would actually have been an excellent solution if someone had
proposed it 20 years ago, but it is hardly realistic to consider it now).

Several contributors to this list have pointed out that you really do need
to be able to recognise which of all the addresses in the various headers
are actually lists. I have proposed a solution that could work. Have you
anything better to propose?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST: [email-masked];
Xref: clerew local.mime:3757
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Angle brackets surrounding Content-ID
Date: Wed, 29 Sep 2004 11:59:06 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Charles Lindsey wrote:
>> 
>> No, I don't think that is right. An id-right, as defined by RFC 2822[...]

>You have missed the critically important fact that in all cases
>discussed, the relevant RFCs refer to RFC 822 (a full Standard),
>not RFC 2822 (a Proposed Standard). And RFC 822 defines the
>identifiers in question as containing a local-part and a domain.

It is the clear intention that RFC 2822 is to supersede RFC 822, and that
all standards that referred to RFC 822 are to be interpreted, so far as is
possible, in the light of RFC 2822.

>RFC 2822 id-right is a problem because it changes the semantics.

Good! It is an improvement.

Have you heard of any cases where this change has caused a problem?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST: [email-masked];
Xref: clerew local.mime:3756
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: reply etiquette
Date: Wed, 29 Sep 2004 11:44:51 GMT
Lines: 24
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>Charles,

>It is inexcusably rude to reply to someone's message without sending 
>the reply to the person who sent the message.  You have done that with 
>several of my messages.  I demand an apology.

I respond to messages that you post to this list by replying to the list.
I understand that you read this list, therefore you see my replies. I do
not see the problem with that.

Does anyone else on this list see a problem?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: Dave Crocker <[email-masked]>
To: Keith Moore <[email-masked]>
CC: ietf-822 list <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Wed, 29 Sep 2004 08:45:58 -0700
Subject: Re: reply etiquette
Sender: [email-masked]

From:
Dave Crocker <[email-masked]> 

Subject:
Re: reply etiquette

Date:
Wed, 29 Sep 2004 08:44:45 -0700

To:
Keith Moore <[email-masked]> 

CC:
ietf-822 list <[email-masked]>  

URL:
http://www.pocomail.com/

hmm.

it appears no one noticed my intended irony.  

my query was an example of the supposed violation but -- as I
expected -- it did not trigger the claimed concern.

In any event, copying only the mailing list is extremely common
etiquette and, in fact, is enforced on lists that set the
Reply-To to be the list.

d/

On Wed, 29 Sep 2004 09:16:33 -0400, Keith Moore wrote:
> > >  It is inexcusably rude to reply to someone's message
> > >  without sending the reply to the person who sent the
> > >  message.  You have done that with several of my
> > >  messages.  I demand an apology.
> > >
> >
> >  I am rather confused by this posting.
> >
> >  Can anyone explain it to me?
> >
>  it's very simple.  if  you reply in a public forum to a
>  message that someone sent, it's common courtesy to send the
>  author of the original message a copy of the reply.
>
>  for a variety of reasons, merely sending the message to the
>  public forum is not sufficient, unless the author has
>  explicitly indicated that this is sufficient.

d/
--
Dave Crocker  <mailto:dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking  <http://brandenburg.com>

d/
--
Dave Crocker  <mailto:dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking  <http://brandenburg.com>

From: Dave Crocker <[email-masked]>
To: Keith Moore <[email-masked]>
CC: ietf-822 list <[email-masked]>
Date: Wed, 29 Sep 2004 08:44:45 -0700
Subject: Re: reply etiquette
Sender: [email-masked]

hmm.

it appears no one noticed my intended irony.  

my query was an example of the supposed violation but -- as I 
expected -- it did not trigger the claimed concern.

In any event, copying only the mailing list is extremely common 
etiquette and, in fact, is enforced on lists that set the 
Reply-To to be the list.

d/

On Wed, 29 Sep 2004 09:16:33 -0400, Keith Moore wrote:
> > >  It is inexcusably rude to reply to someone's message
> > >  without sending the reply to the person who sent the
> > >  message.  You have done that with several of my
> > >  messages.  I demand an apology.
> > >
> >
> >  I am rather confused by this posting.
> >
> >  Can anyone explain it to me?
> >
>  it's very simple.  if  you reply in a public forum to a
>  message that someone sent, it's common courtesy to send the
>  author of the original message a copy of the reply.
>
>  for a variety of reasons, merely sending the message to the
>  public forum is not sufficient, unless the author has
>  explicitly indicated that this is sufficient.

d/
--
Dave Crocker  <mailto:dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking  <http://brandenburg.com>

Cc: Russ Allbery <[email-masked]>, [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 29 Sep 2004 11:44:21 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

>> What I don't agree with is the notion that honoring such requests 
>> should happen "by default", i.e. without the recipient being aware of 
>> it and choosing it explicitly.
>
> I am quite happy with the idea of a configuration option for my MUA 
> that says "enable MTF-handling" (for instance). I am even happy with 
> the default being "disabled". My MUA already has an option "always 
> honour Reply-to"; I suspect that if MFT were "standardised" or in some 
> way  "blessed" by the community, an option would be provided. But I 
> really would like to have SOMETHING that is better than where we are 
> now.

Me too.  But what's clear to me is that we're in this mess largely 
because we've come to expect MUAs to "do the right thing" when it's 
really the reply author's job to specify what the right thing is.  We 
can't fix the problem with additional header fields and additional 
automation in the recipient's MUA.

Now if recipients had suitable MUAs we could define ways by which 
senders could provide hints to recipients about what the senders think 
is the "right thing", and the MUAs could make it easy to comply with 
the sender's wish if the recipient chose to do so.  But as soon as 
recipients' MUAs try to use those hints to automate decisions that need 
to be explicitly made by the recipient _on a per-message basis_ when 
composing a reply, we will have a worse mess than we have now.

Keith

Content-class: urn:content-classes:message
Subject: RE: reply etiquette
Date: Wed, 29 Sep 2004 08:43:46 -0700
From: "Nate Leon" <[email-masked]>
To: "ietf-822 list" <[email-masked]>
Sender: [email-masked]

On the contrary, I consider it careless if you copy me directly on your
reply to my posting, unless I explicitly request that you do so in the
posting.  e.g. "Please copy me on any replies, as I do not read this
list regularly".

Regards,
Nate

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Keith Moore
Sent: Wednesday, September 29, 2004 6:17 AM
To: Dave Crocker
Cc: ietf-822 list
Subject: Re: reply etiquette

>>  It is inexcusably rude to reply to someone's message without
>>  sending the reply to the person who sent the message.  You
>>  have done that with several of my messages.  I demand an
>>  apology.
>
> I am rather confused by this posting.
>
> Can anyone explain it to me?

it's very simple.  if  you reply in a public forum to a message that 
someone sent, it's common courtesy to send the author of the original 
message a copy of the reply.

for a variety of reasons, merely sending the message to the public 
forum is not sufficient, unless the author has explicitly indicated 
that this is sufficient.

Cc: Tony Hansen <[email-masked]>, ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: reply etiquette
Date: Wed, 29 Sep 2004 11:30:26 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

[answering one more message while I wait for a CD to burn...]

>> The courtesy other people see as common is in ridding a recipient of 
>> the need
>> to see multiple copies of a message.  That's a valid concern, but it 
>> is
>> presumptuous to assume that a recipient is on the list, and that the 
>> recipient
>> reads the list traffic in the same way that he reads other traffic.
>
> I do not read list traffic in the same way as I read other traffic.
> However, when you reply to my postings, sending both to me and to the
> list, BOTH copies of the message end up in my ietf-822 folder, and
> that's the way I want it. Well, I don't actually want both copies, but 
> I
> certainly don't want either of them in my main inbox. You do not get my
> attention any faster by sending me a personal copy. (If a copy
> accidentally ends up in my inbox, I curse, and move it to the list
> folder for later attention.)
>
> I post that paragraph by way of an example of how it could be 
> considered
> presumptious to assume a recipient wants to see responses to his/her
> list postings in any different way to any other list postings. That
> seems to be what you are presuming...

nope.  I don't presume anything about how recipients file their 
incoming mail.  What I presume is that if I reply to a message that 
someone sent, it's simple courtesy to ensure that he reliably gets a 
copy of the reply.  It's also simple courtesy to explicitly notify 
other recipients of the message that the author of the subject message 
was sent a copy of the reply - so that they know he was not snubbed.

The alternative of removing the author from the recipient list presumes 
a great deal - that the author of the subject message is (still) on a 
mailing list associated with another of the recipient addresses, that 
the other recipients of the message know that the author is still on 
that mailing list, and that the author of the subject message will see 
the list traffic in a sufficiently timely fashion.  None of these is a 
safe assumption in general.  Even if a reply author knows one or two of 
these, he's unlikely to know all three.

> It is clear (to me at least) that any discussion of culture and/or
> courtesy and/or presumptiousness is going to go rapidly down a rathole.

It is clear (to me at least) that message authors should be clear in 
their intentions about who should receive a message, and that it's up 
to recipients to arrange their incoming mail according to their 
preferences.

Keith

Date: Wed, 29 Sep 2004 17:26:51 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: reply etiquette
Cc: Keith Moore <[email-masked]>, Paul Smith <[email-masked]>
Sender: [email-masked]

Paul Smith writes:
> I don't think it's unreasonable to assume that if someone sent a 
> message to the list, that they are on the list!

A week or three ago I built KDE on my freebsd machine at work. 
"portinstall -Rr kde". The build failed and the error message directed 
me to send mail to [email-masked]. That was the first time I'd heard 
of that address.

Don't google. Tell me: Is [email-masked] a list or not?

I sent a patch; can't remember receiving any reply. Perhaps there was 
one, but the sender was, ah, courteous enough to remove my address.

Arnt

Date: Wed, 29 Sep 2004 17:20:43 +0200 (Romance Daylight Time)
From: Xavier Nodet <[email-masked]>
Subject: Re: Understanding response protocols
To: [email-masked]
cc: Keith Moore <[email-masked]>
Sender: [email-masked]

--=_UBjM22Ot.we7c_8HYJIwTf1S7N3jik
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Disposition: INLINE
content-transfer-encoding: quoted-printable

On Wed, 29 Sep 2004 10:25:10 -0400 Keith Moore =
<[email-masked]> wrote:

> In every Windows and MacOSX based MUA that I have seen, [it =
is] very
> cumbersome to override the decision/guess/suggestion made by =
the MUA.

The MUA I use has a different way of doing things: instead of =
having one
'To:' and one 'Cc:' field with possibly many addresses in each,=
 it uses
one line per address, and this line has a drop-down box in =
front of it
with (among others) 'To', 'Cc', 'Bcc' and 'None'. When 'None' is
selected for a particular address, this address is grayed, and =
of course
not used to send the reply.

When I chose 'reply-To-List' for your message, and because my =
MUA knows
that <[email-masked]> is the address of a list, only this =
address had
'To' in front of it. But the other addresses where still =
available, and
I just had to change the selection from 'None' to 'Cc' to =
include you in
the recipients of my reply.

You can see that on
  <http://xavier.nodet.free.fr/Mahogany-composing.png>

--=20
Xavier Nodet
"They that can give up essential liberty to obtain a little =
temporary
safety deserve neither liberty nor safety." - Benjamin =
Franklin, 1759.

--=_UBjM22Ot.we7c_8HYJIwTf1S7N3jik
Content-Type: application/pgp-signature
Content-Disposition: inline

--=_UBjM22Ot.we7c_8HYJIwTf1S7N3jik--

Date: Wed, 29 Sep 2004 16:17:01 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Tony Hansen <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

On Wed, 29 Sep 2004, Keith Moore wrote:

> The courtesy other people see as common is in ridding a recipient of the need
> to see multiple copies of a message.  That's a valid concern, but it is
> presumptuous to assume that a recipient is on the list, and that the recipient
> reads the list traffic in the same way that he reads other traffic.

I do not read list traffic in the same way as I read other traffic. 
However, when you reply to my postings, sending both to me and to the 
list, BOTH copies of the message end up in my ietf-822 folder, and 
that's the way I want it. Well, I don't actually want both copies, but I
certainly don't want either of them in my main inbox. You do not get my
attention any faster by sending me a personal copy. (If a copy 
accidentally ends up in my inbox, I curse, and move it to the list 
folder for later attention.)

I post that paragraph by way of an example of how it could be considered
presumptious to assume a recipient wants to see responses to his/her
list postings in any different way to any other list postings. That
seems to be what you are presuming...

It is clear (to me at least) that any discussion of culture and/or
courtesy and/or presumptiousness is going to go rapidly down a rathole.
I don't think we can start from that end and then design mechanism
afterwards, because there are too many variables.

It may be unpalatable, but if we do anything (and I suspect that if we 
don't, something will "just grow"), I think we have to add a little bit 
of mechanism that we hope people can tweak to suit their culture and 
courtesy expectations sufficiently for them to live with it. (The 
currently available mechanism isn't enough; if it were, we would not be 
having this discussion.)

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Wed, 29 Sep 2004 16:03:53 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, 29 Sep 2004, Keith Moore wrote:

> What I don't agree with is the notion that honoring such requests
> should happen "by default", i.e. without the recipient being aware of
> it and choosing it explicitly.

I am quite happy with the idea of a configuration option for my MUA that
says "enable MTF-handling" (for instance). I am even happy with the
default being "disabled". My MUA already has an option "always honour
Reply-to"; I suspect that if MFT were "standardised" or in some way 
"blessed" by the community, an option would be provided. But I really
would like to have SOMETHING that is better than where we are now.

> Traditionally, with a meatspace meeting room, you were either inside
> the room (and participating in the meeting) or you were not.  Along
> with the isolation (and privilege) inherent in the physical
> arrangement was often some expectation of focus among participants.
> Including someone outside the room in a discussion that was going on
> inside the room was generally infeasible without special arrangements.
> But with email, lists are just multicast addresses, so discussions
> routinely involve participants that might not be on the list.  And
> being "on" a list is not like being "in" a meeting room (in the days
> before laptops and WiFi) - for instance you can be "on" a list while
> still having far greater demands on your attention that aren't visible
> to other list participants.

Sure, but I think most people nowadays understand that. Certainly those 
that subscribe to lots of lists do, I'm sure.

> Letting the author provide hints about _who_ to reply to might be useful for
> other reasons, but expecting recipients to recognize and accommodate senders'
> preferences about duplicates and filing cannot scale.

Manually, yes, but why not automatically?

<jest>
How about a Common-Courtesy: header to specify what the sender's 
or the list's interpretation of "common courtesy" is? 
</jest>

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Wed, 29 Sep 2004 15:55:30 +0100
To: Keith Moore <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: reply etiquette
Cc: ietf-822 list <[email-masked]>
Sender: [email-masked]

At 15:31 29/09/2004, Keith Moore wrote:

>>Which is exactly the opposite of what some other people consider to be 
>>common courtesy. Many people feel that common courtesy dictates that you 
>>SHOULD trim down the To/Cc recipients to just the list name.
>
>here's the difference:
>
>The courtesy I'm referring to is ensuring that the author of a message 
>gets a copy of the reply, and ensuring that other participants in the 
>discussion are aware that the author was sent a copy of the reply.  The 
>only way to do this reliably is to explicitly specify the author of the 
>subject message as one of the reply recipients.
>
>The courtesy other people see as common is in ridding a recipient of the 
>need to see multiple copies of a message.  That's a valid concern, but it 
>is presumptuous to assume that a recipient is on the list, and that the 
>recipient reads the list traffic in the same way that he reads other traffic.

I don't think it's unreasonable to assume that if someone sent a message to 
the list, that they are on the list!

I agree that the author of the message should get a reply - but given the 
reasonable assumption that if someone is participating in a discussion in a 
mailing list, they are probably receiving messages from the list, replying 
to the list alone should be sufficient. I DON'T agree that other 
participants in the discussion need to be made explicitly aware that the 
author was sent a copy of the reply - for the same reason; it is not 
unreasonable for them to assume that the original author is on the list, so 
a message to the list will get back to the original author.

As you may have seen from other responses to you, _your_ idea of 'common 
courtesy' isn't the same as quite a few other people, so flaming someone 
because they did what THEY saw as common courtesy is definitely not 
courteous. The PROPER way for you to express your opinion would have been 
along the lines of "I don't read mail to the list as quickly as mail sent 
directly to me, so I'd prefer it if you Cc'd your replies to me as well". 
Flaming was totally undeserved.

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

From: Keith Moore <[email-masked]>
Subject: travelling
Date: Wed, 29 Sep 2004 10:34:01 -0400
To: ietf-822 list <[email-masked]>
Sender: [email-masked]

I will be out of town for a few days, with minimal email contact - and 
I don't even have time to catch up on this list's traffic before I 
leave.  So I'll catch up when I get back, probably by early next week.

Keith

Cc: ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: reply etiquette
Date: Wed, 29 Sep 2004 10:31:51 -0400
To: Tony Hansen <[email-masked]>
Sender: [email-masked]

> Which is exactly the opposite of what some other people consider to be 
> common courtesy. Many people feel that common courtesy dictates that 
> you SHOULD trim down the To/Cc recipients to just the list name.

here's the difference:

The courtesy I'm referring to is ensuring that the author of a message 
gets a copy of the reply, and ensuring that other participants in the 
discussion are aware that the author was sent a copy of the reply.  The 
only way to do this reliably is to explicitly specify the author of the 
subject message as one of the reply recipients.

The courtesy other people see as common is in ridding a recipient of 
the need to see multiple copies of a message.  That's a valid concern, 
but it is presumptuous to assume that a recipient is on the list, and 
that the recipient reads the list traffic in the same way that he reads 
other traffic.

Keith

Cc: Russ Allbery <[email-masked]>, [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 29 Sep 2004 10:25:10 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

>> I think it would be better if no "logic" were needed.  The decision 
>> of who to reply to belongs to the person composing the reply.  For 
>> the UA to make it easy for that person to "fill in the blanks" is 
>> reasonable.  For the UA to try to employ "logic" to _decide_ (or 
>> equivalently, _guess_) where the message should go is not reasonable.
>
> How about calling it "suggest" rather than "decide" or "guess"?
>
> When I do "reply-to-all" (as my fingers are now trained to do) in my 
> MUA, it creates To: and Cc: fields according to its current "logic".  
> These fields are displayed when I construct the reply. They can be 
> seen as a _suggestion_ that those are probably the addresses I want to 
> use. And they often are. However, I have the opportunity to modify 
> them before sending the message. Surely this is what everybody wants?

MUAs vary according to how easy it is to modify those recipient 
addresses, and how much information is given to recipients to allow 
them to make reasonable choices about those recipient addresses.  In 
every Windows and MacOSX based MUA that I have seen,  (and most of the 
*x ones) and with typical screen sizes, it is cumbersome to view all 
relevant fields of the subject message while composing the reply, and 
very cumbersome to override the decision/guess/suggestion made by the 
MUA.  Copying and pasting addresses from the subject message typically 
involves a fair amount of clicking (to select/raise windows, which 
typically buries the other window you're interested in), clicking again 
(to select addresses or text), and either dragging or "copy" and 
"paste" key presses.  If you can type, transcribing the addresses is 
actually easier, but it's error prone.

So no, I don't think this is what "everybody" wants.  I think it's what 
"everybody" is accustomed to.

> What we are arguing about is a way of making it possible for MUAs to  
> improve their suggestions.

"improving the suggestions" may be the wrong tack.  I don't want MUAs 
to be more clever as much as I want them to be more transparent.

>  In particular, people want more information about the wishes of 
> original message's author with regard to replies to be available to 
> the MUA. (Reply-to: might once have been intended for this, but it has 
> been used in the wrong way, so we have to try again.)

And (at least in principle) I agree that giving authors a better way to 
convey such information to recipients might be useful, and I agree with 
giving this information to recipients, and I even agree with making it 
easy for recipients to honor that request.  What I don't agree with is 
the notion that honoring such requests should happen "by default", i.e. 
without the recipient being aware of it and choosing it explicitly.

> My MUA has only a "reply-to-all"; there is no "reply-to-list". I 
> therefore have to remember to delete Dan's address whenever I reply to
> one of his messages and NOT to delete Keith's address whenever I reply 
> to one of his. I am in danger of annoying both of them if I get it 
> wrong. My MUA has suggested that this message be copied to Russ 
> because he was involved somewhere back in the thread and his address 
> has been carried along in OPs' replies; I have no idea if he wants an 
> individual copy or not.

Lists are "interesting" for lots of reasons.  I'm starting to see that 
different people view lists in different ways - or that they project 
different sets of social conventions onto the same simple multicast 
mechanism.  Sometimes a particular list has established conventions of 
its own, at other times people implicitly or explicitly believe that a 
list "should" adhere to certain social conventions that they've 
observed elsewhere - often in meatspace.  When different individuals on 
a list have conflicting ideas as to what behavior is appropriate, we're 
not going to solve that problem with adding new fields to the email 
protocol.  (We _might_ solve the problem by explicitly establishing 
social conventions on a per-list basis, and extending the email 
protocol to communicate those conventions to list participants - but 
the main thing is to address the underlying conflict between people's 
expectations.  The mechanism is secondary.)

Because email was not designed for group discussion but as an 
interpersonal communication tool, it doesn't help its participants 
adhere to the social conventions of any particular group (even if those 
are established).   Actually it helps participants violate those 
conventions.  Traditionally, with a meatspace meeting room, you were 
either inside the room (and participating in the meeting) or you were 
not.  Along with the isolation (and privilege) inherent in the physical 
arrangement was often some expectation of focus among participants.  
Including someone outside the room in a discussion that was going on 
inside the room was generally infeasible without special arrangements.  
But with email, lists are just multicast addresses, so discussions 
routinely involve participants that might not be on the list.  And 
being "on" a list is not like being "in" a meeting room (in the days 
before laptops and WiFi) - for instance you can be "on" a list while 
still having far greater demands on your attention that aren't visible 
to other list participants.

The duplicate copies issue is separate.  It's understandable that 
people do not want to see duplicate copies of messages.  It's also 
understandable that different people want different filing arrangements 
for their messages.  But message authors (and reply authors) shouldn't 
be expected to cater to every recipient's whims about duplicate copies 
and filing arrangements.  The right thing is for the author of a 
message (or reply) is to specify _who_ should get the message (where 
_who_ includes lists and/or individuals).  Duplicate suppression and 
filing of messages should be sorted out by software that acts on behalf 
of each recipient, according to that recipient's preferences.  Letting 
the author provide hints about _who_ to reply to might be useful for 
other reasons, but expecting recipients to recognize and accommodate 
senders' preferences about duplicates and filing cannot scale.

Keith

Date: Wed, 29 Sep 2004 15:05:20 +0100
To: Keith Moore <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: reply etiquette
Cc: ietf-822 list <[email-masked]>
Sender: [email-masked]

At 14:16 29/09/2004, Keith Moore wrote:

>>>  It is inexcusably rude to reply to someone's message without
>>>  sending the reply to the person who sent the message.  You
>>>  have done that with several of my messages.  I demand an
>>>  apology.
>>
>>I am rather confused by this posting.
>>
>>Can anyone explain it to me?
>
>it's very simple.  if  you reply in a public forum to a message that 
>someone sent, it's common courtesy to send the author of the original 
>message a copy of the reply.

It's NOT 'common courtesy' - it's what YOU prefer. Don't assume your 
preferences are they way everyone should work!

In many mailing lists that I'm on, people have expressed the preference NOT 
to receive multiple copies of replies, and it's common practice to trim the 
To and Cc fields of replies to ensure they only go back to the list. If YOU 
prefer to receive duplicated emails, that's fine, but don't insult people 
because they are trying to be considerate and only send you one copy of 
their reply. People don't automatically know your preferences.

If you want people to send you lots of copies of their replies, put it in 
your signature or something, and accept mistakes. It's not 'rude' for 
people to try to be considerate - just because you prefer them not to be 
when they're replying to your messages doesn't mean that you have the right 
to 'demand an apology'.

I'll assume you were just having a bad day, otherwise your attack would 
have been "inexcusably rude" as well.
Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Wed, 29 Sep 2004 10:07:26 -0400
From: Tony Hansen <[email-masked]>
To: Keith Moore <[email-masked]>
CC: ietf-822 list <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

Which is exactly the opposite of what some other people consider to be 
common courtesy. Many people feel that common courtesy dictates that you 
SHOULD trim down the To/Cc recipients to just the list name.

"Common courtesy is neither common, nor for some people, courteous." -- me

	Tony Hansen
	[email-masked]

Keith Moore wrote:

>>>  It is inexcusably rude to reply to someone's message without
>>>  sending the reply to the person who sent the message.  You
>>>  have done that with several of my messages.  I demand an
>>>  apology.
>>
>> I am rather confused by this posting.
>> Can anyone explain it to me?
> 
> it's very simple.  if  you reply in a public forum to a message that 
> someone sent, it's common courtesy to send the author of the original 
> message a copy of the reply.
> 
> for a variety of reasons, merely sending the message to the public forum 
> is not sufficient, unless the author has explicitly indicated that this 
> is sufficient.

Date: Wed, 29 Sep 2004 14:31:58 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Dave Crocker <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: reply etiquette
Sender: [email-masked]

On Wed, 29 Sep 2004, Keith Moore wrote:

> for a variety of reasons, merely sending the message to the public forum is
> not sufficient, unless the author has explicitly indicated that this is
> sufficient.

I wish I could! I wish I could! For me it *is* sufficient, and I know 
I'm not alone in this. How can we best move forward from here to agree 
on something that at least allows this functionality to happen 
more-or-less automatically? (I do *not* want to burden people with 
having to remove my address manually every time they respond to one of 
my postings.)

Regards,
Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Cc: ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: reply etiquette
Date: Wed, 29 Sep 2004 09:16:33 -0400
To: Dave Crocker <[email-masked]>
Sender: [email-masked]

>>  It is inexcusably rude to reply to someone's message without
>>  sending the reply to the person who sent the message.  You
>>  have done that with several of my messages.  I demand an
>>  apology.
>
> I am rather confused by this posting.
>
> Can anyone explain it to me?

it's very simple.  if  you reply in a public forum to a message that 
someone sent, it's common courtesy to send the author of the original 
message a copy of the reply.

for a variety of reasons, merely sending the message to the public 
forum is not sufficient, unless the author has explicitly indicated 
that this is sufficient.

To: LIST: [email-masked];
Xref: clerew local.mime:3753
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 29 Sep 2004 10:59:07 GMT
Lines: 72
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>Yes.  The more I look at the problem of replies, the more it looks like the
>problem is 90% UA construction and 10% protocol.   Which probably means that
>adding more protocol isn't the most important part of a solution.  And
>since adding more protocol tends to mean more complexity, doing so could 
>easily make the situation worse.   The thing to do is to get UA functionality
>right, _then_ to see what new protocol frobs (if any) are appropriate.

But the situation seems to be that you can't get the UA functionality
right without some extra protocol, because the information for the UA to
do a decent job just isn't available at present (I think few of us are
convinced by Bruce's claim that Reply-To can be made to do it all).

Moreover, if MUAs are going to be significantly changed to accomodate this
problem, then incorporating some extra protocol at the same time is
neither here nor there.

So yes, the final solution to this will contain both a protocol element
(MFT header or whatever) and a BCP component, and the BCP component may
well be 90% of it (and if a BCP is to be written for mailing lists, then
there are probably a lot of other things that could usefully be said in
it).

>> UAs clearly do need to show where replies will go, and insofar as they
>> don't do that with Reply-To now, I think that's a problem.  But it's not
>> that they're incapable of doing that. 

>No, but current standards are not encouraging them to do that, and in some
>cases they may even be discouraging that.

>> > Of course, if all of the header fields were displayed, the problem would
>> > then be one of complexity.

Actually, is is not display of Reply-To and MFT by agents that is
essential (though it is highly desirable). What is essential is for
compose windows to exhibit clearly the To: and Cc: for the reply (with
alerts and bright red colours if they are not what the user might have
expected, if you like). And the user MUST have the ability to edit those
fields before committing the reply.

But are there any compose windows out there that do not already do that?

>I think it would be better if no "logic" were needed.  The decision of who
>to reply to belongs to the person composing the reply.  For the UA to make
>it easy for that person to "fill in the blanks" is reasonable.  For the UA
>to try to emply "logic" to _decide_ (or equivalently, _guess_) where the 
>message should go is not reasonable.

The ultimate decision certainly belongs there, but the average user will
surely be happy to go along with the what the original author of the list
expander asked for or whatever is the "culture" of the list. Moreover, the
average user just wants a quiet life. He just wants to hit one button,
compose his reply, and hit 'send'. He does not want to be "filling in any
blanks" in the case of what he regards as routine replies.

Yes, just occasionaly he will want to do something different, and some
users may want to do something different all the time, but MUAs should be
designed to make life convenient for the average user (though by all means
let them be configurable to do special things for users who want to be
different).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Wed, 29 Sep 2004 11:45:08 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Bruce Lilly writes:
> Yes, I should have been more clear. It is certainly possible that the 
> ISP has modified Exim, or that it is invoking some external program 
> that is modifying the message.

I'll bet it's a virus/spam filter. It's an ISP, so perhaps Spam 
Assassin? If any of you have SA handy, please test it.

Arnt

Date: Wed, 29 Sep 2004 09:49:42 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: 822 <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

On Tue, 28 Sep 2004, Bruce Lilly wrote:

> Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com)
>	by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7)
>	id 1CAHhO-0002LQ-00; Wed, 22 Sep 2004 20:43:02 -0400
> 
> which appears to identify the same (somewhat old) version of Exim.

Very old. Exim 4 was released in February 2002. Exim 3 is no longer
maintained. However, neither of them has ever had code for folding
header lines.

> I am certain that the problems identified don't happen before
> messages get to that ISP from here (and it's certainly not an
> MUA issue), and it appears that the added exclamation point
> happened somewhere after that ISP.

As long as it's not my problem, I'm happy. :-)

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Wed, 29 Sep 2004 09:46:18 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Tue, 28 Sep 2004, Keith Moore wrote:

> I think it would be better if no "logic" were needed.  The decision of who
> to reply to belongs to the person composing the reply.  For the UA to make
> it easy for that person to "fill in the blanks" is reasonable.  For the UA
> to try to emply "logic" to _decide_ (or equivalently, _guess_) where the 
> message should go is not reasonable.

How about calling it "suggest" rather than "decide" or "guess"? 

When I do "reply-to-all" (as my fingers are now trained to do) in my 
MUA, it creates To: and Cc: fields according to its current "logic". 
These fields are displayed when I construct the reply. They can be seen
as a _suggestion_ that those are probably the addresses I want to use.
And they often are. However, I have the opportunity to modify them
before sending the message. Surely this is what everybody wants?

What we are arguing about is a way of making it possible for MUAs to 
improve their suggestions. In particular, people want more information 
about the wishes of original message's author with regard to replies to 
be available to the MUA. (Reply-to: might once have been intended for 
this, but it has been used in the wrong way, so we have to try again.)

My MUA has only a "reply-to-all"; there is no "reply-to-list". I 
therefore have to remember to delete Dan's address whenever I reply to
one of his messages and NOT to delete Keith's address whenever I reply
to one of his. I am in danger of annoying both of them if I get it
wrong. My MUA has suggested that this message be copied to Russ because 
he was involved somewhere back in the thread and his address has been 
carried along in OPs' replies; I have no idea if he wants an individual
copy or not.

Clearly this does not scale.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

From: Dave Crocker <[email-masked]>
To: ietf-822 list <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Tue, 28 Sep 2004 20:15:57 -0700
Subject: Re: reply etiquette
Sender: [email-masked]

On Tue, 28 Sep 2004 09:57:26 -0400, Keith Moore wrote:
>  It is inexcusably rude to reply to someone's message without
>  sending the reply to the person who sent the message.  You
>  have done that with several of my messages.  I demand an
>  apology.

I am rather confused by this posting.  

Can anyone explain it to me?

d/
--
Dave Crocker  <mailto:dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking  <http://brandenburg.com>

Date: 29 Sep 2004 02:26:57 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore writes:
> The thing to do is to get UA functionality right, _then_ to see what
> new protocol frobs (if any) are appropriate.

One of the crucial MUA features is to automatically communicate certain
information to recipients. Communication _requires_ protocol support.

Specifically, in various situations, the recipient needs to know that
followups go to T, and replies go to R, where R isn't contained in T.
The protocol needs to support this communication. But the old de-facto
standard protocol always includes R in T. That's why the protocol had to
be changed.

Of course, I went through all this in detail in the first message in
this ``Understanding response protocols'' thread. You're now officially
going in circles; congratulations.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: 29 Sep 2004 02:16:49 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Automatic specification of followup targets
Sender: [email-masked]

Long ago I put [email-masked] into my ~/.lists configuration file.
Here's what that told my MUA: ``Please _automatically_ request that my
address be excluded from followups to any message that I send to
[email-masked].''

(The MUA communicates the request using Mail-Followup-To. In detail: if
one of my outgoing messages has [email-masked] in To or Cc, the MUA
automatically copies To+Cc to Mail-Followup-To---unless there's already
a Mail-Followup-To, of course.)

I commented that old message injectors don't have this feature, so they
have to be changed. MUAs need a few extra lines of code. This fact isn't
tied to the protocol for communicating the request; the MUAs simply
don't have the code to inspect and copy To+Cc.

(The feature _is_ supported for all shell users on qmail boxes, for Mutt
users, and for Gnus users---in every case, using Mail-Followup-To.)

A few people have now sent messages claiming that old MUAs _do_ have
this feature---but they're talking about a _different_ feature, one that
fails to accomplish the same result. Specifically, many MUAs can inspect
the _mailbox_---which is quite different from inspecting To+Cc---and add
a preconfigured field---which is quite different from copying To+Cc. The
overall result is a remarkably poor approximation to what users want.
The bottom line is that the MUAs still need to be changed.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Tue, 28 Sep 2004 19:55:24 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: 822 <[email-masked]>
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey wrote:

> The only place where it is known that a crosspost is occurring is at the
> original sender.

Not true, on at least two counts:
1. an author might not know that a particular mailbox expands to a list.
   Indeed, the list manager might not know! [I recall a case where one
   of the GNU bog reporting mailboxes was a list expander, and that
   expander for a time sent out complaints (to the From field, not the
   envelope sender address or Reply-To, or Sender) that the domain name
   had changed -- the domain was the one put in by the expander and it
   turned out that that was the very site that was also generating the
   complaints.]
2. In the case of a mailing list expander where one of the expansion
   mailboxes is a list submission mailbox, the maintainer of the
   first list expander might indeed know that another list is being fed.

> Therefore, any information to inform subsequent agents
> that crossposting is afoot HAS to be placed in the message by the original
> sender.

Bad conclusion based on a false premise.

> The MFT proposal at least provides a possibility for the original sender
> to specify such information.

Which proposal? I haven't seen one that states that MFT "indicates that
a crosspost is occurring".

Date: Tue, 28 Sep 2004 19:43:56 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: 822 <[email-masked]>
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>>Existing UAs do have this feature. It's called setting the content
>>of the standard Reply-To field, which has precisely the desired
>>semantics as specified in RFC 2822:
> 
> 
> Which existing MUAs have the feature to set the Reply-To field
> "_automatically_" according to the particular list(s) involved?

In addition to ones already mentioned by others, Kmail can do so
on a per-folder basis, and can initialize that setting from the
mailto URI of a List-Post field.  Mozilla, Ximian Evolution,
Outlook, and Sylpheed can have a Reply-To field set per "account"
or "identity", which can be easily changed (and certain folders
can be associated with one).  Of those -- which include the most
widely used MUAs -- Kmail seems to be the most easily automated
(indeed, setting a Reply-To address list manually for a folder
involves typing in not a list of addresses but a mailto URI, which
isn't exactly intuitive, but I digress).

Date: Tue, 28 Sep 2004 19:27:02 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: 822 <[email-masked]>
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey wrote:

> I see nothing in RFC 2822 to indicate how that display-name is intended to
> be used. Clearly it is useful to display it for the edification of users
> (and that is actually all that is needed in this case to indicate to users
> which of the various mailboxes in evidence is/are lists and which are
> humans). But there is nothing to preclude MUAs from using that information
> for any purpose, and there is no reason why the convention of using it
> should not be enshrined in some future standard or BCP.

Try RFCs 1958 and 2277, paying attention to the difference between
protocol elements and text.  Text is for human consumption and is
in some language; protocol elements are simply keywords. Display
names, comments, and the field bodies of unstructured fields are
text, which is why precisely those elements are the ones which may
contain encoded-words (RFC 2047/2231/errata).  Every past attempt
to overload display names, comments, and/or unstructured field
bodies with some sort of protocol content has been an unmitigated
disaster.

Indicating a mailbox as a list isn't terribly informative; it may
be a list that expands to one mailbox (or none), the author may
have guessed incorrectly and indicated a non-list as a list or
vice versa, and
  John List:[email-masked];
is at best ambiguous.

Date: Tue, 28 Sep 2004 18:54:32 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: Philip Hazel <[email-masked]>
CC: 822 <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Philip Hazel wrote:

> Exim does not deliberately modify message headers or message bodies
> apart from the required minimum such as adding Received: and translating
> CRLF into LF for local storage. I am firmly of the opinion that messing
> around with message content is not the job of an MTA. There is
> definitely no code for folding header lines in Exim. I have just double-
> checked by sending a message with a References: line that was over 1,000
> characters long. (I am the author of Exim, incidentally.)
> 
> It is possible for a sysadmin to configure Exim to remove and add header 
> lines. It is probably possible to try to make it fold by a sufficiently
> hacky configuration, but that's the fault of the writer of the 
> configuration, not Exim. I suspect that some other software is involved
> at your ISP.

Yes, I should have been more clear. It is certainly possible that
the ISP has modified Exim, or that it is invoking some external
program that is modifying the message. Or it may be a version
issue; the SMTP greeting line emitted is

220 smtp02.mrf.mail.rcn.net ESMTP [NO UCE] RCN Exim 3.35 #7 Tue, 28 Sep 2004 18:41:40 -0400

and the Received field from the modified list message was:

Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com)
	by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7)
	id 1CAHhO-0002LQ-00; Wed, 22 Sep 2004 20:43:02 -0400

which appears to identify the same (somewhat old) version of Exim.

I am certain that the problems identified don't happen before
messages get to that ISP from here (and it's certainly not an
MUA issue), and it appears that the added exclamation point
happened somewhere after that ISP.

Date: Tue, 28 Sep 2004 16:43:38 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> Keith Moore <[email-masked]> writes:
> 
> > In a sense that's correct, because the header recipient addresses and
> > the envelope recipient addresses don't have to agree at all.  But the
> > point is that the replier needs to be fully aware of where his replies
> > are going.  User agents that appear to change their behavior from one
> > message to the next do not promote such awareness.
> 
> I agree with this.
> 
> > The difference in (apparent) consistency occurs because Reply-To, MFT,
> > or similar fields are often not displayed to the recipient.  The
> > recipient expects the reply to go to the sender and recipient addresses
> > that were displayed when he read the message, not to some other set of
> > addresses that were hidden from view.
> 
> Surely this is fundamentally a UA problem, though, isn't it?  

Yes.  The more I look at the problem of replies, the more it looks like the
problem is 90% UA construction and 10% protocol.   Which probably means that
adding more protocol isn't the most important part of a solution.  And
since adding more protocol tends to mean more complexity, doing so could 
easily make the situation worse.   The thing to do is to get UA functionality
right, _then_ to see what new protocol frobs (if any) are appropriate.

> UAs clearly do need to show where replies will go, and insofar as they
> don't do that with Reply-To now, I think that's a problem.  But it's not
> that they're incapable of doing that. 

No, but current standards are not encouraging them to do that, and in some
cases they may even be discouraging that.

> > Of course, if all of the header fields were displayed, the problem would
> > then be one of complexity.
> 
> I think it would be better for the UA to work out the logic for the user,
> at least for UAs not targetted at sophisticated users.

I think it would be better if no "logic" were needed.  The decision of who
to reply to belongs to the person composing the reply.  For the UA to make
it easy for that person to "fill in the blanks" is reasonable.  For the UA
to try to emply "logic" to _decide_ (or equivalently, _guess_) where the 
message should go is not reasonable.

Keith

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 28 Sep 2004 13:11:43 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> In a sense that's correct, because the header recipient addresses and
> the envelope recipient addresses don't have to agree at all.  But the
> point is that the replier needs to be fully aware of where his replies
> are going.  User agents that appear to change their behavior from one
> message to the next do not promote such awareness.

I agree with this.

> The difference in (apparent) consistency occurs because Reply-To, MFT,
> or similar fields are often not displayed to the recipient.  The
> recipient expects the reply to go to the sender and recipient addresses
> that were displayed when he read the message, not to some other set of
> addresses that were hidden from view.

Surely this is fundamentally a UA problem, though, isn't it?  Assuming
that we have to add some new field or some new definition in order to
improve the existing situation, UAs are going to need at least some degree
of modification to use it or use the existing field correctly.  (Even if
we go with Bruce's approach which requires no new fields, UAs are going to
need to modify their handling of Reply-To in order to make the semantics
Bruce discusses easier for people to use.  Many UAs don't have a way of
setting Reply-To or only have one global setting.)

UAs clearly do need to show where replies will go, and insofar as they
don't do that with Reply-To now, I think that's a problem.  But it's not
that they're incapable of doing that.  In fact, if *any* routing of
replies other than simple functions of From, To, and Cc headers is
supported (and I think that we can all agree that at least some people
want this quite a bit, enough so that the need isn't going to go away),
the UA issues seem about the same to me.  There has to be some way to show
the user where their replies to a particular message are going to go.

> Of course, if all of the header fields were displayed, the problem would
> then be one of complexity.

I think it would be better for the UA to work out the logic for the user,
at least for UAs not targetted at sophisticated users.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Tue, 28 Sep 2004 15:47:03 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> Keith Moore <[email-masked]> writes:
> 
> > The notion that a recipient's MUA should change its behavior according
> > to the whim of some other author was broken with Reply-To and it's still
> > broken with MFT.  In all cases the user agent's goal is to serve its
> > user.  To do that well it needs to provide _consistent_ behavior, not
> > behavior that changes from one message to the next.
> 
> I'm not sure I understand what you're saying here.  The author of the
> message that is being replied to is always going to have control over
> where replies go absent manual editing of the destination fields, since
> that author has complete control over all of the headers from which reply
> destinations can be drawn. 

In a sense that's correct, because the header recipient addresses and the
envelope recipient addresses don't have to agree at all.  But the point
is that the replier needs to be fully aware of where his replies are going.
User agents that appear to change their behavior from one message to the 
next do not promote such awareness.

> Using MFT is just as consistent as not using MFT.  Always using From as
> the reply address is just as consistent as using Reply-To if present,
> otherwise From.  One of these things is more *complex* than the other, but
> that's not the same thing as consistency.

The difference in (apparent) consistency occurs because Reply-To, MFT, or 
similar fields are often not displayed to the recipient.  The recipient
expects the reply to go to the sender and recipient addresses that were
displayed when he read the message, not to some other set of addresses that
were hidden from view.

Of course, if all of the header fields were displayed, the problem would
then be one of complexity.

Keith

To: Keith Moore <[email-masked]>
Cc: ietf-822 list <[email-masked]>
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 28 Sep 2004 12:07:36 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> The notion that a recipient's MUA should change its behavior according
> to the whim of some other author was broken with Reply-To and it's still
> broken with MFT.  In all cases the user agent's goal is to serve its
> user.  To do that well it needs to provide _consistent_ behavior, not
> behavior that changes from one message to the next.

I'm not sure I understand what you're saying here.  The author of the
message that is being replied to is always going to have control over
where replies go absent manual editing of the destination fields, since
that author has complete control over all of the headers from which reply
destinations can be drawn.  Therefore, the MUA's reply behavior is
*always* going to depend on the whim of the author of the original
message, since that's where the data comes from.

Using MFT is just as consistent as not using MFT.  Always using From as
the reply address is just as consistent as using Reply-To if present,
otherwise From.  One of these things is more *complex* than the other, but
that's not the same thing as consistency.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Tue, 28 Sep 2004 10:53:12 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: 822 <[email-masked]>
Subject: Re: Angle brackets surrounding Content-ID
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
> 
> 
>>Temporarily leaving aside "strip these angle brackets", there
>>are several issues that should be taken into consideration
>>when comparing identifiers:
> 
> 
>>* domain names are case-insensitive, so "<[email-masked]>"
>> is semantically identical to "<[email-masked]>".  RFC
>> 2822 presents a problem here, because a receiver can never
>> be sure whether or not an RFC 2822 id-right is a case-
>> insensitive domain name or something else (which might be
>> case-sensitive).
> 
> 
> No, I don't think that is right. An id-right, as defined by RFC 2822[...]

You have missed the critically important fact that in all cases
discussed, the relevant RFCs refer to RFC 822 (a full Standard),
not RFC 2822 (a Proposed Standard). And RFC 822 defines the
identifiers in question as containing a local-part and a domain.

RFC 2822 id-right is a problem because it changes the semantics.

>>* local-parts and domain literals need to be canonicalized
>> w.r.t. quoting conventions prior to comparisons. The
>> following are all semantically identical:
>> <foo.bar@[1.2.3.4]> (canonical form)
>> <"foo.bar"@[1\.2.3.4]>
>> <"f\oo.bar"@[1\.2.3.4]>
>> <"f\oo\.bar"@[1\.2.3.4]>
>> <"f\oo\.bar"@[1\.\2.3.4]>
> 
> 
> Yes, that is indeed true within Email, but it is not true (and cannot be
> true) within Netnews.

Content-ID is a MIME production which applies wherever MIME
is used.  The start parameter refers to a content identifier,
as does the cid URI scheme.  Whether they are used in "mail"
messages or "news" messages or even in unrelated formats and
protocols such as HTTP, the syntax and semantics are those
assigned by the MIME RFCs, whether you like it or not.

Date: Tue, 28 Sep 2004 10:40:02 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Nick Ing-Simmons <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Nick Ing-Simmons wrote:
> Bruce Lilly <[email-masked]> writes:
> 
>>Nick Ing-Simmons wrote:
>>
>>
>>>One of the USENET concepts which has translated quite well to mail is 
>>>the use of the References: header to thread mails.
>>
>>The References field was defined in RFC 724 (possibly earlier) which
>>predated Usenet by years.  It was not adopted by Usenet until after
>>RFC 724 had been superseded by RFCs 733 and 822.
> 
> 
> I was refering to the reliable use of message IDs in references field.
> UseNet definitely had that 1st (whatever RFCs may have said).

I'm not convinced of any such reliability, due to malformed
References fields added by some UAs -- which seems to be more
prevalent in news-oriented UAs than in mainstream MUAs.

>>>If there was a clearly defined header that said "you got this mail from 
>>>the list <whatever@somewhere>"
>>
>>You mean something like
>>Return-Path: <[email-masked]>
>>or
>>Sender: [email-masked]
> 
> 
> So the answer is no ;-)

Return-Path certainly provides what you asked for, viz. where
the message came from.  That's not the same thing as a list
submission or subscription address in general (and obviously
isn't in this instance).

>>>it would be trivial to add a
>>>"Reply to list" button to a MUA.
>>
>>Not necessarily. Sometimes there are multiple list expansions.
> 
> 
> So - if the name of the _list_ was in a header "reply to list"
> would go back to the machine hosting the list and be re-expanded.

The point is that you're assuming *one* and only one list,
whereas a message may be copied to multiple lists or be
expanded by one list to mailboxes which include additional
lists.

Now RFC 2369 fields -- when they're used -- might provide
some information, however:
1. they're not always used; messages on this list do not
   have a List-Post field, for example.
2. the presence of those fields is due to list expansion
   software, and therefore provides no indication of the
   author's (or authors') preferences for responses
3. There may be multiple List-Post fields in the case of
   a) submission of the original to two or more disjoint
      lists
   and/or
   b) expansion of one list into another list
   In case b, sending responses to all list submission
   mailboxes will result in duplicates for at least some
   recipients.  There is no obvious indication which of
   several mailboxes should be used or omitted to prevent
   such duplication. In case a, see item #2 above (an author
   might wish responses to go only to one list, or to
   somewhere else entirely).
4. There is no indication of whether or not the author(s)
   and/or any other original message recipients are
   subscribed to any subset of lists indicated by such
   fields, and therefore no reasonable way for a
   respondent to be able to figure out whether or not the
   author(s) or other original message recipients will
   see a response sent only to one or more of the list
   mailboxes, either in a timely manner or ever.

Two conclusions:
1. If an author wishes responses to go to some specific place,
   he needs to indicate so or potential respondents will have
   to play guessing games.  The RFC 2822 Reply-To field has
   the necessary semantics for indicating a recommended list
   of response addresses.
2. If a respondent wishes to send a response somewhere other
   than where the author(s) have recommended, he will have to
   guess what the result will be; he cannot tell whether or
   not an author is subscribed to any list, he may have to guess
   which mailboxes in the original message address fields are
   list addresses, he will be unable to readily determine if
   any mailbox is expanded, or if any mailbox resulting from
   any such expansion will be further expanded.

So while Return-Path, Sender, and List-* fields may be of
some use to recipients for filtering and filing, they really
provide no help for responding.

Cc: ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 28 Sep 2004 10:02:49 -0400
To: Charles Lindsey <[email-masked]>
Sender: [email-masked]

>>> If some member of the list hit his "Reply-to-List" button (expecting 
>>> it to
>>> go to the list) it would go to the author plus the secretary, 
>>> because the
>>> author's clearly expressed intent was that it should not go to the 
>>> list.
>
>> NO.  if the recipient said "reply to list" the reply goes to the list.
>> if the recipient's MUA wants to point out that the author requested 
>> that
>> replies not go to the list, and give the recipient a chance to change
>> his mind about where the reply should go, that's fine.
>
> Not so. The intention of MFT, as currently proposed (that might 
> change),
> is that "reply-to-list" goes, by default, to whatever is in MFT. And 
> the
> intention is that MUAs should implement it that way.

The notion that a recipient's MUA should change its behavior according 
to the whim of some other author was broken with Reply-To and it's 
still broken with MFT.  In all cases the user agent's goal is to serve 
its user.  To do that well it needs to provide _consistent_ behavior, 
not behavior that changes from one message to the next.

Keith

Cc: ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: reply etiquette
Date: Tue, 28 Sep 2004 09:57:26 -0400
To: Charles Lindsey <[email-masked]>
Sender: [email-masked]

Charles,

It is inexcusably rude to reply to someone's message without sending 
the reply to the person who sent the message.  You have done that with 
several of my messages.  I demand an apology.

Keith

Date: Tue, 28 Sep 2004 14:08:30 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Mon, 27 Sep 2004, Charles Lindsey wrote:

> Which existing MUAs have the feature to set the Reply-To field
> "_automatically_" according to the particular list(s) involved?

Depends on how "automatic" you mean. In Pine, you can request this by
providing a list of patterns by which it recognizes messages with
certain characteristics. You can use this to make Pine recognize
messages from mailing lists. Pine can be configured to add Reply-To
and/or other headers, vary the signature in replies, etc, etc. for
messages that match a particular set of patterns.

But is that "automatic"? You do have to set it up.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

To: LIST: [email-masked];
Xref: clerew local.mime:3735
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 28 Sep 2004 10:12:43 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>(Btw, I think what Bruce meant is that if a messages is sent via 
>multiple lists, things tend to break down. One example I've seen 
>recently: "To: [email-masked], [email-masked]".)

It is unlikely that list-expanders will be able to recognise crossposts to
other lists. It is even less likely that recipient MUAs will be able to do
so on their own.

The only place where it is known that a crosspost is occurring is at the
original sender. Therefore, any information to inform subsequent agents
that crossposting is afoot HAS to be placed in the message by the original
sender.

The MFT proposal at least provides a possibility for the original sender
to specify such information. Persuading senders to take advantage of the
facility (or persuading MUA implementors to provide tools to do so) may be
difficult, but that is likely to be true of ANY solution to the
crossposting issue.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Tue, 28 Sep 2004 13:01:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey writes:
> Which existing MUAs have the feature to set the Reply-To field 
> "_automatically_" according to the particular list(s) involved?

Mutt, halfway. You can tell it that when you're reading a special folder 
(say, ~/mail/lists/ietf-822), all replies should get an additional 
header field. One or two lines in .muttrc.

That additional header field can be "x-hi-there" or "reply-to" or 
anything else.

It's about as "automatic" as all other mutt configuration.

Arnt

To: LIST: [email-masked];
Xref: clerew local.mime:3731
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Mon, 27 Sep 2004 11:09:49 GMT
Lines: 22
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>D. J. Bernstein wrote:

>> Any good configuration-sharing tool will also handle Mail-Followup-To.

>Why on Earth would you expect a configuration tool to handle an
>undefined field?

A "good" configuration-sharing tool will handle _any_ field (I suspect a
prime use for such tools is for handling X-fields).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST: [email-masked];
Xref: clerew local.mime:3728
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Reply-To: LIST: <[email-masked]>;
Date: Mon, 27 Sep 2004 11:00:15 GMT
Lines: 49
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>On Thu September 23 2004 10:22, Charles Lindsey wrote:
>> 
>> Some intelligent use of Group syntax is what I have suggested. Getting
>> people to use such a convention might be hard, but publishing the
>> submission list address in the form
>>     LIST: <[email-masked]>;
>> might be a good way to start.

>The display name is intended for display purposes and should not be used
>as a magic token (said intended use would probably fail if encoded). It
>also would not be useful in the presence of multiple lists.

I see nothing in RFC 2822 to indicate how that display-name is intended to
be used. Clearly it is useful to display it for the edification of users
(and that is actually all that is needed in this case to indicate to users
which of the various mailboxes in evidence is/are lists and which are
humans). But there is nothing to preclude MUAs from using that information
for any purpose, and there is no reason why the convention of using it
should not be enshrined in some future standard or BCP.

As to multiple lists, what is the problem? Either the To: field contains
several such LIST groups, or it contains a single LIST group with all the
lists inside it.

>> Just as an experiment, I have configured my system to do that. Let us see
>> how well it propagates.

>It doesn't. In MUAs with a reply-to-list function, which some MUAs have
>and which some participants have suggested, your display name is
>completely ignored.

It will (currently) be ignored as regards where the reply goes to, but it
will not be ignored as regards what goes into the To: (and/or Cc:) of the
reply. I have set the Reply-To of this message in that style, and I would
be surprised if it does not appear in the To: of any reply that you make
to it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST: [email-masked];
Xref: clerew local.mime:3727
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 27 Sep 2004 10:39:27 GMT
Lines: 34
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> If some member of the list hit his "Reply-to-List" button (expecting it to
>> go to the list) it would go to the author plus the secretary, because the
>> author's clearly expressed intent was that it should not go to the list.

>NO.  if the recipient said "reply to list" the reply goes to the list.
>if the recipient's MUA wants to point out that the author requested that
>replies not go to the list, and give the recipient a chance to change
>his mind about where the reply should go, that's fine.

Not so. The intention of MFT, as currently proposed (that might change),
is that "reply-to-list" goes, by default, to whatever is in MFT. And the
intention is that MUAs should implement it that way. I.e. it will go there
_unless_ the recipient take the extra trouble of overriding that default
(most of them won't, but nobody is suggesting that they will not have the
opportunity).

>It is absolutely unacceptable for _anyone_ (the author of an original
>message, or a list, or the recipient's MUA) to override the recipient's
>preference about where a reply goes.

Nobody has suggested that.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST: [email-masked];
Xref: clerew local.mime:3726
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Angle brackets surrounding Content-ID
Date: Mon, 27 Sep 2004 10:31:53 GMT
Lines: 43
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Temporarily leaving aside "strip these angle brackets", there
>are several issues that should be taken into consideration
>when comparing identifiers:

>* domain names are case-insensitive, so "<[email-masked]>"
>  is semantically identical to "<[email-masked]>".  RFC
>  2822 presents a problem here, because a receiver can never
>  be sure whether or not an RFC 2822 id-right is a case-
>  insensitive domain name or something else (which might be
>  case-sensitive).

No, I don't think that is right. An id-right, as defined by RFC 2822, is a
string of characters, possibly subject to special semantics for any
quoted-string or quoted-pair. The suggestion to use a domain name as that
string does not mean that it IS a domain name once copied into an
id-right. It IS now an id-right and is subject to whatever semantic rules
apply to an id-right, and no others.

>* local-parts and domain literals need to be canonicalized
>  w.r.t. quoting conventions prior to comparisons. The
>  following are all semantically identical:
>  <foo.bar@[1.2.3.4]> (canonical form)
>  <"foo.bar"@[1\.2.3.4]>
>  <"f\oo.bar"@[1\.2.3.4]>
>  <"f\oo\.bar"@[1\.2.3.4]>
>  <"f\oo\.bar"@[1\.\2.3.4]>

Yes, that is indeed true within Email, but it is not true (and cannot be
true) within Netnews. Which is why I would like to see that tidied up next
time RFC 2822 comes up for review.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST: [email-masked];
Xref: clerew local.mime:3729
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 27 Sep 2004 11:03:35 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>D. J. Bernstein wrote:

>> The sender wants his MUA to make this request _automatically_ for any
>> message that he sends to various mailing lists. Old message injectors
>> don't have this feature, so they have to be changed.

>Existing UAs do have this feature. It's called setting the content
>of the standard Reply-To field, which has precisely the desired
>semantics as specified in RFC 2822:

Which existing MUAs have the feature to set the Reply-To field
"_automatically_" according to the particular list(s) involved?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST: [email-masked];
Xref: clerew local.mime:3730
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 27 Sep 2004 11:07:08 GMT
Lines: 26
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Nick Ing-Simmons wrote:

>> One of the USENET concepts which has translated quite well to mail is 
>> the use of the References: header to thread mails.

>The References field was defined in RFC 724 (possibly earlier) which
>predated Usenet by years.  It was not adopted by Usenet until after
>RFC 724 had been superseded by RFCs 733 and 822.

The References field as now defined in RFC 2822 is a wholly different
beast to the ones defined in RFC 724 and RFC 822. The syntax is different,
and the semantics is hugely different, being clearly derived from the
Usenet experience.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Tue, 28 Sep 2004 09:46:21 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: 822 <[email-masked]>
cc: Charles Lindsey <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

On Sat, 25 Sep 2004, Bruce Lilly wrote:

> Don't blame MUAs for MTA bugs.  My local file copy's References
> field was exactly 998 octets long (not including the CRLF), which
> is perfectly legal. A copy of that sent through my local MTA came
> back with the Received field in the same state.  A copy sent to
> my ISP's MTA (Exim) came back with line folding inserted after
> the 989th octet (the letter 'a'). Looks like bugs in Exim (989
> instead of 998, and a botched folding algorithm). 

Exim does not deliberately modify message headers or message bodies
apart from the required minimum such as adding Received: and translating
CRLF into LF for local storage. I am firmly of the opinion that messing
around with message content is not the job of an MTA. There is
definitely no code for folding header lines in Exim. I have just double-
checked by sending a message with a References: line that was over 1,000
characters long. (I am the author of Exim, incidentally.)

It is possible for a sysadmin to configure Exim to remove and add header 
lines. It is probably possible to try to make it fold by a sufficiently
hacky configuration, but that's the fault of the writer of the 
configuration, not Exim. I suspect that some other software is involved
at your ISP.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Mon, 27 Sep 2004 14:03:30 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

In principle I mean all internet mail, with only such exceptions that 
have solid justification.

Even though mailing lists users are differerent in principle from the 
general population, I've never found an exception I can formulate and 
justify robustly. Fuzzy exceptions are easy to find. Exceptions based 
on the population of unix types who were on the internet fifteen years 
ago too.

One way to get a proxy for a general list would be to look at all 
incoming mail at a couple of big ISPs in different countries. To the 
extent the user-agent lists match, that should be a decent proxy.

If any big ISPs would play...

Arnt

Date: Mon, 27 Sep 2004 10:58:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Nick Ing-Simmons writes:
> Bruce Lilly <[email-masked]> writes:
>> Not necessarily. Sometimes there are multiple list expansions.
>
> So - if the name of the _list_ was in a header "reply to list" would 
> go back to the machine hosting the list and be re-expanded.

It would have been swell to have had something like that from the start. 
But we didn't. As a retrofit, I don't think it's possible to improve 
much on RFC 2369/2919. Much software doesn't support them and some 
people think they suck, but isn't that always the case for such 
retrofits?

(Btw, I think what Bruce meant is that if a messages is sent via 
multiple lists, things tend to break down. One example I've seen 
recently: "To: [email-masked], [email-masked]".)

Arnt

Cc: Nick Ing-Simmons <[email-masked]>
Subject: Re: Understanding response protocols
To: [email-masked]
Date: Mon, 27 Sep 2004 09:15:46 +0100
From: Nick Ing-Simmons <[email-masked]>
Reply-To: Nick Ing-Simmons <[email-masked]>
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:
>Nick Ing-Simmons wrote:
>
>> One of the USENET concepts which has translated quite well to mail is 
>> the use of the References: header to thread mails.
>
>The References field was defined in RFC 724 (possibly earlier) which
>predated Usenet by years.  It was not adopted by Usenet until after
>RFC 724 had been superseded by RFCs 733 and 822.

I was refering to the reliable use of message IDs in references field.
UseNet definitely had that 1st (whatever RFCs may have said).

>
>> If there was a clearly defined header that said "you got this mail from 
>> the list <whatever@somewhere>"
>
>You mean something like
>Return-Path: <[email-masked]>
>or
>Sender: [email-masked]

So the answer is no ;-)
There is a choice of two fields there and I doubt that 'owner-' 
would be normative in any standard.
Yes my ad. hoc. list scheme does try that...

>
>> it would be trivial to add a
>> "Reply to list" button to a MUA.
>
>Not necessarily. Sometimes there are multiple list expansions.

So - if the name of the _list_ was in a header "reply to list"
would go back to the machine hosting the list and be re-expanded.

Date: 27 Sep 2004 02:21:54 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Arnt Gulbrandsen writes:
> How many per cent of all messages seen on the net does Mutt generate?

Are you asking about Google hits? 442000 for user-agent-mutt, 622000 for
user-agent-mozilla, 129000 for x-mailer-microsoft, and 45900 for
x-mailer-qualcomm, for example.

Or do you mean all mailing-list messages? Weighted by number of
subscribers, or not? Either way, access to the information is difficult.
I can tell you about the lists I read (110535 Mutt messages out of
717790 messages), but of course there are many other mailing lists.

Or do you mean all Internet mail? Here the information is, obviously,
extremely difficult to collect, and the relevance to Mail-Followup-To is
questionable.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Mon, 27 Sep 2004 01:00:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

D. J. Bernstein writes:
> Bruce Lilly writes:
>>  3. The point remains that "Mail-Followup-To" is ignored by the
>>     vast majority of all UAs and by all of the most widely used UAs.
>
> False. Example: Mutt is a widely used MUA that honors Mail-Followup-To.

Mutt is widely used? How many per cent of all messages seen on the net 
does Mutt generate?

Arnt

To: [email-masked]
Cc: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 26 Sep 2004 12:37:12 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> I have examined 1,516 messages which are a collection of messages
> posted to several related announce-only lists plus messages exchanged
> by individuals participating in group discussions over a period of
> several years w/o a mailing list.

Thank you for the concrete information!

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sun, 26 Sep 2004 13:54:53 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Russ Allbery <[email-masked]>
CC: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Russ Allbery wrote:
> Keith Moore <[email-masked]> writes:
> 
> 
>>It might be the case that only a small percentage of users participate
>>in email lists.  It might also be the case that mutt is favored by a
>>fairly narrow class of users who happen to participate on lots of email
>>lists.  But I don't believe it's reasonable to conclude that a
>>significant percentage of people who participate in email lists use
>>mutt.
> 
> 
> Well, statistics have been presented showing that that's the case for one
> pretty broad but mostly technical selection of mailing lists.  What
> statistics do you have to support the alternative position?  You may well
> be correct, but I'd really like to see this argued from the vantage point
> of firm evidence.
> 
> 
>>I don't see "fairly sophisticated users who are on a lot of mailing
>>lists" as the primary audience for this sort of feature.  (where "this
>>sort of feature" is a general improvement in how replies are handled and
>>not something that is specific to lists) I see the audience as "users
>>who use email for more than just occasional personal correspondence".
> 
> 
> I'm skeptical, but it would be nice.  I think that even among that
> audience, you'll find a larger number of mutt users than you seem to be
> expecting.

I have examined 1,516 messages which are a collection of messages
posted to several related announce-only lists plus messages exchanged
by individuals participating in group discussions over a period of
several years w/o a mailing list. These are members of an engineering
professional society unrelated to Internet mail (http://www.smpte.org).
One issues is that not all mailers advertise themselves. Some that do
so use unusual places (e.g. Pine uses the Message-ID field). Among
others, identification may be found in X-Mailer, X-MIMEOLE, User-Agent,
or in one isolated case X-Newsreader fields. Because Message-ID fields
were examined (to find Pine users), there is some remaining cruft.
Messages which could not be attributed to any MUA are grouped together
in a line marked "indeterminate":

    487 Mozilla
    237 Internet Mail Service
    188 Outlook
    120 AT&T Message Center
    102 AOL
     90 Eudora
     67 indeterminate
     45 Lotus Notes Release
     35 Outlook Express
     26 fc
     23 Exchange
     20 Novell GroupWise Internet Agent
     16 Apple Mail
      9 Thunderbird
      7 Atlas Mailer
      6 Entourage
      5 Roving Constant Contact
      3 Springmail
      2 iPlanet Messenger Express
      2 Juno
      1 test
      1 Unknown
      1 OFAAA5FA
      1 OF85256C
      1 OF6C324AB
      1 OF5F926BEC
      1 OF3AD9CEB
      1 Internet Messaging Program
      1 GoldMine
      1 F449LvuKebm4M2S0gUF00000d0b
      1 F42naoBe27dE3Jhv8KT000106ee
      1 F1887LRZY0qVSX2SAEh00010ecf
      1 EMUmail
      1 E187KAc-0005Hg
      1 E17tyFv-0006mU
      1 E17sTLF-0001Ty
      1 E17g6wV-0007EN
      1 E17fb2S-0000do
      1 E17fYh0-0004Ps
      1 Bloomba Professional Edition
      1 7b30e568868c41b584f7cf322ae3a8d
      1 27585ED8A8DCD2118956009027468902BCFF4B
      1 27585ED8A8DCD2118956009027468902BCFF3A
      1 27585ED8A8DCD2118956009027468902BCFF
      1 27585ED8A8DCD2118956009027468902BCFE2C
      1 0I2C00803WCA0Y

Unsurprisingly, mutt isn't even on the list (nor are other character-based-UI
UAs such as Pine and ELM).  The ones identified as "fc" all came from
Message-ID fields and originated at PBS stations; probably an artifact of
whatever MSA/MTA generated Message-IDs. Many of the one-offs are a
result of Message-IDs. Microsoft's products (Outlook, Outlook Express,
Internet Mail Service, Exchange, Entourage) dominate, followed fairly
closely by Mozilla/Thunderbird, with others all fairly far behind.

The same type of analysis of 2,538 recent messages to this mailing list
results in:

    506 Mozilla
    296 indeterminate
    225 Sylpheed
    220 NN
    204 Gnus
    122 Apple Mail
    117 Eudora
    107 Mutt
     89 Pine
     60 The Bat
     41 Outlook Express
     32 Mulberry
     31 OpenXP
     30 Outlook
     28 MimeOLE
     28 KMail
     27 CrossPoint
     14 BatIMail
     10 Lotus Notes
      9 exmh
      9 dtmail
      9 Id
      8 Ximian Evolution
      8 Opera
      8 MR
      8 Exchange
      6 Forte Agent
      5 Z-Mail
      4 PocoMail
      4 Internet Mail Service
      3 mh-e
      3 SquirrelMail
      3 MH-E
      3 Eudora Light
      3 ELM
      2 iqHT6v6wOkZrfnWa4MgHcQ
      2 VM
      2 Mailsmith
      2 Danger Service
      2 CMM
      2 AuvUFTP2Z9Wrz0jrlxdO6Q
      2 01L5QIC3JDLW00Q4RU
      2 01L5QEZ7OYU400Q4RU
      2 01L5JEZZ5EYS00Q4RU
      2 01L5IFYRHAMK00Q4RU
      1 zwZ0W6ZvC
      1 zn9LchILJcKiJfYJ9kyQ8A
      1 z3J6mXZgOKuHdLmvWl5zQw
      1 xqRenBEr5R5kjjJ6Xlpwgw
      1 xaSGldTLm7iOF8wLX6jSrQ
      1 wl0Ru3aMoZ4VmGhmNd1PTg
      1 vyDCOksjW0T5JTUD+zj
      1 vblVCzk7yuOTmh4aNJKFdQ
      1 uUJgMT7Ciu7lztcHxy0FZg
      1 tDL298uKO7MOehILJ2WeWw
      1 tC4hDQnOAEZqtwQUHxZseQ
      1 t5P6YRORQ6bwogKYdWq1ww
      1 sybUXrBvSS0e5J5fjwan1Q
      1 sn21AhOGvpBfnU55O7Wumg
      1 prYqvhAU+WKtGdjb
      1 p06110437bd3d5d396de
      1 p06110411bd46993ab
      1 p06110410bd7887b449c
      1 p0611040fbd492cde8b
      1 p0611040bbd4902ddb2d
      1 p0611040abd461846772d
      1 p06110409bd4614b6a
      1 p06110406bd5ca1d404a
      1 p06110404bd5f11d52c
      1 p06110404bd5dea7e8c
      1 p06110401bd62d06b426d
      1 p0601020abc2d73526fd
      1 p06002021bbc4cab
      1 p05200f24bb99cdacaabd
      1 p05200f23bb99ccf980ea
      1 p05200f22bb99caff09fa
      1 p05200f14bb9bec7f080a
      1 p05200f0cbb9b89b0d
      1 p05200f0bbb9b88ab938c
      1 p05200f0bba7680f98ef
      1 p05200f09bb9b861df9f
      1 p05200f07bb98c00f
      1 p05200f03bb9ddd0137f
      1 p05200f02bb9ddc3808c
      1 p05200f02ba91409579cd
      1 p05200f01bb9b7c55adb
      1 p05200f00bb9b7a713c
      1 p05200e26b9ecc4e303e
      1 p05111a3fb9708269ae
      1 p05111a1cb9748dae
      1 p05111a0fb97a161e0af
      1 p05111a0eb9745555510d
      1 p05111a08b979f6759ee
      1 p05111a08b971d9cc
      1 p05111a02b979cba
      1 p0510034cb98a750b5df
      1 p0510033db98a5c7c98f
      1 p0510032bb93684d40eb
      1 p0510031fb971d00ea5e
      1 p0510031db9c2ed7c528f
      1 p05100311b9f9bca44bfb
      1 p0510030bb9c72a08220a
      1 p0510030ab9ed7c1226d
      1 p0510030ab96db70d
      1 p05100309b93a2c722d1a
      1 p05100307b975886d19a
      1 p05100306b9858ae26f9c
      1 p05100305b9f5285a855b
      1 p05100304b9f69017587e
      1 p05100304b
      1 p05100303b9c410f400cd
      1 p05100303b937439f036f
      1 p05100302b9ac8a2b6b4b
      1 o7jrZVLZd6FgLOH44VcKrQ
      1 neJF6+CS41jHaqMBlY5SAw
      1 kkg5WVwiVSJhjO3CRwJ8sw
      1 kJSYnkehT+XlAJhd+WFXPA
      1 jcOawBbwmd+qp3X6vCA9wQ
      1 iuBsACA1THJrX5vkWtdnZA
      1 h7LVXOlDw
      1 ggchXeRpHsSh
      1 gPUjz2LmGSGnDDQZGeIDgg
      1 fiZK7lbL8FGIdRDHCGmSEA
      1 cLYarZs
      1 aaU2nXcISyi2O16dFAa+dg
      1 aFVEHUCz4vhfZ1BF7VB9wg
      1 a06200a1abd
      1 a06200a06bd5514cf
      1 a06200a05bd5550ce801a
      1 a06000806ba84764bf7eb
      1 YvJ8mKdtbZCPoT3jwVyO0Q
      1 X
      1 VM6xUI48UlTorJXqxfy1iQ
      1 VD0yJWnoH68BDsLtyBBkeg
      1 UkgPy4n1Cl6ncox0Gr7wfQ
      1 UhvnO6pBCBqf2qh75fWJew
      1 Turnpike Integrated
      1 SxZVVwZS5y7TrNpYc+pBjQ
      1 Q9KgRc2Hz1Pk3+n+4RiKEw
      1 PlW8RRS+4JmrXNTlASBtIQ
      1 PSs936ZcbAPmNty5tLclmA
      1 OpPGiAjsOuQ5zgojCvdmcQ
      1 OIyLV7qntjxEzFT1Gw9qGQ
      1 NA4Icnc
      1 Mailsmith Prerelease
      1 MailManager
      1 MMail
      1 MB5TXyMPE3DdvF8zxs0w+g
      1 LlbzzgSu8AhS+pAGh2Dktw
      1 JiOT9YrBJ2kP5pjbaHPDTQ
      1 JX1fmb8yW8DwX79vDkXOvw
      1 IGNkHlX2RIC5Gv0wgJUBGA
      1 HuU1P1DxTyF2kH+Insj8JA
      1 HnMsMI
      1 HM
      1 GrlVRieTpdev7dSqW1k+rw
      1 GUkpu9mSQXLJX
      1 GLMwTG0TieET8A6W53kYvg
      1 Entourage
      1 E7liF9C6446UclpAxR60Qg
      1 E1A5Qly-0001uz
      1 CnENpYZHSfF7oqj6x2nVFw
      1 CXYZ9TunsF0hbc4nRxlidA
      1 CXVLOi727rQudKFH0OpdNw
      1 CLIE Mail
      1 C2UXZ8HuE3NZm2zjleB8iA
      1 BnOPM0iqOnFVUMgIRZ1qsA
      1 B6knpGBu36fZBOwGqIW8fg
      1 AhNFVsj9hZKsigvgZmJFog
      1 906ByjdrGUtL9vQjTs+9KQ
      1 8LEtQCmIAahbHMt36t1tHA
      1 7WsUCIZ
      1 6bMhvPKpbZIIEHDW6ayBrw
      1 4NTjeJVT+0GxTVbd
      1 3ShvKE7rMH8DudtVayqwig
      1 3JZVXnN
      1 1h57AkwLdShKkH1q1I30gw
      1 1aYGbwWRQLpfd4amXcvyBg
      1 02gN6yDPJv+bB4TG5baCjw
      1 01LEEM2T5AT000005R
      1 01LEAB1LVYC000005R
      1 01LE5U6FDLGA00005R
      1 01LE5OQV33N800005R
      1 01LE5MCPBV8G00005R
      1 01LE1VGVOAJM0087C
      1 01LE1V57L3SM0087C
      1 01LE1UZBL64A0087C
      1 01LE1UW084320087C
      1 01LDX31R23EG00005R
      1 01LDTVI1ZMY000005R
      1 01LDTS0X3IE200005R
      1 01LDSZHJYST000005R
      1 01LDSX361EOI00005R
      1 01LDQ56NAXTQ00005R
      1 01LDPF21Z0LQ00005R
      1 01LDP8KE75V400005R
      1 01LDMAZLZG9I0087C
      1 01LDM3NWP1E000005R
      1 01LDM27HCUCO00005R
      1 01LDM23SDIVE00005R
      1 01LD804Z1D2U0061HF
      1 01LD1S0HX57M00005R
      1 01LCN9SPG92Q00005R
      1 01LCJ207ZH9E0061HF
      1 01L5QF7VWKYQ00Q4RU
      1 01L5PLEN33PK00Q4RU
      1 01L5PGPQ2C4S00Q4RU
      1 01L5P3KCJL9O00Q4RU
      1 01L5O60KT45M00Q4RU
      1 01L543ENSLVY00HOW
      1 01L51B2QN2P200NZA
      1 01L4Z0G3HR1W0134RS
      1 01L34N7Q0VXM00HOW
      1 01L33T4X9MMO00HOW
      1 01L2PCC4JBE400HOW
      1 01L2CXCUEAFE00Q4RU
      1 01L1CIWCV8UK002O3W
      1 01L1B5KHQCSS00AIOP
      1 01L16WQ9CGGE00AIOP
      1 01L16ELBAZKM00AIOP
      1 01L16ALA0SA800AIOP
      1 01L15JBKZI4600UICS
      1 01L146MFQL3U00AIOP
      1 01KXFX5UDAES00D1EZ
      1 01KWXELT5VCQ00D1EZ
      1 01KWXCKO7NZA00CUGD
      1 01KVGJD5GAD8007FVT
      1 01KUWU7B2U6I002DEU
      1 01KUWSYUIBQW002DEU
      1 01KT33NZM1YG002DEU
      1 01KT20NGV54G002DEU
      1 01KT0IRFG4WQ002O3W
      1 01KT0EFA1708002O3W
      1 01KT08A2WHUO007FVT
      1 01KSZ8VDV80C002DEU
      1 01KSZ65K873A002DEU
      1 01KSXWTM9YL6002O3W
      1 01KSXQ420128002O3W
      1 01KSW6IRJIEU002DEU
      1 01KSW57NBMJU002DEU
      1 01KSUQ3YIS6O009UB
      1 01KSSWPNAZS0002DEU
      1 01KSS57SEMEQ00AE
      1 01KSS4VOC3UW00AE
      1 01KSQRPDDTPE002DEU
      1 01KSQDUOCSEE002DEU
      1 01KSPRDKTJ7200AE
      1 01KSPHV89YF2002O3W
      1 01KS8NG6MPA2009UB
      1 01KS5OP8K4RO002DEU
      1 01KS089V3Y40002DEU
      1 01KRLYIRSE3W00AE
      1 01KRKJ7GQ3PM009UB
      1 01KRB7W73PXI00AE
      1 01KRAO4HIJ9200AE
      1 01KQXJ08MY2E00AE
      1 01KQXI2CVYEC00AE
      1 01KQXG8HY0CM00AE
      1 01KQTWL8HOKY009OMN
      1 01KQT7J5O71Y009OMN
      1 01KQSPWQZ4GI009OMN
      1 01KQSMDJEP9A009OMN
      1 01KQR2TXIGII009OMN
      1 01KQPSV8ZVPS009OMN
      1 01KQ684QLEX2001ZTY
      1 01KPBK83BHRI004VR
      1 01KOYW4ODO5U004XU
      1 01KOYU1DXQOI004XU
      1 01KOT9MFPS1C004XU
      1 01KNDO3BOV7600628S
      1 01KLJZFE40HA0001B
      1 01KLBOH06IB60001B
      1 01KLAG31RZ4A0001B
      1 01KKZOLNW0UA0001B
      1 01KIVW17LTEU000NJJ
      1 01KIUYLDQDJ0000NJJ
      1 01KIRL1NPHEQ001HMU
      1 01KIKXB7DOIA0001B
      1 01KIJ96XDENO0001B
      1 01KIJ8EYUI4U0001B
      1 01KHUAVKP2CW000ASW
      1 +zqc
      1 +w9mA+77oX2cNSsgf1BqZg

Mutt accounts for about 4% of the messages, far behind Mozilla, Microsoft's
Outlook variants (Outlook, Outlook Express, MIMEOLE, Exchange, Internet Mail
Service, Entourage, etc.), Eudora variants and look-alikes (e.g Sylpheed).

Subject: Fwd: Re: Understanding response protocols
To: [email-masked]
Date: Sun, 26 Sep 2004 09:19:34 +0100
From: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

Forwarded for Frank Ellerman, who has no other access to this list.

I suspect his "Original-To: LIST:[email-masked];" was an artefact of  
Gmane, and reflects the genuine "To:" header as received there.

------- Forwarded message -------
From: "Frank Ellermann" <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 24 Sep 2004 20:01:18 +0200

Charles Lindsey wrote in <ietf-822.imc.org>:

> publishing the submission list address in the form
>     LIST: <[email-masked]>;
> might be a good way to start.
> Just as an experiment, I have configured my system to do
> that. Let us see how well it propagates.

Hi, here's the result of your experiment as seen on GMaNe:

| Original-To: LIST:[email-masked];

For the complete list of all headers see below.  I'm quite
happy with my selection of 3 buttons at GMaNe:

Re:News => To list.  I can't use that for ietf-822, because
            I'm not subscribed, and "write-only" access on
            majordomo lists works only after a manual
            intervention (= bother Paul in the case of imc)
Re:Mail => That's what you found in your inbox, feel free
            to forward if it's relevant for the discussion.
Re:Both => Guess.

So behind a mail2news gateway like GMaNe the "3rd button"
is already available on my client (Netscape 2.02, 1996).

I've used Re:Both less than 10 times, and in almsost all
cases it was an error on my side.

                       Bye, Frank

---------------------------------------------------------
Path: main.gmane.org!not-for-mail
From: "Charles Lindsey" <[email-masked]>
Newsgroups: gmane.ietf.rfc822
Subject: Re: Understanding response protocols
Date: Thu, 23 Sep 2004 14:22:41 GMT
Lines: 23
Sender: [email-masked]
Approved: [email-masked]
Message-ID: <[email-masked]>
References:  
<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><7WsUCIZ5/9iz5hktp/[email-masked]><[email-masked]>  
<[email-masked]>
NNTP-Posting-Host: deer.gmane.org
Mime-Version: 1.0
X-Trace: sea.gmane.org 1095992618 5727 80.91.229.6 (24 Sep 2004 02:23:38  
GMT)
NNTP-Posting-Date: Fri, 24 Sep 2004 02:23:38 +0000 (UTC)
Original-X-From: [email-masked] Fri Sep 24 04:23:23 2004
Original-Received: from above.proper.com ([208.184.76.39])
         by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian))
         id 1CAfk2-0004on-00
         for <[email-masked]>; Fri, 24 Sep 2004 04:23:22 +0200
Original-Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
         by above.proper.com (8.12.11/8.12.9) with ESMTP id i8O2CTQf035652;
         Thu, 23 Sep 2004 19:12:29 -0700 (PDT)
         (envelope-from [email-masked])
Original-Received: (from majordom@localhost)
         by above.proper.com (8.12.11/8.12.9/Submit) id i8O2CTpB035651;
         Thu, 23 Sep 2004 19:12:29 -0700 (PDT)
[email-masked] using -f
Original-Received: from smtp801.mail.ukl.yahoo.com  
(smtp801.mail.ukl.yahoo.com [217.12.12.138])
         by above.proper.com (8.12.11/8.12.9) with SMTP id i8O2CSho035641
         for <[email-masked]>; Thu, 23 Sep 2004 19:12:28 -0700 (PDT)
         (envelope-from [email-masked])
Original-Received: from unknown (HELO  
host81-144-75-20.midband.mdip.bt.net) ([email-masked]@81.144.75.20 with  
poptime)
   by smtp801.mail.ukl.yahoo.com with SMTP; 24 Sep 2004 02:12:18 -0000
Original-Received: (from chl@localhost)
         by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8NGoAK21358;
         Thu, 23 Sep 2004 17:50:10 +0100 (BST)
Original-Received: (from news@localhost)
         by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8NGCP220738
         for LIST; Thu, 23 Sep 2004 17:12:25 +0100 (BST)
Original-To: LIST:[email-masked];
Original-Xref: clerew local.mime:3693
Original-Newsgroups: local.mime
Original-Path: clerew!chl
X-Newsreader: NN version 6.5.2 (NOV)
Original-Lines: 25
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
Xref: main.gmane.org gmane.ietf.rfc822:10578
X-Report-Spam: http://spam.gmane.org/gmane.ietf.rfc822:10578

In <[email-masked]> Nick Ing-Simmons  
<[email-masked]> writes:
[...]

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: 26 Sep 2004 04:09:34 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Bruce Lilly writes:
> Because different UAs have different feature sets, they necessarily
> require separate configuration.

Your argument is disproven by, for example, clients using IMSP to share
address books.

Your argument is also, on its face, mind-bogglingly stupid. Even if you
had never heard of shared configuration before this, how could you claim
that it can't be done?

> Reconfiguration every time a list subscription changes. A PITA.

You aren't answering the question. Yes, changing a list subscription
takes effort; why do you think this is a problem with Mail-Followup-To?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Sat, 25 Sep 2004 19:07:10 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> The proper solution for that is for the author to configure his MUA to
> always use [email-masked] as his From/Reply-To address (most MUAs provide
> that config option, which would probably also be automatically used within
> MFT is the agent was smart enough to be MFT aware.

You are presuming a fixed configuration, which isn't always appropriate,
e.g. for mobile users.  Some UAs take a domain name as provided by an
OS function call, which in turn may have been set via DHCP or a similar
mechanism.

>>It seems to work fine for others that use it also.
> 
> 
> Nobody on this list is using it except for you.

News flash: this isn't the world's only mailing list.

Date: Sat, 25 Sep 2004 18:59:01 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Nick Ing-Simmons <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Nick Ing-Simmons wrote:

> One of the USENET concepts which has translated quite well to mail is 
> the use of the References: header to thread mails.

The References field was defined in RFC 724 (possibly earlier) which
predated Usenet by years.  It was not adopted by Usenet until after
RFC 724 had been superseded by RFCs 733 and 822.

> If there was a clearly defined header that said "you got this mail from 
> the list <whatever@somewhere>"

You mean something like
Return-Path: <[email-masked]>
or
Sender: [email-masked]

> it would be trivial to add a
> "Reply to list" button to a MUA.

Not necessarily. Sometimes there are multiple list expansions.

Date: Sat, 25 Sep 2004 18:08:26 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "D. J. Bernstein" <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

D. J. Bernstein wrote:
> Bruce Lilly writes:
> 
>>Something like MFT, for instance, requires changes to senders' and
>>recipients' UAs
> 
> 
> One of the basic goals here is for followups to exclude the sender's
> address upon request from the sender.

Then the non-standard Mail-Followup-To field fails to meet that goal,
since it doesn't specify a list of addresses (or a single address)
to exclude from anything.

Now you might have said that a goal is for the original message
author to be able to indicate a preference for where responses
*should* go.

> The sender wants his MUA to make this request _automatically_ for any
> message that he sends to various mailing lists. Old message injectors
> don't have this feature, so they have to be changed.

Existing UAs do have this feature. It's called setting the content
of the standard Reply-To field, which has precisely the desired
semantics as specified in RFC 2822:

   When the "Reply-To:" field is present, it
   indicates the mailbox(es) to which the author of the message suggests
   that replies be sent.

> This has nothing to do with the choice of protocol. Every protocol needs
> this MUA support. Criticizing Mail-Followup-To on this basis is silly.

The difference is that Reply-To has long been defined with the
desired semantics, and is already supported by UAs. Mail-Followup-To
isn't even defined properly.

> As for the recipient's MUA: Yes, Mail-Followup-To needs some changes,
> but every one of your proposals requires vastly more changes. Again,
> criticizing Mail-Followup-To on this basis is silly.

You are wrong. Because Reply-To is and has long been a standard
field, nothing needs to change in UAs. Or MTAs or MSAa.

>>and to any MSAs and MTAs that rewrite address fields.
> 
> 
> At this point you're inventing problems that don't exist. The software
> that creates Mail-Followup-To is responsible for using fully-qualified
> domain names.

It is often the case that transport modifies domain names in addresses
for various reasons -- to hide internal host names, to accommodate
domain name changes when a company or organization is acquired by
or merges with another organization or company, etc.

> Subsequent transports aren't expected to, and shouldn't,
> rewrite Mail-Followup-To.

The ostrich approach is rarely successful (even for ostriches).

Date: Sat, 25 Sep 2004 17:51:58 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "D. J. Bernstein" <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

D. J. Bernstein wrote:
> Bruce Lilly writes:
> 
>>Some people use multiple UAs, possibly at multiple locations. Anything
>>that requires extensive configuration is a problem.
> 
> 
> Even without Mail-Followup-To, having to manually configure several MUAs
> is a pain for the user. These users need configuration-sharing tools.

There are a couple of cases worth mentioning:
1. multiple copies on different hosts of the same type of MUA. These
   can usually be handled by copying some sort of configuration file.
2. different UAs, whether on one host or different hosts. Because
   different UAs have different feature sets, they necessarily
   require separate configuration.

> Any good configuration-sharing tool will also handle Mail-Followup-To.

Why on Earth would you expect a configuration tool to handle an
undefined field?

>>Also, some people read lists via a web archive; an MUA has no way to
>>determine that.
> 
> 
> If the user wants to set Mail-Followup-To for a list, he tells the MUA
> about that list. End of problem.

If he is using some obscure UA that actually notices that non-standard
field. *And* if everybody else also does.

> Yes, there are many situations where the MUA can reasonably do this by
> default, saving even more time, but we're talking about a trivial amount
> of user effort either way. This is once per list, not once per message!

Once per UA, per user, per list. That's still a lot of configuration
for a user who uses multiple UAs and subscribes to multiple lists.
There's no guarantee that any implementation will be able to
appropriately handle messages sent to multiple lists, and issues
other than mailing lists aren't addressed at all.

>>And people change mailing list subscriptions (e.g. when they go on
>>vacation).
> 
> 
> Someone who doesn't really monitor the list probably isn't setting
> Mail-Followup-To in the first place. Anyway, what's your point?

Reconfiguration every time a list subscription changes. A PITA.

Date: Sat, 25 Sep 2004 17:02:54 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>, 822 <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
> 
> You want to take a close look at the References field in your message. It
> was 989 characters long, and ended with "<[email-masked]!" followed
> by a folded " n.ac.uk>" on the next line.  Also, it was full of TABs where
> it had evidently been folded before during its travels, but the folding
> had been systematically undone by some system somewhere. So there are two
> buggy MUAs somewhere on this list.

Don't blame MUAs for MTA bugs.  My local file copy's References
field was exactly 998 octets long (not including the CRLF), which
is perfectly legal. A copy of that sent through my local MTA came
back with the Received field in the same state.  A copy sent to
my ISP's MTA (Exim) came back with line folding inserted after
the 989th octet (the letter 'a'). Looks like bugs in Exim (989
instead of 998, and a botched folding algorithm). My copy of the
message from the list expander had an extra exclamation point
added at the 990th octet (either that differs from yours or you
miscounted).  I'm not sure where that came from. There were tabs
in the single References field line in your message which I
responded to.  I haven't traced back to determine if there had
ever been line folding; in any case unfolding is perfectly legal
when done properly, so that's immaterial.

Date: Sat, 25 Sep 2004 15:20:37 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore wrote:
> 
>> I don't follow that; which part of the specification do you
>> believe is responsible for failure of some UAs to display the
>> field?
> 
> 
> The part that doesn't say that it needs to be obvious to the recipient
> that replies aren't going to the recipient list of the original message.

UI behavior is rarely prescribed.  RFC 2822 is a message format
specification, not an MUA UI design guide. Likewise RFC 2821 is
a message transfer protocol specification, as are the corresponding
RFCs for POP variants, IMAP variants, NNTP, LMTP, etc.  So if
there were to be such a UI design guide for MUAs, it would be
some additional document. If an RFC, probably an Informational
one rather than Standards Track.

>>> These exist regardless.  By that argument, we don't need reply-to or
>>> mail-followup-to or any other header field to affect how replies are
>>> addressed.
>>
>>
>> No, that's not the argument. You seem to be conflating the
>> recipient list with the indication of intent.
> 
> 
> You seem to be separating them.  This increases the chance that a vital
> piece of information will be missed because the recipient has to look in
> two places.

There has never been and is not now any place where (from a protocol
point of view) the sender's intent is indicated -- so there's nothing
in the protocol to "separate".  Mind you, the specific suggestion was
that an author could choose to use any of the human-readable places
where intent could be indicated, for the benefit of human respondents.

>>> It could be because
>>> the sender is pointing to an alternate address for himself - say
>>> because he wants to get replies on his PDA.  Or it could be because the
>>> sender thought replies should go to his secretary, or to a list, or
>>> somewhere else.
>>
>>
>> Perhaps he only wants responses sent to his PDA (or secretary)
>> for a limited period of time.  Perhaps he expects different
>> recipients to respond to different addresses.  I don't believe
>> it practical to devise a way to handle the myriad of
>> circumstances that individual authors might under some
>> situations like to express -- at least not without adding
>> more confusion to the situation (which languages should
>> the authors desires be expressed in, which charsets, what
>> formats should be used for date and time, how should
>> precedence relationships be expressed, etc.).
> 
> 
> Having too little information is confusing because it's ambiguous. 
> Having too much information is confusing because it's complex.
> 
> The simple solution is to let the author supply text  that describes why
> the recipient should or should not use a particular reply address, since
> the decision is going to be have to be made by a human recipient (rather
> than his MUA) anyway.

1. which recipient (any given message may have many recipients)
2. text in which language(s)?
3. text in which charset(s)?
4. if he writes something like "reply to [email-masked]' if before
   12/11/10 and to [email-masked]' after that date", is the date in
   question in October, or November, or December, and which day
   of the month in which year (and century)?

Simply allowing an author to supply some text doesn't necessarily
clarify matters for all recipients, doesn't simplify matters, and
requires substantial (most likely manual) input from the author,
requires that such text be presented to recipients, and requires
recipients to be able to comprehend the intent.

> Not in detail.  In brief - it affects the vast majority of MUAs out
> there, and it makes existing uses of reply-to much less reliable.
> 
> My transition model is that, at least for many years, recipient MUAs
> need to keep honoring Reply-to (at least in the sense that they make the
> recipient aware that reply-to was used and give him the chance to
> explicitly reply to that address) _unless_ the sender of the message
> also asserted whatever new reply request gets adopted.   If we define a
> new reply request field, we can make sure that existing uses of reply-to
> don't fail.  If we redefine reply-to to behave differently (or to be
> ignored), those existing uses will fail.

I'm not proposing any such redefinition; I propose the same syntax
and semantics specified in RFC 2822.

>>> My sense is that that answer doesn't sound good to lots of people.
>>> I'm still trying to understand why.   I think there are at least
>>> two issues here.  One is that it requires substantial changes to
>>> existing message stores (if you built one from scratch to handle this it
>>> would be fairly easy).
>>
>>
>> As mentioned, Cyrus IMAP already has a configurable option
>> for this (implemented in the message store).
> 
> 
> so all we have to do is get everyone to switch to Cyrus, and then [...]

No, I was merely pointing out that there exists at least one
implementation (a widely used one at that) which provides a
means to eliminate duplicates at the message store. Duplicate
elimination at an MUA raises several issues, e.g. *which* MUA
(many people use multiple UAs), where is the duplicate actually
eliminated from if not the message store (eliminating duplicates
from a private stash in a proprietary format still leaves any
duplicates that might be in the real message store), etc,

> nothing says there can't be multiple ways of suppressing duplicates.  it
> should be possible to arrange that they won't interfere with each
> other.  the user with the UA or MS that suppresses duplicates can then
> choose whether or not to originate mail with the mechanism that
> suppresses duplicates on replies to lists.

So all we have to do is change every UA (and probably many MTAs
as well)?

> heck, I can't even get my home ISP to support IMAP/POP over SSL or TLS -
> which EVERYBODY should be doing.   (and by most metrics they are one of
> the better ISPs in the US)  I don't imagine that I'll get them to
> support duplicate suppression anytime soon.  But if someone adds
> duplicate suppression to any of several different MUAs, I can install
> that MUA on my machines and the fact that my ISP doesn't run the message
> store like I want them to becomes irrelevant.

Leaving aside secure transport, switching to a single MUA that
supports one particular feature means living with any peculiarities,
bugs, security weaknesses, etc. that are characteristics of that
particular MUA, as well as having to live without any features which that
MUA does not support.

>>>> Oh! Have you never sent a response to the mailbox in the From
>>>> field as well as the Reply-To address(es) when Reply-To was
>>>> present?
>>>
>>>
>>> Perhaps, but it's been extremely rare - and I probably only did this
>>> when the Reply-To addresses were redundant with other addresses
>>> that were already in the recipient list.
>>
>>
>> That wouldn't explain including the From field mailbox when
>> it was not present in To or Cc.
> 
> 
> what does that have to do with the question?  (or maybe this is a rathole?)

Well the specific question (still quoted above) was about using
the From field mailbox(es) in addition to Reply-To address(es),
and was unrelated to To and/or Cc fields.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Understanding response protocols
Date: Sat, 25 Sep 2004 13:59:01 -0400
Sender: [email-masked]

On Thu September 23 2004 10:22, Charles Lindsey wrote:
> 
> In <[email-masked]> Nick Ing-Simmons <[email-masked]> writes:
> 
> >To this end MFT is a useful addition to the available information,
> >but getting concensus on how you identify the mailing list in
> >the To Cc forest is probably more useful.
> 
> Some intelligent use of Group syntax is what I have suggested. Getting
> people to use such a convention might be hard, but publishing the
> submission list address in the form
>     LIST: <[email-masked]>;
> might be a good way to start.

The display name is intended for display purposes and should not be used
as a magic token (said intended use would probably fail if encoded). It
also would not be useful in the presence of multiple lists.

> Just as an experiment, I have configured my system to do that. Let us see
> how well it propagates.

It doesn't. In MUAs with a reply-to-list function, which some MUAs have
and which some participants have suggested, your display name is
completely ignored.  Neither reply-to-author nor a middle repsonse would
use it.  A broad response could be edited by the user (indeed, in the case
of your message it would *require* hand-editing due to the Newsgroups
field pointing to a nonexistent newsgroup), so could easily be eliminated.

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 24 Sep 2004 11:51:26 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> you don't have firm evidence either, because you don't have anything
> close to a random sample.  statistics that aren't representive of what
> you are trying to measure are meaningless.

Good point; I can't really use evidence of the case that I think is most
typical to prove to you that it's the most typical.  :)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 24 Sep 2004 14:26:57 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> Keith Moore <[email-masked]> writes:
> 
> > It might be the case that only a small percentage of users participate
> > in email lists.  It might also be the case that mutt is favored by a
> > fairly narrow class of users who happen to participate on lots of email
> > lists.  But I don't believe it's reasonable to conclude that a
> > significant percentage of people who participate in email lists use
> > mutt.
> 
> Well, statistics have been presented showing that that's the case for one
> pretty broad but mostly technical selection of mailing lists.  What
> statistics do you have to support the alternative position?  You may well
> be correct, but I'd really like to see this argued from the vantage point
> of firm evidence.

me too.  if I figure out a way to get firm evidence I'll let you know.

you don't have firm evidence either, because you don't have anything 
close to a random sample.  statistics that aren't representive of what
you are trying to measure are meaningless.

--
Nero fiddled.  Bush read _My Pet Goat_.

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 24 Sep 2004 11:17:28 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> It might be the case that only a small percentage of users participate
> in email lists.  It might also be the case that mutt is favored by a
> fairly narrow class of users who happen to participate on lots of email
> lists.  But I don't believe it's reasonable to conclude that a
> significant percentage of people who participate in email lists use
> mutt.

Well, statistics have been presented showing that that's the case for one
pretty broad but mostly technical selection of mailing lists.  What
statistics do you have to support the alternative position?  You may well
be correct, but I'd really like to see this argued from the vantage point
of firm evidence.

> I don't see "fairly sophisticated users who are on a lot of mailing
> lists" as the primary audience for this sort of feature.  (where "this
> sort of feature" is a general improvement in how replies are handled and
> not something that is specific to lists) I see the audience as "users
> who use email for more than just occasional personal correspondence".

I'm skeptical, but it would be nice.  I think that even among that
audience, you'll find a larger number of mutt users than you seem to be
expecting.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 24 Sep 2004 14:11:15 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> I really think both you and Bruce are off-target where it matters
> here. The vast majority of users, the people who are highly unlikely
> to be using something other than Outlook or AOL's mail client and are
> just mailing back and forth with people at work or family or friends,
> are also rarely in situations where anything that we're discussing
> even matters to them.
> 
> If you look at the primary audience for this sort of feature, namely
> fairly sophisticated mail users who are on a lot of mailing lists,
> mutt is*extremely* common.  If you're trying to come up with something
> that would be useful for the average Outlook user, I think you're
> wasting your time; they don't use e-mail in a fashion as to make any
> of this relevant to them.

It might be the case that only a small percentage of users participate
in email lists.  It might also be the case that mutt is favored by a
fairly narrow class of users who happen to participate on lots of email
lists.  But I don't believe it's reasonable to conclude that a
significant percentage of people who participate in email lists use
mutt.

Nor do I believe it is reasonable to assume that Outlook users are
unlikely to use mailing lists.  I participate on several non-technical
email lists that have Outlook users on them.  (as well as AOL,
hotmail, yahoo mail, and a surprising number of gmail users).  And in
my experience these people do have strong opinions about where 
replies should go (no, they don't all agree).

I don't see "fairly sophisticated users who are on a lot of 
mailing lists" as the primary audience for this sort of feature.
(where "this sort of feature" is a general improvement in how
replies are handled and not something that is specific to lists)
I see the audience as "users who use email for more than 
just occasional personal correspondence".

Keith

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 24 Sep 2004 10:48:30 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> False. Example: Mutt is a widely used MUA that honors Mail-Followup-To.

> Bruce was correct.  Mutt's deployment relative to other UAs is
> insignificant.

I really think both you and Bruce are off-target where it matters here.
The vast majority of users, the people who are highly unlikely to be using
something other than Outlook or AOL's mail client and are just mailing
back and forth with people at work or family or friends, are also rarely
in situations where anything that we're discussing even matters to them.

If you look at the primary audience for this sort of feature, namely
fairly sophisticated mail users who are on a lot of mailing lists, mutt is
*extremely* common.  If you're trying to come up with something that would
be useful for the average Outlook user, I think you're wasting your time;
they don't use e-mail in a fashion as to make any of this relevant to
them.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 24 Sep 2004 13:13:04 -0400
From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> 
> Bruce Lilly writes:
> > 3. The point remains that "Mail-Followup-To" is ignored by the
> >    vast majority of all UAs and by all of the most widely used UAs.
> 
> False. Example: Mutt is a widely used MUA that honors Mail-Followup-To.

Bruce was correct.  Mutt's deployment relative to other UAs is insignificant.

Date: Fri, 24 Sep 2004 13:11:48 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], LIST: [email-masked];
Subject: Re: Understanding response protocols
Sender: [email-masked]

> If some member of the list hit his "Reply-to-List" button (expecting it to
> go to the list) it would go to the author plus the secretary, because the
> author's clearly expressed intent was that it should not go to the list.

NO.  if the recipient said "reply to list" the reply goes to the list.
if the recipient's MUA wants to point out that the author requested that
replies not go to the list, and give the recipient a chance to change
his mind about where the reply should go, that's fine.

It is absolutely unacceptable for _anyone_ (the author of an original
message, or a list, or the recipient's MUA) to override the recipient's
preference about where a reply goes.

> If the list member did not have a "Reply-to-List" button, then he would
> hit "Reply-to-All", which is the next best thing, and I think we have been
> assuming that "Reply-to-All" would follow the MFT if no RTL button was
> available 

Again, if the recipient says "reply to all", then _all_ is where the 
reply should go.  MFT is advisory at best.

> (but this shows that such a third button is really needed).

that's not at all clear.

Keith

Date: Fri, 24 Sep 2004 09:06:48 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>, [email-masked]
Organization: Bruce Lilly
To: Jacob Palme <[email-masked]>
CC: 822 <[email-masked]>, Nate Waddoups <[email-masked]>
Subject: Re: Angle brackets surrounding Content-ID
Sender: [email-masked]

Jacob Palme wrote:
> I have received e-mail from an implementor, who has noted
> a discrepancy between RFC 2110 and 2112 regarding the syntax
> of the start parameter to the Content-Type: Multipart/related
> defined in RFC2112 and used in some examples in RFC 2110.
> 
> RFC2112 says that there should be angle brackets around
> the value of the start parameter, e.g.
> 
>     Content-Type: Multipart/related; boundary="boundary-example-1";
>     type=Text/HTML; start=<[email-masked]>
> 
> but RFC2110 has some examples without these angle brackets, e.g.
> 
>     Content-Type: Multipart/related; boundary="boundary-example-1";
>     type=Text/HTML; start=[email-masked]
> 
> My conclusion is that since RFC2112 is the document which
> defines this parameter, it should take precedence and
> RFC2110 is incorrect in its examples. However, a good
> implementor should certainly strip these angle brackets
> from all Message-IDs (wherever they occur) before
> comparing them with other Message-IDs or using them
> in any way. A good implementor should also accept the
> incorrect syntax without these angle brackets in what
> it receives, but always use the angle brackets in what
> it produces.
> 
> With this message I only want to check that other e-mail
> experts agree with this.

First, both RFC 2110 and 2112 are obsolete, 2110 having been
superseded by 2557 and 2112 having been obsoleted by RFC 2387.

Second, there are several different types of things being discussed:
Content-ID (RFC 2045)
Message-ID (RFCs 822/2822)
start parameters (RFCs 2387/2045/2231 and the RFC editor errata page)

Related constructs include cid and mid URIs (RFC 2392).

RFC 2387 goes to some length to clarify the issue described;
the start parameter is supposed to include the angle brackets
which are an integral part of the RFC 822 msg-id construct.

Content identifiers and message identifiers use similar syntax.
However they serve distinct purposes. Prior to RFC 2822, the
syntax was identical, viz. RFC 822 msg-id, which in turn was
identical syntax to an RFC 822 route-addr with no route, i.e.
an angle-bracketed addr-spec (the latter consisting of a
local-part, '@', and a domain).  RFC 2822 defines msg-id
differently, using id-left and id-right, merely recommending
that id-right be a domain.  Having said that, all of the other
RFCs mentioned above use RFC 822 as their basis, not 2822.
There are implications for comparisons (below).

Temporarily leaving aside "strip these angle brackets", there
are several issues that should be taken into consideration
when comparing identifiers:

* domain names are case-insensitive, so "<[email-masked]>"
  is semantically identical to "<[email-masked]>".  RFC
  2822 presents a problem here, because a receiver can never
  be sure whether or not an RFC 2822 id-right is a case-
  insensitive domain name or something else (which might be
  case-sensitive).
* local-parts and domain literals need to be canonicalized
  w.r.t. quoting conventions prior to comparisons. The
  following are all semantically identical:
  <foo.bar@[1.2.3.4]> (canonical form)
  <"foo.bar"@[1\.2.3.4]>
  <"f\oo.bar"@[1\.2.3.4]>
  <"f\oo\.bar"@[1\.2.3.4]>
  <"f\oo\.bar"@[1\.\2.3.4]>
* if one or more identifiers being compared are in a parameter
  of a MIME Content-Type or Content-Disposition field must
  reassemble any such parameter fragments, remove any RFC
  2231-specific character encoding and/or quoting present,
  convert to a common charset, and possibly consider
  specified language; paying particular attention to the
  published (
  http://www.rfc-editor.org/cgi-bin/errata.pl
  ) errata for RFC 2231 and any other relevant RFCs.
* if one or more identifiers was obtained from a URI, any
  URI-encoding (RFC 2396) must be undone prior to comparison
* identifier syntax (modulo RFC 2822 introductions) and the
  context in which identifiers appear, generally permit
  comments, whitespace, and line-folding, which should be
  removed prior to comparison
Now, regarding "strip these angle-brackets":
* if an implementation chooses to strip the angle brackets
  which are an integral part of a msg-id as used in Content-ID
  and Message-ID fields and in "start" parameters (but NOT) in
  CID or MID URIs), it must be done carefully and properly, not
  with reckless abandon by amateurish programmers.  Note that
  either '<' or '>' or '@' or any other special character may
  appear in a local-part if quoted using either a quoted-string
  or qpair backslash quoting, and do NOT signal the end of the
  identifier and must NOT be stripped (though quoting must be
  canonicalized for comparison as noted above).
* handling of the angle brackets must also be performed with due
  consideration to security issues, as these characters may have
  special meaning to some library functions, and there may well
  be security implications.

In the specific case of CID or MID URIs, the angle brackets are
omitted. When comparing a CID or MID URI to an identifier
obtained from a different source (e.g. when comparing an MID
URI to a Message-ID header field body) an implementation could
either properly and carefully strip the delimiting angle brackets
(ONLY!) from the non-CID/MID identifier or add brackets to the
CID/MID-derived identifier.

My personal recommendation for such comparisons would be to
reassemble fragments, undo quoting and encoding, carefully and
correctly separate the identifier into local-part and domain,
checking for correct identifier syntax (exactly one '@', which
incidentally in very old messages might be " at "), carefully
and correctly canonicalize the local-part and domain, then
perform a case-insensitive comparison of the domains and a
case-sensitive comparison of the local-parts. Specifically
for identifiers, charset and language can probably be ignored
in the event that one identifier is obtained from a parameter
(because identifiers in field bodies (excepting parameters)
are always in a subset of US-ASCII which is invariant across
charsets likely to be encountered and have no language. I
would verify that the angle brackets were present where
required, and not present where forbidden (e.g. after handling
the considerations mentioned above, if there is a '>' at the
end of the domain part, somebody fouled up badly (or RFC 2822
syntax is being used) because a domain name never contains
that character.

To: LIST:[email-masked];
Xref: clerew local.mime:3695
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 23 Sep 2004 14:51:04 GMT
Lines: 74
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Charles Lindsey wrote:
>> 
>>>And MTAs.
>> 
>> 
>> Why MTAs? MSAs perhaps.

>Some MTAs rewrite addresses. For example, a border MTA may rewrite
>[email-masked] as [email-masked] in order to hide internal host names.
>If such addresses are rewritten in the envelope and in standard
>address fields, then any new address field that is intended to be
>used by recipients should be similarly processed.

The proper solution for that is for the author to configure his MUA to
always use [email-masked] as his From/Reply-To address (most MUAs provide
that config option, which would probably also be automatically used within
MFT is the agent was smart enough to be MFT aware.

But I agree that the sysadmin in charge to the border might also configure
his MTA to do that rewrite (it is indeed commonly done), in which case he
would have to apply it to all the various headers we are talking about. I
have no doubt sendmail.cf could be made to do it.

>>>>Looks like we have to choose some least-harmful
>>>>alternative. Reply-To is what we have at the moment, and it is clearly not
>>>>working.
>> 
>> 
>>>It works fine for me...
>> 
>> 
>> But not for anybody else, apparently.

>It seems to work fine for others that use it also.

Nobody on this list is using it except for you.

>> We are discussing a suggestion that it might be introduced as a solution
>> to the problem. You do not need ABNF and a full draft (though they would
>> be required eventually). But, if you insist, that you may consult
>> ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-drums-mail-followup-to-00b.txt.
>> Oddly, that draft does not actually specify any ABNF, but you may assume
>> it intended syntax similar to the Reply-To field in RFC 2822.

>Actually there is a syntax specification (however it omits the
>colon which delimits field name from field body...).  You also
>seem to be very confused about address fields; you claim that
>the syntax in Jacob's 5-year-old draft is intended to be like
>that of the Reply-To field, but Jacob's draft specifies a
>mailbox-list whereas Reply-To uses an address list.  That
>draft would make wide responses difficult at best, since it
>deprecates such wide responses.  There are provisions that are
>impractical for implementation.

Yes, that draft was written in the middle of DRUMS, before the final form
of RFC 2822 was fixed. If we wanted to follow that route, then there are
several things in that draft I would like to change.

But its most interesting feature was that it took it for granted that an
MUA would know when it was doing a "group reply", and that implies that
some form of "Reply-to-List" button was envisaged.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Fri, 24 Sep 2004 09:09:51 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Thu, 23 Sep 2004, Keith Moore wrote:

> As I write this message I'm thinking that the audience consists of
> both you and the list.  If I knew you weren't going to receive the
> response I wouldn't bother addressing concerns that only you seem to
> have,

Most lists contain lurkers who don't contribute if they see their 
concerns being discussed by others. Very few people post to lists saying 
just "I agree with X".

However, apart from that, this is a personal/cultural thing. If I knew 
you were not going to read this, I would still post to the list in order 
to get my response on record.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

To: LIST:[email-masked];
Xref: clerew local.mime:3692
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Thu, 23 Sep 2004 14:12:47 GMT
Lines: 60
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

You want to take a close look at the References field in your message. It
was 989 characters long, and ended with "<[email-masked]!" followed
by a folded " n.ac.uk>" on the next line.  Also, it was full of TABs where
it had evidently been folded before during its travels, but the folding
had been systematically undone by some system somewhere. So there are two
buggy MUAs somewhere on this list. I have pruned a load of References out
of the header for this reply (but leaving the initial one, of course).

>Charles Lindsey wrote:

>> If the author has some special
>> requirements of his own, he will include his own MFT (whatever) header,
>> and the list owner will do nothing further. We were discussing the case
>> where the author (through ignorance or laziness) did nothing and left it
>> to the list owner to supply a sensible default, consistent with the
>> culture of the list.

>Others have addressed some of your assumptions.  In addition, you
>seem to be assuming that either
>a) a human list manager will manually deal with every such message,
>   which is impractical

Certainly not that.

>or
>b) that some software will insert some canned field; given the wide
>   variation in possible author intent, that is likely to be wrong
>   much of the time.

No. The canned field, reflecting the culture of the list, will be
determined by the list manager, but only used in the event that the author
had indicated no intent (so what else could the list-manager do?). The
list manager's software may have attempted to check whether the author was
subscribed or not when constructing his MFT.

>Moreover, you seem to be assuming that the only case of interest is
>formally managed lists.  That ignores cases where correspondence
>takes place among a group of people with no list expansion at all.

I would not expect such an informal list to be using MFT at all. But if
some individual author had inserted an MFT anyway, then that might of
might not affect where replies from some list member went (depending on
which of his various "reply" buttons he pressed). If that did cause the
reply to be sent to the MFT set, then that is what the author intended and
so presuambly was Good Thing. Otherwise we would be back to the situation
which prevails today, and there is nothing that can be done about it. But
that is not the case we are currently discussing.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST:[email-masked];
Xref: clerew local.mime:3694
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 23 Sep 2004 14:39:57 GMT
Lines: 57
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>>> How often depends on the list and how its used.  But it's not
>>> "fanciful".  For instance, when I was on IESG it was common to Cc a WG
>>> mailing list on a communication that was actually directed to someone
>>> else, say the IETF secretary.
>>
>> But for such a message what would MFT say?

I think it would say:
    Mail-Followup-To: author,secretary
    Reply-To: author
>>
>> You really need two different ones.
>>
>> For the copy that went to the
>> directed recipent (e.g. the IETF secretary) you want their "reply"
>> to come back to you, and perhaps not go with the FYI WG list?

>Depends on the nature of the reply.  The most common reply from the 
>secretary is probably just an "ack" to say "I got the message and will 
>act on it".  Such messages would usually not be copied to WG lists.

If the secretary hits his "Reply" button (which is probably the right
thing for him to do in this case), then it would go just to the author.

If some member of the list hit his "Reply-to-List" button (expecting it to
go to the list) it would go to the author plus the secretary, because the
author's clearly expressed intent was that it should not go to the list.

If the list member did not have a "Reply-to-List" button, then he would
hit "Reply-to-All", which is the next best thing, and I think we have been
assuming that "Reply-to-All" would follow the MFT if no RTL button was
available (but this shows that such a third button is really needed).

>> But presumably the copy that goes to the WG list should have something
>> that directs replies to the list - and excludes the IETF secretary
>> who does not want to be bothered with the "discussion" that arises
>> on the list?

Not if the author had explicitly requested otherwise. If the author had
omitted the MFT , the list manager would have inserted
   Mail-Followup-To: list
(assuming that was the list culture) or maybe
   Mail-Followup-To: list,author
it he (it) could not detect the author as a subscriber.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: LIST:[email-masked];
Xref: clerew local.mime:3693
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 23 Sep 2004 14:22:41 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> Nick Ing-Simmons <[email-masked]> writes:

>To this end MFT is a useful addition to the available information,
>but getting concensus on how you identify the mailing list in
>the To Cc forest is probably more useful.

Some intelligent use of Group syntax is what I have suggested. Getting
people to use such a convention might be hard, but publishing the
submission list address in the form
    LIST: <[email-masked]>;
might be a good way to start.

Just as an experiment, I have configured my system to do that. Let us see
how well it propagates.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 24 Sep 2004 03:10:17 +0200
Lines: 40
Cancel-Lock: sha1:gS4J0QR56qiZA7beWNP3qKVV+hk=
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> Simon Josefsson wrote:
>> Bruce Lilly <[email-masked]> writes:
>>>D. J. Bernstein wrote:
>>>>Bruce Lilly writes:
>>>>>3. The point remains that "Mail-Followup-To" is ignored by the
>>>>>  vast majority of all UAs and by all of the most widely used UAs.
>>>>
>>>>False. Example: Mutt is a widely used MUA that honors Mail-Followup-To.
>>>
>>>Mutt is not "widely used" compared to Microsoft Outlook, Netscape/Mozilla/
>>>Thunderbird, etc.
>>
>> Do you have a reference to back up this claim?
>
> Do you seriously doubt that in the general population that usage
> of MS Outlook is not at least several orders of magnitude greater
> than that of mutt?

No.  However, it seems that at least one of the problems discussed
here -- how to enhance the reply functionality of e-mail to make it
possible to avoid duplicate copies in mailing list discussions -- is
not a general problem.

You need to be on mailing lists to actually worry about the problem.
I do doubt the general user is on enough mailing lists to worry about
this problem.  That doesn't mean we shouldn't try to solve the
problem.

> Anyway, there is http://www.terena.nl/library/multiling/ml-mua/mua-statist.html
> which is a bit old. Nevertheless, mutt is way down on the list,
> below Juno's proprietary MUA.

That is over 6 years old.  It is based on less than 3000 e-mails.  It
is surveyed among "TERENA Community" users only.  It seems difficult
to build any conclusion at all on that survey.

Thanks,
Simon

Date: Thu, 23 Sep 2004 20:22:17 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Simon Josefsson wrote:
> Bruce Lilly <[email-masked]> writes:
> 
> 
>>D. J. Bernstein wrote:
>>
>>>Bruce Lilly writes:
>>>
>>>
>>>>3. The point remains that "Mail-Followup-To" is ignored by the
>>>>  vast majority of all UAs and by all of the most widely used UAs.
>>>
>>>
>>>False. Example: Mutt is a widely used MUA that honors Mail-Followup-To.
>>
>>Mutt is not "widely used" compared to Microsoft Outlook, Netscape/Mozilla/
>>Thunderbird, etc.
> 
> 
> Do you have a reference to back up this claim?

Do you seriously doubt that in the general population that usage
of MS Outlook is not at least several orders of magnitude greater
than that of mutt?

Anyway, there is http://www.terena.nl/library/multiling/ml-mua/mua-statist.html
which is a bit old. Nevertheless, mutt is way down on the list,
below Juno's proprietary MUA.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 24 Sep 2004 02:05:26 +0200
Lines: 24
Cancel-Lock: sha1:ZMMCXWs3O8uarD/XEWaDPcIZs4o=
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> D. J. Bernstein wrote:
>> Bruce Lilly writes:
>> 
>>>3. The point remains that "Mail-Followup-To" is ignored by the
>>>   vast majority of all UAs and by all of the most widely used UAs.
>> 
>> 
>> False. Example: Mutt is a widely used MUA that honors Mail-Followup-To.
>
> Mutt is not "widely used" compared to Microsoft Outlook, Netscape/Mozilla/
> Thunderbird, etc.

Do you have a reference to back up this claim?

There is <http://gmane.org/user-agents.php>, which do suggest that
Mutt is comparable to Outlook/Mozilla/Thunderbird.

The corpus on gmane.org is slanted towards technical mailing lists,
though.  Similar studies for different user groups would be useful.

Thanks,
Simon

Date: Thu, 23 Sep 2004 19:43:36 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "D. J. Bernstein" <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

D. J. Bernstein wrote:
> Bruce Lilly writes:
> 
>>3. The point remains that "Mail-Followup-To" is ignored by the
>>   vast majority of all UAs and by all of the most widely used UAs.
> 
> 
> False. Example: Mutt is a widely used MUA that honors Mail-Followup-To.

Mutt is not "widely used" compared to Microsoft Outlook, Netscape/Mozilla/
Thunderbird, etc.

Date: 23 Sep 2004 21:55:54 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Bruce Lilly writes:
> 3. The point remains that "Mail-Followup-To" is ignored by the
>    vast majority of all UAs and by all of the most widely used UAs.

False. Example: Mutt is a widely used MUA that honors Mail-Followup-To.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Thu, 23 Sep 2004 13:53:27 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: =?ISO-8859-1?Q?Claus_F=E4rber?= <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Claus Färber wrote:
> Hallo,
> 
> Bruce Lilly <[email-masked]> schrieb/wrote:
> 
>>Claus Färber wrote:
>>
>>>Further, it does not allow something like this:
>>>| From: [email-masked]
>>>| To: [email-masked], [email-masked]
>>>| Reply-To: [email-masked]
>>>| Mail-Followup-To: [email-masked]
> 
> 
>>"No, it does not work with existing UAs." Most UAs ignore illegal
>>fields such as "Mail-Followup-To".
> 
> 
> When discussing a new potential standard, it does not make sense to
> slanderously refer to proposed fields as "illegal". They field is
> currently undefined but the idea of introducing a new spec is to change  
> that.

1. I'm not aware that we're discussing any "new potential standard";
   as Keith has pointed out, this list is not associated with any
   active WG, therefore has no charter, etc., and the present
   discussion is not related to any proposed draft.
2. Fields which are not defined in any RFC are referred to by at
   least one UA's author(s) as "illegal", so use of that term is
   appropriate in the context of UAs ignoring non-standard
   fields -- that's how they're viewed by (some) UA authors.
3. The point remains that "Mail-Followup-To" is ignored by the
   vast majority of all UAs and by all of the most widely used
   UAs.  I.e. you initiated the discussion of what does and
   does not work with existing UAs -- and "Mail-Followup-To"
   does not work with any substantial fraction of existing UAs.

>>And the following achieves what I believe you intended using only
>>standard header fields, with (as discussed) the From field for
>>narrow responses, Reply-To for default responses, and a user-edited
>>selection from all addresses for a wide response:
> 
> 
>>From: [email-masked]
>>Sender: [email-masked]
>>To: [email-masked], [email-masked]
>>Reply-To: [email-masked]
> 
> 
> A user agent following established practice

What happened to "when discussing a new potential standard" -- are
you trying to have your cake and eat it too?

> will send narrow replies to
> "[email-masked]" (Reply-To) and broad replies to
> "[email-masked], [email-masked]"  
> (To, Reply-To), which is also wrong.

(Several) existing UAs provide a "reply-to-author" feature which
uses the From field, ignoring Reply-To, which happens to be
what Keith has suggested should be done.  Such narrow responses
go to "[email-masked]". Is that not where you expect narrow
responses to go?

Broad responses as discussed here almost invariably require
hand editing, so go to an edited set of mailboxes.

> IOW: Both solutions are not backwards-compatible wrt broad replies but
> your proposal (it's not the existing standard because it adds additional
> semantics to the existing header fields)

No -- there are no additional semantics. The From field still
holds the mailboxes of the author(s), and reply-to has exactly
the semantics specified in RFC 2822, viz.:

   When the "Reply-To:" field is present, it
   indicates the mailbox(es) to which the author of the message suggests
   that replies be sent.

> also breaks narrow replies

No, narrow responses as discussed on this list go to the author(s)
[as specified in the From field as defined in RFC 2822 and its
predecessors].

> (and
> Mail<->Netnews gateways).

No, since the fields in question are all standard fields and have exactly
the same unchanged semantics in both mail and news messages.

> Please note that you can't put two addresses in the From field either,  
> in case that the message has been jointly written by two authors (e.g.  
> "[email-masked]" and "[email-masked]").

Incorrect, as pointed out in detail elsewhere.

Date: Thu, 23 Sep 2004 16:13:46 +0200
To: IETF mailing list on e-mail headers <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Angle brackets surrounding Content-ID
Cc: "Nate Waddoups" <[email-masked]>
Sender: [email-masked]

I have received e-mail from an implementor, who has noted
a discrepancy between RFC 2110 and 2112 regarding the syntax
of the start parameter to the Content-Type: Multipart/related
defined in RFC2112 and used in some examples in RFC 2110.

RFC2112 says that there should be angle brackets around
the value of the start parameter, e.g.

    Content-Type: Multipart/related; boundary="boundary-example-1";
    type=Text/HTML; start=<[email-masked]>

but RFC2110 has some examples without these angle brackets, e.g.

    Content-Type: Multipart/related; boundary="boundary-example-1";
    type=Text/HTML; start=[email-masked]

My conclusion is that since RFC2112 is the document which
defines this parameter, it should take precedence and
RFC2110 is incorrect in its examples. However, a good
implementor should certainly strip these angle brackets
from all Message-IDs (wherever they occur) before
comparing them with other Message-IDs or using them
in any way. A good implementor should also accept the
incorrect syntax without these angle brackets in what
it receives, but always use the angle brackets in what
it produces.

With this message I only want to check that other e-mail
experts agree with this. Below is quoted some mail exchange
between me and the implementor.

I am sending this message to the ietf-822 mailing list,
since the MHTML mailing list does not work any more.
If there is need for much more discussion about MHTML,
I can if needed try to resurrect the MHTML mailing list
using a new listserver.

At 13.35 -0700 04-09-20, Nate Waddoups wrote:
>In section 9.2 of RFC 2110, there is an example message with suspicious
>syntax and I was hoping you could clarify it for me.  The content-type
>of the messages's root is:
>
>    Content-Type: Multipart/related; boundary="boundary-example-1";
>        type=Text/HTML; start=[email-masked]
>
>The Content-ID of the first child of that multipart/related part is:
>
>    Content-ID: <[email-masked]>
>
>Notice that one has angle brackets and the other does not.  Is this
>legal MIME or is this an error in the example message?  The BNF for the
>start parameter indicates that the angle brackets are required but I
>want to make sure that I am not overlooking something.

At 17.17 +0200 04-09-21, Jacob Palme wrote:
>Funny that no one has mentioned this discrepancy before.
>
>Since RFC2112 is the document which defines the start
>parameter, a natural assumption is that that is the correct
>thing to do. This is a normal principle in IETF that if
>there is a discrepancy between two documents, the one which
>standardizes a feature has precedence.
>
>An implementor should of course follow the golden rule: "Be
>liberal in what you accept, be conservative in what you
>send". Thus in this case accept both syntaxes in incoming
>messages, but use the right format when producing new
>messages.
>
>There is a risk that actual implementors will read RFC2110
>and implement the syntax without angle brackets. If one
>wants to tackle this problem really seriously, one should
>perhaps send messages with both syntaxes to some of the
>mostly used mailers and see which format works best with
>them.
>
>There is a mailing list on the MHTML standard, which was
>used when the standard was developed. It has been inactive
>for a long time, but I will try to write a message to it,
>to check if someone else has a comment on this.

At 13.53 -0700 04-09-21, Nate Waddoups wrote:
>The fact that the start parameter in the example message lacks angle
>brackets is not my primary concern... What concern me most is that the
>start parameter value is different from the Content-ID value, in that
>one is surrounded by angle brackets and the other is not. 
>
>If a mail client matches a start parameter to a Content-id by stripping
>the outer angle brackets from the start parameter prior to comparison,
>would that be considered "liberal" or just "broken?" 

At 10.44 +0200 04-09-22, Jacob Palme wrote:
>I would certainly recommend doing that, stripping angle
>brackets from both the "start" and the "Content-ID" value
>(and anywhere else where a message-Id or Content-Id occurs)
>before storing, comparing or doing anything with them.
>
>One can compare with SMTP, where the correct syntax is
>MAIL FROM:<[email-masked]>
>but where many good SMTP softwares will accept variants like
>MAIL FROM:[email-masked]
>or
>MAIL FROM: <[email-masked]>
>
>according to the "be liberal in what you acccept" principle.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Cc: [email-masked], [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 23 Sep 2004 08:42:31 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

>> In the sense that the responder _realizes_ he's not sending a copy to
>> the author of the original message, no.  Because use of MFT for the
>> case where the author doesn't want to see the reply is 
>> indistinguishable
>> from the use of MFT where the author is subscribed to the list.
>
> When I'm responding on a discussion list like this one, I don't think I
> need to know. Life is too short. If the author has cut herself out of
> the responses, that is her responsibility.

Perhaps.  I'd certainly agree that if an author has cut herself out of 
a response, one should in most cases honor that request.

However I think the responder does want to know this, for several 
reasons.  The simplest and most obvious is that a response may serve 
multiple purposes depending on who reads it.  As I write this message 
I'm thinking that the audience consists of both you and the list.  If I 
knew you weren't going to receive the response I wouldn't bother 
addressing concerns that only you seem to have, and I probably wouldn't 
bother trying to argue things in detail that others on the list seem to 
accept without detailed support.

Keith

Date: Thu, 23 Sep 2004 09:33:22 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, 22 Sep 2004, Keith Moore wrote:

> In the sense that the responder _realizes_ he's not sending a copy to 
> the author of the original message, no.  Because use of MFT for the
> case where the author doesn't want to see the reply is indistinguishable
> from the use of MFT where the author is subscribed to the list.

When I'm responding on a discussion list like this one, I don't think I 
need to know. Life is too short. If the author has cut herself out of
the responses, that is her responsibility.

In practice, of course, it is likely that the original posting would 
include text along the lines of "I'm not subscribed to this list and I 
don't want to see the discussion, thanks." In all these edge cases 
the solution is to add clarifying words to the message if you think 
clarification is needed.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Wed, 22 Sep 2004 20:36:41 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Charles Lindsey wrote:

> If the author has some special
> requirements of his own, he will include his own MFT (whatever) header,
> and the list owner will do nothing further. We were discussing the case
> where the author (through ignorance or laziness) did nothing and left it
> to the list owner to supply a sensible default, consistent with the
> culture of the list.

Others have addressed some of your assumptions.  In addition, you
seem to be assuming that either
a) a human list manager will manually deal with every such message,
   which is impractical
or
b) that some software will insert some canned field; given the wide
   variation in possible author intent, that is likely to be wrong
   much of the time.

Moreover, you seem to be assuming that the only case of interest is
formally managed lists.  That ignores cases where correspondence
takes place among a group of people with no list expansion at all.

Date: Wed, 22 Sep 2004 20:21:40 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
> 
> 
>>Charles Lindsey wrote:
> 
> 
>>>It is quite clear to me that _any_solution to the problems we are
>>>dicussing will require changes to MUAs before it becomes effective. MFT is
>>>a nice solution on the face of it, but requires the most change to
>>>existing MUAs.
> 
> 
>>And MTAs.
> 
> 
> Why MTAs? MSAs perhaps.

Some MTAs rewrite addresses. For example, a border MTA may rewrite
[email-masked] as [email-masked] in order to hide internal host names.
If such addresses are rewritten in the envelope and in standard
address fields, then any new address field that is intended to be
used by recipients should be similarly processed.

>>>Mail-Copies-To would he easier to introduce, but it does
>>>not do such a good job.
> 
> 
>>Not easier -- it has the same problems and requires MUA and MTA
>>changes.
> 
> 
> What MTA support?

See above.

>>>Looks like we have to choose some least-harmful
>>>alternative. Reply-To is what we have at the moment, and it is clearly not
>>>working.
> 
> 
>>It works fine for me...
> 
> 
> But not for anybody else, apparently.

It seems to work fine for others that use it also.

>>>It is well enough defined for us to understand what it would entail.
> 
> 
>>Where's the ABNF? Where's the definition of how the field is handled
>>w.r.t. message fragmentation and reassembly?  Where's the discussion
>>w.r.t. interaction with Reply-To in RFC 2822?  Where's the discussion
>>about automatic responses in RFC 3834?
> 
> 
> We are discussing a suggestion that it might be introduced as a solution
> to the problem. You do not need ABNF and a full draft (though they would
> be required eventually). But, if you insist, that you may consult
> ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-drums-mail-followup-to-00b.txt.
> Oddly, that draft does not actually specify any ABNF, but you may assume
> it intended syntax similar to the Reply-To field in RFC 2822.

Actually there is a syntax specification (however it omits the
colon which delimits field name from field body...).  You also
seem to be very confused about address fields; you claim that
the syntax in Jacob's 5-year-old draft is intended to be like
that of the Reply-To field, but Jacob's draft specifies a
mailbox-list whereas Reply-To uses an address list.  That
draft would make wide responses difficult at best, since it
deprecates such wide responses.  There are provisions that are
impractical for implementation.

Date: Wed, 22 Sep 2004 13:57:39 -0400
From: Keith Moore <[email-masked]>
To: Philip Hazel <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> > On the other hand, a recipient does not reliably know whether a particular
> > address is subscribed to a list and whether that address wants duplicate
> > copies.  So it's helpful if there's something that tells him this.
> 
> Quite.
> 
> And while we are thinking of "fanciful" cases :-) how about the case 
> where somebody sends a message to a list to which they are not 
> subscribed, but nevertheless does not want to receive any followups?
> ("You guys might like to discuss this; I don't have time / am not 
> interested / whatever.") I think that could be done with MFT, couldn't 
> it?

In the sense that the responder doesn't send a copy to the author of the
original message, yes.

In the sense that the responder _realizes_ he's not sending a copy to 
the author of the original message, no.  Because use of MFT for the
case where the author doesn't want to see the reply is indistinguishable
from the use of MFT where the author is subscribed to the list.

Keith

To: [email-masked]
Xref: clerew local.mime:3673
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 22 Sep 2004 10:08:25 GMT
Lines: 28
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> Precisely! I think that's exactly what the proponents of MFT are
>> arguing.

>But I think they _do_ want to worry about whether their replies are 
>going to "all" or to some other set of recipients.  And MFT can cause 
>the replies to go to some other set of recipients without the responder 
>realizing this.

Then when we come to write the draft for MFT (whatever), we write into it
that MUAs SHOULD/MAY (as a matter of best practice) do certain things,
like alerting the user, or showing the intended To: and Cc: headers; and
we ensure that the syntax/whatever of the header provides all reasonable
information to assist in that. I have already suggested that much useful
information could be encoded into group syntax, or that additional syntax
(e.g. MIME-style parameters) could be provided.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Wed, 22 Sep 2004 16:10:20 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Nick Ing-Simmons <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, 22 Sep 2004, Keith Moore wrote:

> On the other hand, a recipient does not reliably know whether a particular
> address is subscribed to a list and whether that address wants duplicate
> copies.  So it's helpful if there's something that tells him this.

Quite.

And while we are thinking of "fanciful" cases :-) how about the case 
where somebody sends a message to a list to which they are not 
subscribed, but nevertheless does not want to receive any followups?
("You guys might like to discuss this; I don't have time / am not 
interested / whatever.") I think that could be done with MFT, couldn't 
it?

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Wed, 22 Sep 2004 16:06:28 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, 22 Sep 2004, Arnt Gulbrandsen wrote:

> I guess you're really avoiding a hurdle. Having to make a conscious decision
> when you want to start typing is an unpleasant distraction.

But at present I cannot make that decision, even if I wanted to. I
happen to know that when I reply to one of Keith's messages on this
list, he wants to get a duplicate copy, but when I reply to one of
Dan's, he doesn't. So I can get it right for them, as long as I
remember. However, I can't get it right in general.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Cc: [email-masked], Philip Hazel <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 22 Sep 2004 10:44:27 -0400
To: Nick Ing-Simmons <[email-masked]>
Sender: [email-masked]

>> How often depends on the list and how its used.  But it's not
>> "fanciful".  For instance, when I was on IESG it was common to Cc a WG
>> mailing list on a communication that was actually directed to someone
>> else, say the IETF secretary.
>
> But for such a message what would MFT say?
>
> You really need two different ones.
>
> For the copy that went to the
> directed recipent (e.g. the IETF secretary) you want their "reply"
> to come back to you, and perhaps not go with the FYI WG list?

Depends on the nature of the reply.  The most common reply from the 
secretary is probably just an "ack" to say "I got the message and will 
act on it".  Such messages would usually not be copied to WG lists.

> But presumably the copy that goes to the WG list should have something
> that directs replies to the list - and excludes the IETF secretary
> who does not want to be bothered with the "discussion" that arises
> on the list?

Actually I'd assume that for messages from a list the usual response 
would be either to IESG or to a particular AD - as in "thank you for 
finally approving this document" or "you neglected to consider this 
important issue" or "I wish to appeal".

> However if we had list header then WG members could "reply to list"
> for their discussion, and IETF secretary would reply to sender (just 
> you)
> or reply to all (CCing the list)

Reply to list is problematic if there are multiple lists involved in a 
conversation.  Often cross-posting is the right thing to do.

Also,  having different reply behavior for different copies of a 
message makes me nervous.  If someone is on two lists his replies are 
probably going to be written with both lists in mind.  The reply 
shouldn't go to one list or the other depending on which copy he 
happened to read first.

It occurs to me that a lot of this hinges on whether the recipient 
knows enough information to know which addresses to include in a reply. 
  For instance, a recipient probably recognizes the addresses of lists 
to which he is subscribed.  If he wants to reply only to that list, he 
has the information he needs to do so.  If he wants to configure his 
user agent to act differently for messages received from that list, he 
can do that also.

On the other hand, a recipient does not reliably know whether a 
particular address is subscribed to a list and whether that address 
wants duplicate copies.  So it's helpful if there's something that 
tells him this.

Keith

Cc: [email-masked], Philip Hazel <[email-masked]>
Subject: Re: Understanding response protocols
To: [email-masked]
Date: Wed, 22 Sep 2004 15:30:06 +0100
From: Nick Ing-Simmons <[email-masked]>
Reply-To: Nick Ing-Simmons <[email-masked]>
Sender: [email-masked]

Keith Moore <[email-masked]> writes:
>
>How often depends on the list and how its used.  But it's not 
>"fanciful".  For instance, when I was on IESG it was common to Cc a WG 
>mailing list on a communication that was actually directed to someone 
>else, say the IETF secretary.

But for such a message what would MFT say?

You really need two different ones.

For the copy that went to the 
directed recipent (e.g. the IETF secretary) you want their "reply"
to come back to you, and perhaps not go with the FYI WG list?

But presumably the copy that goes to the WG list should have something 
that directs replies to the list - and excludes the IETF secretary 
who does not want to be bothered with the "discussion" that arises 
on the list?

However if we had list header then WG members could "reply to list"
for their discussion, and IETF secretary would reply to sender (just you)
or reply to all (CCing the list)

>
>>  (And surely you'd Bcc the list in that circumstance, anyway?)
>
>A person might do so, but not "surely".  Knowing that the list was 
>copied might be useful to the other recipients of the message.
>
>> Are we in danger of not doing anything because we can't do everything?
>
>I don't think so.  I just don't want to see us discourage valuable uses 
>of lists.
>
>Keith

Subject: Re: Understanding response protocols
To: [email-masked]
Date: Wed, 22 Sep 2004 15:17:39 +0100
From: Nick Ing-Simmons <[email-masked]>
Reply-To: Nick Ing-Simmons <[email-masked]>
Sender: [email-masked]

Philip Hazel <[email-masked]> writes:
>On Wed, 22 Sep 2004, Arnt Gulbrandsen wrote:
>
>> > True, but I thought we were discussing a problem that arises when a mailing
>> > list *is* used for a discussion. 

As is happening here ;-) !
Perhaps we could analyse the headers of various resonses and 
see which ones fit the models being discussed.

>> > In that situation, it does become more like
>> > USENET, and users have similar expectations of the two.

One of the USENET concepts which has translated quite well to mail is 
the use of the References: header to thread mails.

>> 
>> Some users do. Not all.
>
>Yes. Agreed. Sorry. I should have said "some users".
>
>> Some people want mail to behave like mail, whether a list is involved or not.
>> Others want mailing lists to behave like usenet. 

Part of the problem is it is not easy to identify when a list is involved.
I (automatically) file incoming mail based on list it comes from 
when I can. Do do so I have to match various "headers":

	 $mail->get('X-Mailing-List-Name') ||
    	 $mail->get('List-ID')  ||
    	 $mail->get('List-Name')  ||
    	 $mail->get('X-List')  ||
         $mail->get('X-listname') ||

and I was missing the 'List-ID' used by this list till recently.

If there was a clearly defined header that said "you got this mail from 
the list <whatever@somewhere>" it would be trivial to add a 
"Reply to list" button to a MUA.

Note that 'List-ID' for this list is List-ID: <ietf-822.imc.org>
with no @ which would make it hard to use if this list 
had been called (say) [email-masked]

Sending _just_ to the list would probably suit most discussion type lists.
List+Author would cover a few more cases where author may not be 
subscribed.

>
>At present, I use "reply to all" for virtually every message to which I 
>respond, whether it comes from a mailing list or not, though of course 
>it doesn't always do the right thing, and if I remember, I edit the 
>recipients manually sometimes when I know people don't want personal 
>copies. There are, of course, some exceptions, for which I just use
>"reply", but these are pretty rare for me.

Likewise.

>
>On the other side of the fence, I just quietly delete the duplicate
>copies I receive because I know it isn't easy for the posters to find 
>out that I don't actually want them.

My home grown MUA quietly supresses duplicates, when it can, based 
in Message-Id. So I have a pet hate of those mailers which Cc me 
and a mailing list and use different Message-Id for the two (or more)
copies.

As I use a MUA I wrote it does what I want it to do (provided I can 
be bothered to change it), so I am most interested in defining 
headers that allow "smart" tools to do what their users want.

To this end MFT is a useful addition to the available information,
but getting concensus on how you identify the mailing list in
the To Cc forest is probably more useful.

>
>Philip

Date: Wed, 22 Sep 2004 16:02:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Philip Hazel writes:
> Well, there have been suggestions of three commands/buttons/whatever,
> giving the user the choice of responding to
>
> (a) The author, typically taking reply-to or from
> (b) All - everything in reply-to/From, To, and Cc
> (c) Followup - contents of MFT (fallback to (b) if not present)
>
> Those that want "mail behaviour" use (a) or (b); those that want 
> "usenet behaviour" use (c). But I expect it isn't that simple.

It is a bit much to ask of people. People hate hurdles in their way, 
particularly ones that require abstract thinking.

I tried to implement something like that, but less abstract and not 
demanding an instant answer. In the reply window, I added a pane asking 
where to reply, showing the concrete consequences on-screen (ie. which 
addresses would be included/excluded for each type of reply). It still 
was a bit of a pain.

It seems to me that there is an inherent and unavoidable conflict: To 
select the right type of reply requires significantly more care and 
attention than email writers are used to now. Most are used to hitting 
one key and typing away.

...
> At present, I use "reply to all" for virtually every message to which 
> I respond,
...

I guess you're really avoiding a hurdle. Having to make a conscious 
decision when you want to start typing is an unpleasant distraction.

Someone's going to flame now, I'm sure.

Arnt

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 22 Sep 2004 09:56:36 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

>> Another difference: a USENET discussion inherently takes place within
>> the context of one or more newsgroups, whereas a message in an email
>> discussion that is mostly taking place outside the context of any list
>> might cc a list that only has a peripheral interest in the discussion
>> - because people on the list need to know.
>
> With respect, this is getting very fanciful. How often is that likely 
> to
> happen?

How often depends on the list and how its used.  But it's not 
"fanciful".  For instance, when I was on IESG it was common to Cc a WG 
mailing list on a communication that was actually directed to someone 
else, say the IETF secretary.

>  (And surely you'd Bcc the list in that circumstance, anyway?)

A person might do so, but not "surely".  Knowing that the list was 
copied might be useful to the other recipients of the message.

> Are we in danger of not doing anything because we can't do everything?

I don't think so.  I just don't want to see us discourage valuable uses 
of lists.

Keith

Date: Wed, 22 Sep 2004 14:42:12 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, 22 Sep 2004, Keith Moore wrote:

> Another difference: a USENET discussion inherently takes place within
> the context of one or more newsgroups, whereas a message in an email
> discussion that is mostly taking place outside the context of any list
> might cc a list that only has a peripheral interest in the discussion
> - because people on the list need to know.

With respect, this is getting very fanciful. How often is that likely to 
happen? (And surely you'd Bcc the list in that circumstance, anyway?)
Are we in danger of not doing anything because we can't do everything?

I think I see a categorization here that perhaps is being overlooked, at 
least by me (and I apologize for that): 

Two Kinds Of List

(1) A discussion list, like this one.

(2) A list that just a handy way of addressing a group of people, for 
    instance the list of all the staff in my department. This kind of 
    list has limited and controlled membership.

I can just about imagine a situation where somebody wanted to cc
a message to all our staff, but I can more likely imagine it being a
forward rather than a (b)cc.

My comments have all been in the context of a discussion list.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Cc: Charles Lindsey <[email-masked]>, [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 22 Sep 2004 09:34:25 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

>> There's nothing inherently wrong with that, but it does mean that when
>> someone responds to a message from you, they may be responding
>> specifically to opinions that you have expressed, rather than to the
>> list in general.
>
> I'm afraid I just don't get that at all. When I respond to a list, 
> sure,
> I'm responding to a particular posting, but I see it as part of the
> general discussion, just as if I stood up in a meeting and said my
> piece.

I don't think it's reasonable to assume that most of the time a list is 
a recipient of a message, that the message is intended primarily for 
the list.  I've seen too many cases to the contrary.  Lists come in all 
sizes and exist for a wide variety of purposes.  Not all lists are used 
as virtual meeting rooms.

Keith

Date: Wed, 22 Sep 2004 14:29:35 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, 22 Sep 2004, Arnt Gulbrandsen wrote:

> > True, but I thought we were discussing a problem that arises when a mailing
> > list *is* used for a discussion. In that situation, it does become more like
> > USENET, and users have similar expectations of the two.
> 
> Some users do. Not all.

Yes. Agreed. Sorry. I should have said "some users".

> Some people want mail to behave like mail, whether a list is involved or not.
> Others want mailing lists to behave like usenet. To/Cc details are just
> consequences of that basic difference. AFAICT, Keith seems to argue that To/Cc
> should be set in a way suitable for the former desire, Charles the latter.
> 
> I'm afraid I can't suggest a response protocol that caters to both
> expectations.

Well, there have been suggestions of three commands/buttons/whatever, 
giving the user the choice of responding to 

(a) The author, typically taking reply-to or from
(b) All - everything in reply-to/From, To, and Cc
(c) Followup - contents of MFT (fallback to (b) if not present)

Those that want "mail behaviour" use (a) or (b); those that want "usenet 
behaviour" use (c). But I expect it isn't that simple.

Personally, I want a button that says "reply to this mailing list
posting so that it goes to the list and to any other addresses that it
should go to, according to the preferences of the author and/or list
manager (if any)". In other words, a "do the right thing" button. A
formal mailing list does not have to be involved. Any message that is
sent to multiple recipients can fall into this category.

Maybe such a thing is not possible. Otherwise this thread would not have
gone on so long.

At present, I use "reply to all" for virtually every message to which I 
respond, whether it comes from a mailing list or not, though of course 
it doesn't always do the right thing, and if I remember, I edit the 
recipients manually sometimes when I know people don't want personal 
copies. There are, of course, some exceptions, for which I just use
"reply", but these are pretty rare for me.

On the other side of the fence, I just quietly delete the duplicate
copies I receive because I know it isn't easy for the posters to find 
out that I don't actually want them.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 22 Sep 2004 09:27:23 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

On Sep 22, 2004, at 4:25 AM, Philip Hazel wrote:

> On Tue, 21 Sep 2004, Keith Moore wrote:
>
>> Many assumptions that are reasonable in USENET are less reasonable in
>> email.  For instance, it's meaningless to talk about USENET 
>> discussions
>> that don't involve any newsgroups, but it's perfectly reasonable to 
>> have
>> email discussions that don't involve mailing lists.
>
> True, but I thought we were discussing a problem that arises when a
> mailing list *is* used for a discussion. In that situation, it does
> become more like USENET, and users have similar expectations of the 
> two.

There are still significant differences.  For instance, in a USENET 
discussion it's assumed that everybody can read all of the "major" 
newsgroups, so there's less reason to followup to multiple newsgroups.  
Another difference: a USENET discussion inherently takes place within 
the context of one or more newsgroups, whereas a message in an email 
discussion that is mostly taking place outside the context of any list 
might cc a list that only has a peripheral interest in the discussion - 
because people on the list need to know.

Date: Wed, 22 Sep 2004 10:49:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Philip Hazel writes:
> On Tue, 21 Sep 2004, Keith Moore wrote:
>
>>  Many assumptions that are reasonable in USENET are less reasonable 
>>  in email. For instance, it's meaningless to talk about USENET 
>>  discussions that don't involve any newsgroups, but it's perfectly 
>>  reasonable to have email discussions that don't involve mailing 
>>  lists.
>
> True, but I thought we were discussing a problem that arises when a 
> mailing list *is* used for a discussion. In that situation, it does 
> become more like USENET, and users have similar expectations of the 
> two.

Some users do. Not all.

Some people want mail to behave like mail, whether a list is involved or 
not. Others want mailing lists to behave like usenet. To/Cc details are 
just consequences of that basic difference. AFAICT, Keith seems to 
argue that To/Cc should be set in a way suitable for the former desire, 
Charles the latter.

I'm afraid I can't suggest a response protocol that caters to both 
expectations.

Arnt

Date: Wed, 22 Sep 2004 09:25:34 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Tue, 21 Sep 2004, Keith Moore wrote:

> Many assumptions that are reasonable in USENET are less reasonable in
> email.  For instance, it's meaningless to talk about USENET discussions
> that don't involve any newsgroups, but it's perfectly reasonable to have
> email discussions that don't involve mailing lists.

True, but I thought we were discussing a problem that arises when a 
mailing list *is* used for a discussion. In that situation, it does 
become more like USENET, and users have similar expectations of the two.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Wed, 22 Sep 2004 09:20:53 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Tue, 21 Sep 2004, Keith Moore wrote:

> > >I was responding to a message from you, and the principal purpose of my 
> > >sending the message was to provide information to you.
> > 
> > Well that was not the way I saw it.
> 
> Perhaps it has not occurred to you that your opinions are rather, uh, 
> distant from those of most other participants. 

Well, I see it the same way as Charles. Perhaps this is a left-pond vs 
right-pond cultural thing. In any event, unless Charles and I are the 
only two people in the whole world who see it that way, it seems that 
there is no hope of trying to make the nice[*] distinction you were 
trying to draw.

> There's nothing inherently wrong with that, but it does mean that when
> someone responds to a message from you, they may be responding
> specifically to opinions that you have expressed, rather than to the
> list in general.

I'm afraid I just don't get that at all. When I respond to a list, sure,
I'm responding to a particular posting, but I see it as part of the
general discussion, just as if I stood up in a meeting and said my
piece.

Philip

[*] I use "nice" in the original meaning of "fine, close, fastidious".

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Tue, 21 Sep 2004 15:46:11 -0400
From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> > MFT can cause the replies to go to some other set of recipients
> > without the responder realizing this.
> 
> My MUA shows me the original message along with the reply under
> construction. To-line differences are already reasonably clear, although
> I suppose automatic highlighting of the differences in red would save a
> moment of reading.
> 
> But the point you keep missing is that the original sender and the
> original recipient are _cooperating_ to send followups to the right
> place. Sure, there are occasional disagreements, but _usually_ the
> recipient wants exactly what the sender specified in Mail-Followup-To.

The way _you_ use MFT, this is _usually_ what the recipient wants.
It's not clear whether this would be true if MFT were more widely 
adopted by a more diverse set of users.

But I do agree that the user interface can make a huge contribution to
helping the responder be aware of what he is doing.

> USENET has always allowed the original sender to specify Followup-To.
> The recipient can select a different followup target but _usually_ wants
> exactly what the sender wants. That's why the recipient's software uses
> Followup-To as the _default_ followup address.

USENET is a different environment, with a different purpose than email.
Many assumptions that are reasonable in USENET are less reasonable in
email.  For instance, it's meaningless to talk about USENET discussions
that don't involve any newsgroups, but it's perfectly reasonable to have
email discussions that don't involve mailing lists.

Keith

Date: 21 Sep 2004 18:46:32 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore writes:
> MFT can cause the replies to go to some other set of recipients
> without the responder realizing this.

My MUA shows me the original message along with the reply under
construction. To-line differences are already reasonably clear, although
I suppose automatic highlighting of the differences in red would save a
moment of reading.

But the point you keep missing is that the original sender and the
original recipient are _cooperating_ to send followups to the right
place. Sure, there are occasional disagreements, but _usually_ the
recipient wants exactly what the sender specified in Mail-Followup-To.
My MUA does this by _default_ to save editing time for the user.

USENET has always allowed the original sender to specify Followup-To.
The recipient can select a different followup target but _usually_ wants
exactly what the sender wants. That's why the recipient's software uses
Followup-To as the _default_ followup address.

Should the recipient know what's going on? Of course. Should the
recipient be able to edit the target list? Of course. But this is not an
argument against Mail-Followup-To.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Tue, 21 Sep 2004 12:35:26 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> >> Then please explain to me the subtlety that lead you to send the 
> >> message I am responding to To: me with Cc: the list.
> 
> >I was responding to a message from you, and the principal purpose of my 
> >sending the message was to provide information to you.
> 
> Well that was not the way I saw it.

Perhaps it has not occurred to you that your opinions are rather, uh, 
distant from those of most other participants.  There's nothing 
inherently wrong with that, but it does mean that when someone responds
to a message from you, they may be responding specifically to opinions
that you have expressed, rather than to the list in general.

> I was under the impression that we
> were both partaking in a discussion on this list with a view to finding
> the best tools to be provided, either by standardized headers or best
> practice for features in MTAs, to resolve what most here seem to agree is
> a problem in need of resolution.
> 
> In that situation, I would expect most contributions to the discussion to
> be directed To: the list with Cc: the original author in those cases where
> that author needed a personal copy.

At least for messages that I send, your expectations are incorrect.  

Keith

To: [email-masked]
Xref: clerew local.mime:3668
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 21 Sep 2004 11:27:16 GMT
Lines: 32
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> Then please explain to me the subtlety that lead you to send the 
>> message I
>> am responding to To: me with Cc: the list.

>I was responding to a message from you, and the principal purpose of my 
>sending the message was to provide information to you.

Well that was not the way I saw it. I was under the impression that we
were both partaking in a discussion on this list with a view to finding
the best tools to be provided, either by standardized headers or best
practice for features in MTAs, to resolve what most here seem to agree is
a problem in need of resolution.

In that situation, I would expect most contributions to the discussion to
be directed To: the list with Cc: the original author in those cases where
that author needed a personal copy.

The basic problem is that most MUAs do not make that happy outcome
particularly easy to achieve.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Cc: Charles Lindsey <[email-masked]>, [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 21 Sep 2004 09:40:45 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

>> I suspect that when people hit "reply to all" to a message from a 
>> list they
>> generally want the reply to go to everyone who received the original 
>> message,
>> not "just" to the list.  They don't want to worry about which of those
>> recipients are on the list and which ones are not.
>
> Precisely! I think that's exactly what the proponents of MFT are
> arguing.

But I think they _do_ want to worry about whether their replies are 
going to "all" or to some other set of recipients.  And MFT can cause 
the replies to go to some other set of recipients without the responder 
realizing this.

Date: Tue, 21 Sep 2004 10:08:11 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Mon, 20 Sep 2004, Keith Moore wrote:

> I suspect that when people hit "reply to all" to a message from a list they
> generally want the reply to go to everyone who received the original message,
> not "just" to the list.  They don't want to worry about which of those
> recipients are on the list and which ones are not.

Precisely! I think that's exactly what the proponents of MFT are 
arguing.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Mon, 20 Sep 2004 22:22:45 +0200
From: Alan Barrett <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Sat, 18 Sep 2004, Claus Färber wrote:
> Please note that you can't put two addresses in the From field either,  
> in case that the message has been jointly written by two authors (e.g.  
> "[email-masked]" and "[email-masked]").

Putting two addresses in the From field is exactly what you should do
for a message with two authors.  RFC 822 section A.2.7 has an example
with multiple addresses in the From field, and RFC 2822 section 3.6.2 is
clear that the From field contains a mailbox-list.

--apb (Alan Barrett)

Date: Mon, 20 Sep 2004 15:37:06 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> Given that the mail clients that I've used tend to fill out To and Cc
> nearly at random, I think there's already so much noise involved that
> trying to extract any information from whether someone is on the To or
> Cc lines is a lost cause *for replies*.  I agree with you much more
> for original messages, where the sender has addressed the message by
> hand.

I generally find that to be the case also - To and CC are far more
meaningful on original messages than on replies.

But in the vein of trying to make email a more effective communications
medium, I'm hoping we can encourage MUAs to improve in this regard.

(so much communication is now being done by email that it's kind of
important that it work well)

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 20 Sep 2004 12:31:40 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> (not that I always take so much care in making sure to and cc are
> appropriately used - I get lazy too sometimes - but in this particular
> instance they were appropriately used.)

Given that the mail clients that I've used tend to fill out To and Cc
nearly at random, I think there's already so much noise involved that
trying to extract any information from whether someone is on the To or Cc
lines is a lost cause *for replies*.  I agree with you much more for
original messages, where the sender has addressed the message by hand.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Mon, 20 Sep 2004 15:01:39 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> No, you have completely missed the point. If the author has some
> special requirements of his own, he will include his own MFT
> (whatever) header, and the list owner will do nothing further. We were
> discussing the case where the author (through ignorance or laziness)
> did nothing and left it to the list owner to supply a sensible
> default, consistent with the culture of the list.

or maybe the author did not add MFT because he wanted the default 
behavior.

or maybe the author did not add MFT because he had a legacy MUA that
didn't support it.

or maybe the author did not add MFT because he wanted uniform behavior
from legacy and current recipients' MUAs.

or maybe the author did not add MFT because he didn't want to endorse
poorly-designed extensions to the mail protocol.

Keith

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 20 Sep 2004 12:17:22 -0400
To: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

>> Okay, I get that.  What I don't buy is the assertion that "the only 
>> reason people
>> use Reply-to-All" is that they want replies to go to the list at 
>> least.  I find
>> Reply-to-All useful in a much wider variety of situations than that, 
>> and I also
>> find that I get a lot of replies-to-all in mail that isn't sent to 
>> any list.
>
> Sure, but I was speaking of the use of Reply-to-All when responding to
> mailing lists, not to messages in general.

I suspect that when people hit "reply to all" to a message from a list 
they generally want the reply to go to everyone who received the 
original message, not "just" to the list.  They don't want to worry 
about which of those recipients are on the list and which ones are not.

Keith

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 20 Sep 2004 12:15:21 -0400
To: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

>> No.  Several cases are valid for this list, and for most lists.  In
>> particular, it's often reasonable to send a message To this list,
>> it's often reasonable to send a message (or a reply) To an
>> individual and Cc this list, and it's sometimes reasonable to send a
>> message To another list and Cc this list.  [*]
>
> Yes, that is what I said. But in most situations and on most lists the
> list address should be in the To:.

you are simply incorrect.

>> Note that there's a subtle but useful difference between a reply that 
>> is
>> addressed To the author of the subject message with a CC to the list,
>> and a reply that is addressed To the list (with or without a CC to the
>> author).
>
> Then please explain to me the subtlety that lead you to send the 
> message I
> am responding to To: me with Cc: the list.

I was responding to a message from you, and the principal purpose of my 
sending the message was to provide information to you.  The list was 
copied because the information might also be useful to others on the 
list , and so that the list would be aware that I've responded (in 
particular, to avoid the common assumption that silence implies 
agreement or assent).

(not that I always take so much care in making sure to and cc are 
appropriately used - I get lazy too sometimes - but in this particular 
instance they were appropriately used.)

Keith

To: [email-masked]
Xref: clerew local.mime:3659
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 20 Sep 2004 10:17:44 GMT
Lines: 53
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Charles Lindsey wrote:

>> It is quite clear to me that _any_solution to the problems we are
>> dicussing will require changes to MUAs before it becomes effective. MFT is
>> a nice solution on the face of it, but requires the most change to
>> existing MUAs.

>And MTAs.

Why MTAs? MSAs perhaps.

>> Mail-Copies-To would he easier to introduce, but it does
>> not do such a good job.

>Not easier -- it has the same problems and requires MUA and MTA
>changes.

What MTA support?

>> Looks like we have to choose some least-harmful
>> alternative. Reply-To is what we have at the moment, and it is clearly not
>> working.

>It works fine for me...

But not for anybody else, apparently.

>> It is well enough defined for us to understand what it would entail.

>Where's the ABNF? Where's the definition of how the field is handled
>w.r.t. message fragmentation and reassembly?  Where's the discussion
>w.r.t. interaction with Reply-To in RFC 2822?  Where's the discussion
>about automatic responses in RFC 3834?

We are discussing a suggestion that it might be introduced as a solution
to the problem. You do not need ABNF and a full draft (though they would
be required eventually). But, if you insist, that you may consult
ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-drums-mail-followup-to-00b.txt.
Oddly, that draft does not actually specify any ABNF, but you may assume
it intended syntax similar to the Reply-To field in RFC 2822.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3660
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Mon, 20 Sep 2004 10:24:15 GMT
Lines: 29
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Charles Lindsey wrote:
>> 
>> 
>> In most cases the list owner will have a sufficiently accurate list of his
>> contributors

>You have completely missed the point; a list owner doesn't know
>what the author desires -- merely having a list of potential
>authors doesn't help.

No, you have completely missed the point. If the author has some special
requirements of his own, he will include his own MFT (whatever) header,
and the list owner will do nothing further. We were discussing the case
where the author (through ignorance or laziness) did nothing and left it
to the list owner to supply a sensible default, consistent with the
culture of the list.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3657
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 20 Sep 2004 09:52:40 GMT
Lines: 46
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>No.  Several cases are valid for this list, and for most lists.  In 
>particular, it's often reasonable to send a message To this list, 
>it's often reasonable to send a message (or a reply) To an 
>individual and Cc this list, and it's sometimes reasonable to send a 
>message To another list and Cc this list.  [*]

Yes, that is what I said. But in most situations and on most lists the
list address should be in the To:.

>Note that there's a subtle but useful difference between a reply that is
>addressed To the author of the subject message with a CC to the list,
>and a reply that is addressed To the list (with or without a CC to the
>author).  

Then please explain to me the subtlety that lead you to send the message I
am responding to To: me with Cc: the list. Indeed all your responses to me
are in that form, yet I note that you respond to some other people with
To: the list (maybe those are the ones who have set Reply-To).

In my collection of unexpired message from this list, I find
   158 messages with To: [email-masked], and
   130 messages with Cc: [email-masked]

I suspect that is more due to habit than to any subtle variation of
intent. But the effect is that using Reply-To to respond to the list just
will not work, and using Reply-to-All works, but sends duplicates which
are unwanted by most of us. I have no reason to suppose that this behavour
is untypical of lists in general.

I also find
   68 messages with Reply-To: [email-masked]
and, not unsurprisingly
   68 messages with From: Bruce Lilly

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3658
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 20 Sep 2004 09:54:46 GMT
Lines: 32
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> Because, except in the case where the list-maintainer automatically
>> inserts Reply-To (a usage often deprecated, though I find it appropriate
>> in many lists that I use), Reply-to-All is the only thing that guarantees
>> that the reply gets sent to the list. Simple Reply will usually just
>> respond to the author.
>> 
>> Therefore, users who want a quiet life and cannot be botherd to
>> cut-and-paste (which is most of us) just hit Reply-to-All, a practice
>> which means duplicate copies to the author and accusations of
>> obnoxiousness. That is the whole problem we are discussing, with a view to
>> find some better method.

>Okay, I get that.  What I don't buy is the assertion that "the only reason people 
>use Reply-to-All" is that they want replies to go to the list at least.  I find
>Reply-to-All useful in a much wider variety of situations than that, and I also
>find that I get a lot of replies-to-all in mail that isn't sent to any list.

Sure, but I was speaking of the use of Reply-to-All when responding to
mailing lists, not to messages in general.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Sun, 19 Sep 2004 21:44:55 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Fri, 17 Sep 2004, Keith Moore wrote:

> Note that there's a subtle but useful difference between a reply that is
> addressed To the author of the subject message with a CC to the list,
> and a reply that is addressed To the list (with or without a CC to the
> author).  

I suspect that the vast majority of people would not understand this 
subtlety, and would therefore not take care to make the UAs behave 
accordingly. I, for one, do not really see any real difference in 
practice. I certainly don't pay any attention to the details of what my 
MUA does when I reply-to-all, though sometimes I wish it would generate

To: author, list

instead of

To: author
Cc: list

which makes removing the author manually more hassle than it need be. 

But most times I just reply-to-all and don't even read what is 
generated.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Sun, 19 Sep 2004 10:15:25 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "D. J. Bernstein" <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

D. J. Bernstein wrote:
> Lilly now proposes three UA reply buttons:

Absolutely wrong. I propose nothing whatsoever to do with "buttons".

Date: Sat, 18 Sep 2004 13:46:06 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Russ Allbery wrote:
> Bruce Lilly <[email-masked]> writes:
> 
> 
>>You have completely missed the point; a list owner doesn't know what the
>>author desires -- merely having a list of potential authors doesn't
>>help.
> 
> 
> The list owner often does, actually.  Mailman has an explicit setting
> saying "please try to suppress duplicates in mail sent to me and to the
> list." [...]

That still misses the point; suppression of duplicates isn't the
only issue.

To: [email-masked]
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
Subject: Re: Understanding response protocols
Date: 18 Sep 2004 21:46:00 +0200
Lines: 54
Sender: [email-masked]

Hallo,

Bruce Lilly <[email-masked]> schrieb/wrote:
> Claus Färber wrote:
>> Further, it does not allow something like this:
>> | From: [email-masked]
>> | To: [email-masked], [email-masked]
>> | Reply-To: [email-masked]
>> | Mail-Followup-To: [email-masked]

> "No, it does not work with existing UAs." Most UAs ignore illegal
> fields such as "Mail-Followup-To".

When discussing a new potential standard, it does not make sense to
slanderously refer to proposed fields as "illegal". They field is
currently undefined but the idea of introducing a new spec is to change  
that.

> And the following achieves what I believe you intended using only
> standard header fields, with (as discussed) the From field for
> narrow responses, Reply-To for default responses, and a user-edited
> selection from all addresses for a wide response:

> From: [email-masked]
> Sender: [email-masked]
> To: [email-masked], [email-masked]
> Reply-To: [email-masked]

A user agent following established practice will send narrow replies to
"[email-masked]" (Reply-To) and broad replies to
"[email-masked], [email-masked]"  
(To, Reply-To), which is also wrong.

                      | narrow replies       |  broad replies
                      | w/ leagacy software  |  w/ leagacy software
----------------------+----------------------+-----------------------
From/Reply-To +       | Reply-To (correct)   |  To (maybe correct)
Mail-Followup-To      |                      |  Reply-To (wrong)
----------------------+----------------------+------------------------
Sender/From +         | Reply-To (wrong)     |  Reply-To (correct)
Reply-To              |                      |  To (wrong)

IOW: Both solutions are not backwards-compatible wrt broad replies but
your proposal (it's not the existing standard because it adds additional
semantics to the existing header fields) also breaks narrow replies (and
Mail<->Netnews gateways).

Please note that you can't put two addresses in the From field either,  
in case that the message has been jointly written by two authors (e.g.  
"[email-masked]" and "[email-masked]").

Claus

Date: 18 Sep 2004 05:40:07 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Lilly now proposes three UA reply buttons:

   * ``narrow'' (From);
   * ``middle'' (Reply-To || From); and
   * ``wide'' (From + Reply-To + To + Cc, I think).

Now, which of these buttons am I supposed to press when I want to follow
up to a mailing list? I don't see an answer to this in Lilly's message.

If the answer is ``wide'': The followup includes too many addresses, as
Lilly admits, so it requires manual editing. In other words, this fails
to solve the most basic problems under discussion.

If the answer is ``middle'': For most of today's messages, the followup
is completely misdirected---the list is _not_ in Reply-To. Yes, the list
is in Reply-To in _some_ cases, but there are billions of exceptions.
This approach will be undeployable unless we first go through a massive
transition to get rid of the exceptions.

If the answer is ``narrow'': This is even worse. The followup is
completely misdirected for practically all of today's messages. Surely
this isn't Lilly's answer. 

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: 18 Sep 2004 05:05:27 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Bruce Lilly writes:
> Something like MFT, for instance, requires changes to senders' and
> recipients' UAs

One of the basic goals here is for followups to exclude the sender's
address upon request from the sender.

The sender wants his MUA to make this request _automatically_ for any
message that he sends to various mailing lists. Old message injectors
don't have this feature, so they have to be changed.

This has nothing to do with the choice of protocol. Every protocol needs
this MUA support. Criticizing Mail-Followup-To on this basis is silly.

As for the recipient's MUA: Yes, Mail-Followup-To needs some changes,
but every one of your proposals requires vastly more changes. Again,
criticizing Mail-Followup-To on this basis is silly.

> and to any MSAs and MTAs that rewrite address fields.

At this point you're inventing problems that don't exist. The software
that creates Mail-Followup-To is responsible for using fully-qualified
domain names. Subsequent transports aren't expected to, and shouldn't,
rewrite Mail-Followup-To.

The post office is expected to touch the envelope (Return-Path,
Received, Delivered-To, etc.) but should never touch the contents. It
amazes me that such a basic principle needs to be stated here.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: 18 Sep 2004 04:36:14 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Bruce Lilly writes:
> Some people use multiple UAs, possibly at multiple locations. Anything
> that requires extensive configuration is a problem.

Even without Mail-Followup-To, having to manually configure several MUAs
is a pain for the user. These users need configuration-sharing tools.
Any good configuration-sharing tool will also handle Mail-Followup-To.

> Also, some people read lists via a web archive; an MUA has no way to
> determine that.

If the user wants to set Mail-Followup-To for a list, he tells the MUA
about that list. End of problem.

Yes, there are many situations where the MUA can reasonably do this by
default, saving even more time, but we're talking about a trivial amount
of user effort either way. This is once per list, not once per message!

> And people change mailing list subscriptions (e.g. when they go on
> vacation).

Someone who doesn't really monitor the list probably isn't setting
Mail-Followup-To in the first place. Anyway, what's your point?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 17 Sep 2004 23:38:37 -0400
To: [email-masked]
Sender: [email-masked]

>> But there's another wrinkle in that the ability to redirect replies is
>> arguably a security risk.[*]  Say an attacker forges a message from
>> someone's boss that tells its recipient to do something costly and
>> irreversible.[...]
>
> Alerts are little more than a band-aid -- the real issue is the
> need for authentication, avoiding the forgery in the first place.

authentication would be nice.  but we should be hesitant to call it a 
"need".  nobody has ever figured out how to make computers understand 
and faithfully implement trust relationships between humans.

From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 17 Sep 2004 23:36:37 -0400
To: [email-masked]
Sender: [email-masked]

> I don't follow that; which part of the specification do you
> believe is responsible for failure of some UAs to display the
> field?

The part that doesn't say that it needs to be obvious to the recipient 
that replies aren't going to the recipient list of the original 
message.

>>>> (a) there's no way to determine the sender's intent (did he want the
>>>> old behavior or the new behavior?)
>>>
>>> Regarding a default set of response recipients (as discussed above),
>>> I see no "old" vs. "new" dichotomy; it's the same behavior (which
>>> in any case is the respondent's (or his UA's) behavior). If the
>>> original author(s) feel(s) that expressing an intent is important,
>>> there are several ways at his.their disposal
>>
>> These exist regardless.  By that argument, we don't need reply-to or
>> mail-followup-to or any other header field to affect how replies are
>> addressed.
>
> No, that's not the argument. You seem to be conflating the
> recipient list with the indication of intent.

You seem to be separating them.  This increases the chance that a vital 
piece of information will be missed because the recipient has to look 
in two places.

>> It could be because
>> the sender is pointing to an alternate address for himself - say
>> because he wants to get replies on his PDA.  Or it could be because 
>> the
>> sender thought replies should go to his secretary, or to a list, or
>> somewhere else.
>
> Perhaps he only wants responses sent to his PDA (or secretary)
> for a limited period of time.  Perhaps he expects different
> recipients to respond to different addresses.  I don't believe
> it practical to devise a way to handle the myriad of
> circumstances that individual authors might under some
> situations like to express -- at least not without adding
> more confusion to the situation (which languages should
> the authors desires be expressed in, which charsets, what
> formats should be used for date and time, how should
> precedence relationships be expressed, etc.).

Having too little information is confusing because it's ambiguous.  
Having too much information is confusing because it's complex.

The simple solution is to let the author supply text  that describes 
why the recipient should or should not use a particular reply address, 
since the decision is going to be have to be made by a human recipient 
(rather than his MUA) anyway.  But this doesn't lend itself to giving 
the recipient a small and fixed number of buttons to choose from, and 
that's the style most MUAs have adopted.

>>>> (b) it would make the effect of setting reply-to even less
>>>> predictable than it is now
>>>
>>> Specifically for "middle" responses, I see no change.
>>
>> We seem to be talking about two different things.  I'm talking about a
>> new header field that would change how (new) UAs compose replies by
>> default.  You seem to be talking about a new reply button.
>
> What do you mean by "default" -- what is the specific
> respondent action that you have in mind that all respondents
> are supposed to conform to?

I don't have any such model of responder behavior in mind.  I have a 
model in mind for a MUA user interface that facilitates a variety of 
responder behaviors.

>>>>> Use of From (ignoring Reply-To when present), as you have
>>>>> suggested is a change to the standard response protocols.
>>>>
>>>> I've suggested lots of things.  I haven't seen any suggestion, by me
>>>> or anybody else, that doesn't have some drawbacks.
>>>
>>> True, but as mentioned yesterday, this particular change has
>>> a rather small scope of impact; it affects only a subset of
>>> UAs, has no impact on MTAs, etc.
>>
>> I disagree.
>
> Would you like to elaborate?

Not in detail.  In brief - it affects the vast majority of MUAs out 
there, and it makes existing uses of reply-to much less reliable.

My transition model is that, at least for many years, recipient MUAs 
need to keep honoring Reply-to (at least in the sense that they make 
the recipient aware that reply-to was used and give him the chance to 
explicitly reply to that address) _unless_ the sender of the message 
also asserted whatever new reply request gets adopted.   If we define a 
new reply request field, we can make sure that existing uses of 
reply-to don't fail.  If we redefine reply-to to behave differently (or 
to be ignored), those existing uses will fail.

>>> For (b), as I've said, I think you were on the right track when
>>> you stated that that should be handled in the message store.
>>
>> My sense is that that answer doesn't sound good to lots of people.
>> I'm still trying to understand why.   I think there are at least
>> two issues here.  One is that it requires substantial changes to
>> existing message stores (if you built one from scratch to handle this 
>> it
>> would be fairly easy).
>
> As mentioned, Cyrus IMAP already has a configurable option
> for this (implemented in the message store).

so all we have to do is get everyone to switch to Cyrus, and then they 
won't want to overload mail-followup-to anymore.  how well do you think 
that will work in practice?

>> Another is that ordinary users have much
>> more ability to change or upgrade their user agents than they have
>> to upgrade their message stores.
>
> That might be so for a user who uses only one UA on only
> one computer to access his messages.  I don't think we
> should restrict our thinking to that model.

nothing says there can't be multiple ways of suppressing duplicates.  
it should be possible to arrange that they won't interfere with each 
other.  the user with the UA or MS that suppresses duplicates can then 
choose whether or not to originate mail with the mechanism that 
suppresses duplicates on replies to lists.

>> So there may be a perception
>> (and it may be correct) that it's easier to deploy a solution to
>> this problem in the MUA than in the message store - even if,
>> from a purely technical perspective, it doesn't work as well as
>> the message store solution.
>
> Unless one is dealing with a large centralized time-sharing
> system, duplicate detection (let alone suppression, for some
> meaning of the term) at an MUA requires that the MUA have
> access to sufficient information to perform the task. An
> MUA that accesses messages by any of the likely protocols
> (POP variants, IMAP) is going to involve substantial
> amounts of client/server traffic.  Better to handle
> duplicate detection/suppression at the MDA or message
> store.

I agree that it's "better" if you control all aspects of the system, 
and it's also "better" if you use multiple MUAs, and it also will work 
more reliably - for a user who can impose such a constraint on his 
message store.  However in my experience most MUAs download all of the 
messages anyway, and most users only use one MUA most of the time.  So 
for those users duplicate suppression in the MUA might be a viable 
option.

heck, I can't even get my home ISP to support IMAP/POP over SSL or TLS 
- which EVERYBODY should be doing.   (and by most metrics they are one 
of the better ISPs in the US)  I don't imagine that I'll get them to 
support duplicate suppression anytime soon.  But if someone adds 
duplicate suppression to any of several different MUAs, I can install 
that MUA on my machines and the fact that my ISP doesn't run the 
message store like I want them to becomes irrelevant.

>>> Oh! Have you never sent a response to the mailbox in the From
>>> field as well as the Reply-To address(es) when Reply-To was
>>> present?
>>
>> Perhaps, but it's been extremely rare - and I probably only did this
>> when the Reply-To addresses were redundant with other addresses
>> that were already in the recipient list.
>
> That wouldn't explain including the From field mailbox when
> it was not present in To or Cc.

what does that have to do with the question?  (or maybe this is a 
rathole?)

>> There are lots of scenarios that could be constructed.  Which ones
>> deserve to have buttons dedicated to them?
>
> If you wish to discuss UI design, a potentially more productive
> approach might be to consider allowing the user to pick and
> choose from among the standard address fields (From, Reply-To,
> To, Cc, Sender, Return-Path) in the original message.  That
> would certainly provide flexibility.

Something like that, yes.

Keith

Date: Fri, 17 Sep 2004 21:26:53 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>>As suggested by Keith, and as discussed in my earlier message, the
>>proposal under discussion is based on individual responses going
>>to the mailbox(es) specified in the From field, when the respondent
>>specifically wishes to direct a response to the original messages
>>author(s).
> 
> 
> I think you need to make it clear that you are referring to some
> "Reply-To-Author" functionality such as has been mentioned here and which
> apparently is available in some agents.

That is what I wrote.

> Personally, I am somewhat dubious about such feature because
>    a) most users will suppose it is the normal way to reply to ordinary
> mails, which it isn't ("Reply-To-From-address" would convey a more
> accurate intention of such a button), and

I don't care if the function is implemented with a GUI button
or some other UI, nor do I care to quibble about specific
labels; the functionality is reply to the author(s) whose
mailboxes are listed in the From field.

>    b) I am very dubious about _any_ automatic method of responding

Automatic responses have not been discussed.

>> Default responses would go to the addresses specified
>>in Reply-To, whether ... [lots of good reasons snipped].
> 
> 
> By "Default response", I presume you mean what the usual "Reply" button
> does (and maybe Reply-to-All also).

"Default"isn't a clear term, and I have recently changed to referring
to use of Reply-To as a "middle" response to differentiate it from
a "narrow" response to the author(s) and from a "wide" response
including original message recipients.

> The real problem here is
> that "Reply-To-All" is the wrong button to use when replying to the list
> but, unfortunately, the "Reply" button will usually do the wrong thing.

If the original message author recommends responses to go to
a list, and indicates so by setting the Reply-To field
accordingly, and the respondent agrees, the a "middle" response
(rather than reply-to-author or reply-to-all) is appropriate.

> Hence the reason why we are having this debate, and hence the reason why
> any solution to this problem is going to involve extra MUA functionality,
> such as a "Reply-to-List" button, or an extra header such as MFT, or
> both.

No extra functionality or fields are required (see above).

>>Wrong. Default responses go to wherever the original message
>>sender set Reply-To to point --
> 
> 
> Which is no solution at all, as various people have pointed out. Anything
> that involves routine manual addition of an extra header everytime someone
> posts to a mailing list is doomed to failure, because you will never
> educate users to do it.

You are the only person insisting that some manual action is
required.  It is not.

> We MUST have a solution where the right thing happens
> automatically (possibly after some configuration by the user). MFT might
> do it. Mail-Copies-To might do it. But Reply-To already has too much
> baggage attached to it, and the only configuration option for it likely to
> be available in current MUAs is to set it to some fixed address for _all_
> outgoing mails.

You are wrong about that.

> It is quite clear to me that _any_solution to the problems we are
> dicussing will require changes to MUAs before it becomes effective. MFT is
> a nice solution on the face of it, but requires the most change to
> existing MUAs.

And MTAs.

> Mail-Copies-To would he easier to introduce, but it does
> not do such a good job.

Not easier -- it has the same problems and requires MUA and MTA
changes.

> Looks like we have to choose some least-harmful
> alternative. Reply-To is what we have at the moment, and it is clearly not
> working.

It works fine for me...

> It is well enough defined for us to understand what it would entail.

Where's the ABNF? Where's the definition of how the field is handled
w.r.t. message fragmentation and reassembly?  Where's the discussion
w.r.t. interaction with Reply-To in RFC 2822?  Where's the discussion
about automatic responses in RFC 3834?

Date: Fri, 17 Sep 2004 20:34:44 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Russ Allbery wrote:

>  I don't see any feasible solution to this problem that
> doesn't require changing all of the UAs over time; even Bruce's solution
> of replying to either From or Reply-To requires changing all the UAs to
> add an option to reply to From, ignoring Reply-To, and to remove the
> option to reply to Reply-To+To+Cc.)

To clarify:

Several UAs already provide separate reply-to-author functions, and
would not need to be modified.  Many others provide other more-or-
less intuitive methods to do the same (double-clicking or right-
clicking on the From line in a GUI, for example, or via cut-and-
paste).  That latter set of UAs is still usable, though perhaps
requires slightly more user effort to reply-to-author.  But that's
already the case for a recipient who wishes to override Reply-To
and reply instead to the mailbox(es) in the From field...

Some sort of broad reply-to-all function is probably desirable,
as least as a starting point for a respondent to reduce the
recipient list, so I'm certainly not proposing that such a broad
response function be prohibited or deprecated; indeed it may be
useful to extend it to include the From field as well as the others.

There is also a crucial difference in *which* UAs need to be
modified in order to support specific functionality, and whether
or not other messaging components should be modified. Something
like MFT, for instance, requires changes to senders' and
recipients' UAs and to any MSAs and MTAs that rewrite address
fields.

Date: Fri, 17 Sep 2004 20:06:24 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Charles Lindsey wrote:

> No, RFC 822 is/was a Standard. Standards do not, by definition, contain
> "errors". "Bugs" maybe, but not errors.

Some standards (and other RFCs) do in fact contain errors.  Many
are listed on the RFC Editor's errata page
http://www.rfc-editor.org/cgi-bin/errata.pl
That page specifically says "errors do sometimes go undetected".
It says nothing about "bugs".

Date: Fri, 17 Sep 2004 20:01:56 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore wrote:

> But there's another wrinkle in that the ability to redirect replies is
> arguably a security risk.[*]  Say an attacker forges a message from 
> someone's boss that tells its recipient to do something costly and
> irreversible.[...]

Alerts are little more than a band-aid -- the real issue is the
need for authentication, avoiding the forgery in the first place.

Date: Fri, 17 Sep 2004 19:56:46 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore wrote:

>>As is usually the case, it pays to differentiate implementation
>>issues from architectural issues.  You have stated that some UAs
>>fail to display Reply-To and that that can be a source of
>>confusion for the users (victims?) of such UAs. That is clearly
>>an implementation issue, one that should be addressed by the
>>authors of such UAs.
> 
> 
> It could also be attributed to a failure in the specifications.

I don't follow that; which part of the specification do you
believe is responsible for failure of some UAs to display the
field?

>>>(a) there's no way to determine the sender's intent (did he want the
>>>old behavior or the new behavior?)
>>
>>Regarding a default set of response recipients (as discussed above),
>>I see no "old" vs. "new" dichotomy; it's the same behavior (which
>>in any case is the respondent's (or his UA's) behavior). If the
>>original author(s) feel(s) that expressing an intent is important,
>>there are several ways at his.their disposal 
> 
> 
> These exist regardless.  By that argument, we don't need reply-to or 
> mail-followup-to or any other header field to affect how replies are
> addressed.  

No, that's not the argument. You seem to be conflating the
recipient list with the indication of intent.

>>You have stated (and I agree) that the
>>respondent's desires w.r.t. responses trump those of the author,
>>so it is in fact the respondent's interpretation (in the absence
>>of any sender indication, or where there is disagreement) that
>>matters.  The authors' intent is at best a recommendation.
> 
> 
> You're reading way too much into this.  The recipient of a message
> wishes to reply to the author of a message, and notices that there's 
> a reply-to field that points to an address he doesn't recognize.
> Should the recipient reply to the From address instead, or should
> he send the reply to the Reply-To address?  He doesn't know, because
> he doesn't know _why_ the sender set reply-to.

Perhaps not, but he presumably knows why he wishes to respond.
While there may in fact be many reasons for an author to
suggest response addresses, there are also many reasons why a
particular recipient might respond.

> It could be because
> the sender is pointing to an alternate address for himself - say 
> because he wants to get replies on his PDA.  Or it could be because the
> sender thought replies should go to his secretary, or to a list, or
> somewhere else.

Perhaps he only wants responses sent to his PDA (or secretary)
for a limited period of time.  Perhaps he expects different
recipients to respond to different addresses.  I don't believe
it practical to devise a way to handle the myriad of
circumstances that individual authors might under some
situations like to express -- at least not without adding
more confusion to the situation (which languages should
the authors desires be expressed in, which charsets, what
formats should be used for date and time, how should
precedence relationships be expressed, etc.).

> The recipient of the message has no idea whether it's
> appropriate to send _his_ message to the reply-to address.

The potential respondent is going to have to think about
it, no matter what. Even if there are a thousand fields
similar to
  Respond-here-on-weekdays: [email-masked]
  Respond-here-for-urgent-matters: [email-masked]
  Respond-here-for-my-assistant: [email-masked]
etc. ad nauseum.

>>>(b) it would make the effect of setting reply-to even less
>>>predictable than it is now
>>
>>Specifically for "middle" responses, I see no change.
> 
> 
> We seem to be talking about two different things.  I'm talking about a
> new header field that would change how (new) UAs compose replies by
> default.  You seem to be talking about a new reply button.

What do you mean by "default" -- what is the specific
respondent action that you have in mind that all respondents
are supposed to conform to?

As far as "buttons" are concerned, I'm not speaking of
any specific type of UI; many UAs already distinguish
among generic "reply", narrow "reply-to-author", and
broad "reply-to-all" functions (whether they use text
interfaces or GUI interfaces is largely irrelevant).

>>>>Use of From (ignoring Reply-To when present), as you have
>>>>suggested is a change to the standard response protocols. 
>>>
>>>I've suggested lots of things.  I haven't seen any suggestion, by me
>>>or anybody else, that doesn't have some drawbacks.
>>
>>True, but as mentioned yesterday, this particular change has
>>a rather small scope of impact; it affects only a subset of
>>UAs, has no impact on MTAs, etc.
> 
> 
> I disagree.

Would you like to elaborate?

>>For (b), as I've said, I think you were on the right track when
>>you stated that that should be handled in the message store. 
> 
> 
> My sense is that that answer doesn't sound good to lots of people.
> I'm still trying to understand why.   I think there are at least
> two issues here.  One is that it requires substantial changes to
> existing message stores (if you built one from scratch to handle this it
> would be fairly easy).

As mentioned, Cyrus IMAP already has a configurable option
for this (implemented in the message store).

> Another is that ordinary users have much 
> more ability to change or upgrade their user agents than they have
> to upgrade their message stores.

That might be so for a user who uses only one UA on only
one computer to access his messages.  I don't think we
should restrict our thinking to that model.

> So there may be a perception
> (and it may be correct) that it's easier to deploy a solution to
> this problem in the MUA than in the message store - even if,
> from a purely technical perspective, it doesn't work as well as
> the message store solution.

Unless one is dealing with a large centralized time-sharing
system, duplicate detection (let alone suppression, for some
meaning of the term) at an MUA requires that the MUA have
access to sufficient information to perform the task. An
MUA that accesses messages by any of the likely protocols
(POP variants, IMAP) is going to involve substantial
amounts of client/server traffic.  Better to handle
duplicate detection/suppression at the MDA or message
store.

>>For
>>several reasons, including the fact that some responses may be
>>sent some considerable time after the original message (e.g.
>>notification to an RFC author of a potential erratum -- there
>>are uncorrected typos in RFC 724 (27 years!), for example), 
> 
> 
> Please consider the possibility that nobody cares about RFC 724
> anymore

It is certainly possible that few people are interested
in correcting errors in RFC 724 -- but that was just one
example; RFCs 2045 (7+ years) is another example.

> and that the RFC Editor doesn't want to fix typos in
> RFCs after they are published.

Perhaps -- but that's not what the RFC Editor's web page
says. In fact it provides an extensive set of errata.

>>Oh! Have you never sent a response to the mailbox in the From
>>field as well as the Reply-To address(es) when Reply-To was
>>present?
> 
> 
> Perhaps, but it's been extremely rare - and I probably only did this
> when the Reply-To addresses were redundant with other addresses 
> that were already in the recipient list.  

That wouldn't explain including the From field mailbox when
it was not present in To or Cc.

> There are lots of scenarios that could be constructed.  Which ones
> deserve to have buttons dedicated to them?

If you wish to discuss UI design, a potentially more productive
approach might be to consider allowing the user to pick and
choose from among the standard address fields (From, Reply-To,
To, Cc, Sender, Return-Path) in the original message.  That
would certainly provide flexibility.

> Note also that in the
> example you gave it probably makes more sense to say "reply 
> ignoring Reply-to" than "reply to both From and Reply-To"

No, for the reason given with the example (to keep the
person at the Reply-To address advised that the situation
is being handled).

To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 17 Sep 2004 16:39:17 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> You have completely missed the point; a list owner doesn't know what the
> author desires -- merely having a list of potential authors doesn't
> help.

The list owner often does, actually.  Mailman has an explicit setting
saying "please try to suppress duplicates in mail sent to me and to the
list."  The way that Mailman implements that feature currently (by
suppressing the list copy since it can't stop the personal copy) does the
wrong thing for me, and therefore I can't currently use it, but nothing
requires that the feature be implemented in that fashion if some better
approach presents itself.

List management software is trending towards having a full-featured
options interface where subscribers can manage preferences like this.

Now, I don't know if the average user will be able to handle using one of
those interfaces, but that's more of a UI design question.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 17 Sep 2004 19:15:17 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>>No, the list owner has no idea of what the message author intended;
>>he might not be subscribed to the list, desiring personal responses
>>to be summarized to the list, he might read the list from a web
>>archive interface w/o being subscribed to the list, he might be
>>sending a notification to one list that a topic of potential interest
>>to that list's subscribers is being discussed on another list (with
>>discussion supposed to take place on the latter list), etc...
> 
> 
> In most cases the list owner will have a sufficiently accurate list of his
> contributors

You have completely missed the point; a list owner doesn't know
what the author desires -- merely having a list of potential
authors doesn't help.

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 17 Sep 2004 10:41:06 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> Okay, I get that.  What I don't buy is the assertion that "the only
> reason people use Reply-to-All" is that they want replies to go to the
> list at least.  I find Reply-to-All useful in a much wider variety of
> situations than that, and I also find that I get a lot of replies-to-all
> in mail that isn't sent to any list.

I agree with Keith.  I use Reply-to-All as my default reply mechanism for
all e-mail messages, since I almost always want my reply to reach all of
the places the original message went.

(Where I don't agree with him is on Mail-Followup-To, which seems to me to
work just fine for private mail as well as for mailing list mail when
people use it.  I don't see any feasible solution to this problem that
doesn't require changing all of the UAs over time; even Bruce's solution
of replying to either From or Reply-To requires changing all the UAs to
add an option to reply to From, ignoring Reply-To, and to remove the
option to reply to Reply-To+To+Cc.)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 17 Sep 2004 13:02:14 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> >> My understanding is the opposite. RFC 2822 seems to me to imply that
> >> the Reply-To address is a substitute for the From address - i.e.(b).
> 
> >I would argue that RFC 2822 propagated the error in RFC 822.  But it's
> >pretty much irrelevant now, because (b) is the widespread behavior.
> 
> No, RFC 822 is/was a Standard. Standards do not, by definition, contain
> "errors". "Bugs" maybe, but not errors.

Okay, this is getting very semantically picky, but to me:

A mistake in the specification is indicative of an error of some kind on
the part of the specification authors or editors.

A bug is a failure to conform to a specification.

But if we want to argue about the meanings of words and who shall be
master, we should just quote Humpty Dumpty (via Lewis Carroll) and be 
done with it.

> If that were not so, then anyone would be able to cherry pick which bits
> of a standard they were free to ignore.

In fact, anyone *is* free to cherry pick which bits of a standard they wish
to ignore.  There are no standards police, no prisons or death penalty for
standards violations.  (though occasionally I wish there were ...)

Keith

Date: Fri, 17 Sep 2004 12:57:24 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> >> ISTM that the only reason that people use Reply-to-All when responding to
> >> mailing lists is that it is the only way of ensuring (without inspecting
> >> the headers carefully and cutting/pasting as necessary) that the reply
> >> goes to the list at least. 
> 
> >I don't know why you believe that. 
> 
> Because, except in the case where the list-maintainer automatically
> inserts Reply-To (a usage often deprecated, though I find it appropriate
> in many lists that I use), Reply-to-All is the only thing that guarantees
> that the reply gets sent to the list. Simple Reply will usually just
> respond to the author.
> 
> Therefore, users who want a quiet life and cannot be botherd to
> cut-and-paste (which is most of us) just hit Reply-to-All, a practice
> which means duplicate copies to the author and accusations of
> obnoxiousness. That is the whole problem we are discussing, with a view to
> find some better method.

Okay, I get that.  What I don't buy is the assertion that "the only reason people 
use Reply-to-All" is that they want replies to go to the list at least.  I find
Reply-to-All useful in a much wider variety of situations than that, and I also
find that I get a lot of replies-to-all in mail that isn't sent to any list.

Keith

Date: Fri, 17 Sep 2004 12:55:38 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> But the common case is when the list is a discussion list (as this
> one) and the expectation is that authors will write to the list with
> suggestions and list members are expected to reply to the list with
> comments, such as "Brilliant!", or "This is nuts!". In such cases, all
> communications should be To: the list, and maybe Cc: the author if he
> has requested it.

No.  Several cases are valid for this list, and for most lists.  In 
particular, it's often reasonable to send a message To this list, 
it's often reasonable to send a message (or a reply) To an 
individual and Cc this list, and it's sometimes reasonable to send a 
message To another list and Cc this list.  [*]

Note that there's a subtle but useful difference between a reply that is
addressed To the author of the subject message with a CC to the list,
and a reply that is addressed To the list (with or without a CC to the
author).  

Keith

[*] Even if there are some lists for which only one case applies, this
is a matter of etiquette, not of protocol :)

Date: Fri, 17 Sep 2004 12:48:43 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> >I also doubt that it's reasonable to use a single header field to 
> >communicate preferences for group replies, because the recipient may 
> >need to act differently depending on _why_ that field was set, and the 
> >recipient's UA may need to act differently (say to alert the recipient 
> >to an exceptional condition) depending on why that field was set.  But 
> >I'm still thinking about this.
> 
> But the MFT field is clearly _capable_ of dealing with a variety of
> sitations,

no, it's not _clearly_ capable, because overloading is often a Bad Idea.

> Now if you want it to be evident which particular situation applies in
> each case (because users may want to modify their responses accordingly),
> then that is a reasonable request, and it could be tackled in various
> ways, such as:
> 
> 1. Invent Yet-Another-header-field
> 2. Add additional features to an existing field (e.g. to MFT or Reply-To),
>    which can be further subdivided into:
>    2a. Fit it into existing syntax (e.g. group syntax or comments)
>    2b. Add new syntax (e.g. MIME-style parameters); could hardly be added
>        to Reply-To, but could be OK for MFT which is not yet standardized.

Yes, I'm considering things like that.  I suspect there's enough deployment
of MFT that we shouldn't change the syntax.  It might be better to use a
different field name entirely if the MFT syntax were not found to be adequate.

Keith

To: [email-masked]
Xref: clerew local.mime:3632
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 17 Sep 2004 10:28:48 GMT
Lines: 61
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> Where did you get the idea that Mail-Followup-To communicates anything
>> other than this?

>your web page on the subject talks about setting MFT automatically, in 
>order to suppress duplicate replies.  and that seems to be by far the 
>most common use of MFT.

>I also doubt that it's reasonable to use a single header field to 
>communicate preferences for group replies, because the recipient may 
>need to act differently depending on _why_ that field was set, and the 
>recipient's UA may need to act differently (say to alert the recipient 
>to an exceptional condition) depending on why that field was set.  But 
>I'm still thinking about this.

But the MFT field is clearly _capable_ of dealing with a variety of
sitations, and since all these situations are going to arise then that
would appear to be a Good Thing.

Now if you want it to be evident which particular situation applies in
each case (because users may want to modify their responses accordingly),
then that is a reasonable request, and it could be tackled in various
ways, such as:

1. Invent Yet-Another-header-field
2. Add additional features to an existing field (e.g. to MFT or Reply-To),
   which can be further subdivided into:
   2a. Fit it into existing syntax (e.g. group syntax or comments)
   2b. Add new syntax (e.g. MIME-style parameters); could hardly be added
       to Reply-To, but could be OK for MFT which is not yet standardized.

Examples:

Mail-Followup-To: LIST:[email-masked],[email-masked];,
                  AUTHOR:Keith Moore <[email-masked]>;,
                  LIST-OWNER:<[email-masked]>;,
                  CC:"Scott Hollenbeck" <[email-masked]>

Reply-To: Mary Jones <[email-masked]> (my secretary)

Mail-Followup-To: [email-masked],[email-masked],
                  Keith Moore <[email-masked]>,<[email-masked]>.
                  "Scott Hollenbeck" <[email-masked]>;
                  reason="multiple-lists,author"; added-by=list-maintainer

Note that MIME-style syntax is appealing insofar as it is extensible
(allowing for x-tokens if registerd tokens are insufficient to the need),
but it is probably not wise in a context where <address>es are used, on
account of parsing difficulties.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3634
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 17 Sep 2004 10:43:35 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> ISTM that the only reason that people use Reply-to-All when responding to
>> mailing lists is that it is the only way of ensuring (without inspecting
>> the headers carefully and cutting/pasting as necessary) that the reply
>> goes to the list at least. 

>I don't know why you believe that. 

Because, except in the case where the list-maintainer automatically
inserts Reply-To (a usage often deprecated, though I find it appropriate
in many lists that I use), Reply-to-All is the only thing that guarantees
that the reply gets sent to the list. Simple Reply will usually just
respond to the author.

Therefore, users who want a quiet life and cannot be botherd to
cut-and-paste (which is most of us) just hit Reply-to-All, a practice
which means duplicate copies to the author and accusations of
obnoxiousness. That is the whole problem we are discussing, with a view to
find some better method.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3633
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 17 Sep 2004 10:36:00 GMT
Lines: 37
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> IMO, when sending to a mailing list, the address of the list should
>> normally go in "To:". "Cc:" should be reserved for cases where the 
>> message
>> is intended for some individual but it is thought the mailing list 
>> might
>> be interested to hear about it.

>more often than not it's appropriate to Cc a list, since To is often 
>used for recipients who are expected to act on a message and Cc used 
>for recipients who just need to be aware of the content of the message. 
>  it's rare that you can expect an entire list to "act on" anything.

Sure. I thought that is what I said.

But the common case is when the list is a discussion list (as this one)
and the expectation is that authors will write to the list with
suggestions and list members are expected to reply to the list with
comments, such as "Brilliant!", or "This is nuts!". In such cases, all
communications should be To: the list, and maybe Cc: the author if he has
requested it.

Yes, there are other lists (e.g. announcement lists) where that behaviour
is inappropriate, and Cc: the list is the right thing, but I harldy think
your "more often than not" applies to those cases.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3635
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 17 Sep 2004 10:47:33 GMT
Lines: 24
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> My understanding is the opposite. RFC 2822 seems to me to imply that
>> the Reply-To address is a substitute for the From address - i.e.(b).

>I would argue that RFC 2822 propagated the error in RFC 822.  But it's
>pretty much irrelevant now, because (b) is the widespread behavior.

No, RFC 822 is/was a Standard. Standards do not, by definition, contain
"errors". "Bugs" maybe, but not errors.

If that were not so, then anyone would be able to cherry pick which bits
of a standard they were free to ignore.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Thu, 16 Sep 2004 16:02:35 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> >> A large part of the problem is that some people think that
> >>
> >> (a)  Reply-To specifies the complete list of recipients that the
> >>      author thinks should receive replies while other people think
> >that>
> >> (b)  Reply-To specifies a list of recipients to be used instead of
> >>      the From address when directing replies.
> 
> >I'd argue that the proper function is (a) but the reality is (b).
> 
> My understanding is the opposite. RFC 2822 seems to me to imply that
> the Reply-To address is a substitute for the From address - i.e.(b).

I would argue that RFC 2822 propagated the error in RFC 822.  But it's
pretty much irrelevant now, because (b) is the widespread behavior.

> >> Mail-Followup-To seems to fit the bill.
> 
> >One of my concerns with MFT is that it's being promoted and used as a
> >way to suppress some kinds of duplicate copies of replies.  There's a
> >conflict between using a field like this to suppress duplicate copies
> >and using the same field to indicate whether the author thinks
> >replies should go to somewhere besides "everyone who received this
> >message":
> 
> MFT tells where replies are to be sent in the case of a Reply-to-All
> (or maybe a Reply-to-List if avaiable). Its chief merit is that it has
> the flexibility to fulfil both the roles you mention

As far as I can tell, that's not a feature, it's a bug.

> >- The recipient's user interface needs to act differently in these
> >two cases - in the first case it's just a normal "reply all" since 
> >everybody is getting a copy of the message.  In the second case the 
> >replier needs to be aware that the reply is going to a different set
> >of recipients than is normal, and it seems appropriate for the MUA to
> >
> >provide some kind of alert to that effect.
> 
> No problem with an alert, provided I have the option to configure it
> off.

One of the problems with having alerts is that if they happen too often,
they'll annoy the user but to no useful effect.  i.e. they'll still
annoy one part of his brain but he'll just accept the default action
without thinking about it.  Which is worse than not having alerts. 

That's part of why using MFT for both duplicate suppression and reply
delegation seems like a problem to me - you don't want the alerts for
duplicate suppression (since the message is still going to everyone the
replier thought it should go to) but you might want them for reply
delegation (when the message is going to some other set of recipients).

But there's another wrinkle in that the ability to redirect replies is
arguably a security risk.[*]  Say an attacker forges a message from 
someone's boss that tells its recipient to do something costly and
irreversible.  If the recipient replies to confirm the message, the boss
will see the reply and may have a chance to stop the action.  But if the
attacker also sets reply-to to point to somewhere else, and the
recipient doesn't notice, then the boss won't see the reply.  From that
point-of-view you might like to have an alert any time replies are
redirected from the default, or you might like to insist that such
replies require explicit confirmation by the replier.  And again, that
set of conditions might happen so often that the alerts will be worse
than useless.

So I'm trying to understand whether there is a set of conditions in
which the alerts would actually be helpful.

Keith

[*] and yes, it's a risk we've accepted for ~23 years, but that doesn't
mean it's not worth considering if we're going to change how replies
work.

Date: Thu, 16 Sep 2004 15:45:37 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> >b) you are conflating at least two things here - one being whether 
> >people want to get duplicate copies of a message sent to a particular 
> >address (IMHO it's fairly safe to assume that most do not want 
> >duplicate copies), another being whether senders prefer that replies 
> >reach everyone who received a copy of the original message - or at 
> >least, don't mind having this as a default.
> 
> Possibly so. But you now seem to accept that the number who find duplicate
> replies "obnoxious" is nearer 90% than 50% (which indicates that some
> change to protocols and/or practice is definitely needed).

"most" implies more than half.  it does not imply nearness to 90%.

> As to the number of people who would routinely intend replies to go to all
> of the original recipients, even where mailing lists are not involved, I
> would expect that actually to be considerably less than the 50% I allowed.

I would expect it to be more than half.
(hmmm.  wonder if any of the webmail services keeps stats on such things?)

> ISTM that the only reason that people use Reply-to-All when responding to
> mailing lists is that it is the only way of ensuring (without inspecting
> the headers carefully and cutting/pasting as necessary) that the reply
> goes to the list at least. 

I don't know why you believe that. 

Keith

Date: Thu, 16 Sep 2004 13:37:22 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> Keith Moore wrote:
> >>>And FWIW, I'm in agreement with the view that Reply-To is too
> >messed up>>to be salvaged.
> >>
> >>(once again) What are the specific issues that you have in mind?
> > 
> > 
> > The way Reply-To is implemented, it is rarely useful and the
> > behavior can be confusing to repliers.
> 
> For clarity, I believe that you mean the way that the behavior
> of UAs w.r.t. the Reply-To field is implemented; otherwise it's
> difficult to envision what you mean by the "implementation" of the
> Reply-To field.

Yes.  But the reason that Reply-To was implemented that way can be
traced to language in RFC 822 that implies that Reply-To replaces From.

> As is usually the case, it pays to differentiate implementation
> issues from architectural issues.  You have stated that some UAs
> fail to display Reply-To and that that can be a source of
> confusion for the users (victims?) of such UAs. That is clearly
> an implementation issue, one that should be addressed by the
> authors of such UAs.

It could also be attributed to a failure in the specifications.

> > Changing how reply-to works probably wouldn't work very well because
> 
> Again when you speak of "how reply-to works", I believe that
> you are discussing UA implementation issues.  

Yes, but any changes to such behavior, if they were to take place, would
probably need to be prompted by new specifications or changes to
existing specifications.

> To the extent that
> some fail to display the field, changing that behavior of the
> implementation would be an improvement.  

Failure to display the field is only one of several problems with 
the way Reply-To is handled today.

> Use of the Reply-To
> address list as a middle (neither "narrow" nor "wide") set of
> recipients for responses doesn't seem to be any sort of change,

If it became widespread, that would certainly be a departure from
existing practice.   However I don't think that widespread 
implementation of "middle" reply would be a step in a useful direction.

> > (a) there's no way to determine the sender's intent (did he want the
> > old behavior or the new behavior?)
> 
> Regarding a default set of response recipients (as discussed above),
> I see no "old" vs. "new" dichotomy; it's the same behavior (which
> in any case is the respondent's (or his UA's) behavior). If the
> original author(s) feel(s) that expressing an intent is important,
> there are several ways at his.their disposal 

These exist regardless.  By that argument, we don't need reply-to or 
mail-followup-to or any other header field to affect how replies are
addressed.  

> You have stated (and I agree) that the
> respondent's desires w.r.t. responses trump those of the author,
> so it is in fact the respondent's interpretation (in the absence
> of any sender indication, or where there is disagreement) that
> matters.  The authors' intent is at best a recommendation.

You're reading way too much into this.  The recipient of a message
wishes to reply to the author of a message, and notices that there's 
a reply-to field that points to an address he doesn't recognize.
Should the recipient reply to the From address instead, or should
he send the reply to the Reply-To address?  He doesn't know, because
he doesn't know _why_ the sender set reply-to.  It could be because
the sender is pointing to an alternate address for himself - say 
because he wants to get replies on his PDA.  Or it could be because the
sender thought replies should go to his secretary, or to a list, or
somewhere else.  The recipient of the message has no idea whether it's
appropriate to send _his_ message to the reply-to address.

> > (b) it would make the effect of setting reply-to even less
> > predictable than it is now
> 
> Specifically for "middle" responses, I see no change.

We seem to be talking about two different things.  I'm talking about a
new header field that would change how (new) UAs compose replies by
default.  You seem to be talking about a new reply button.

> >>Use of From (ignoring Reply-To when present), as you have
> >>suggested is a change to the standard response protocols. 
> > 
> > I've suggested lots of things.  I haven't seen any suggestion, by me
> > or anybody else, that doesn't have some drawbacks.
> 
> True, but as mentioned yesterday, this particular change has
> a rather small scope of impact; it affects only a subset of
> UAs, has no impact on MTAs, etc.

I disagree.

> >>The sole changes are (1) added support for narrow
> >>responses to the From field mailboxes for UAs which do not
> >>already have such a mechanism, 
> > 
> > 
> > Except that (a) we'd still like to have ways for an author to
> > recommend that replies go elsewhere (i.e. a way that actually makes
> > sense when the replier chooses "reply all") and (b) lots of people
> > would like to have a simple way of minimizing duplicate copies of
> > replies.
> 
> For (b), as I've said, I think you were on the right track when
> you stated that that should be handled in the message store. 

My sense is that that answer doesn't sound good to lots of people.
I'm still trying to understand why.   I think there are at least
two issues here.  One is that it requires substantial changes to
existing message stores (if you built one from scratch to handle this it
would be fairly easy).  Another is that ordinary users have much 
more ability to change or upgrade their user agents than they have
to upgrade their message stores.  So there may be a perception 
(and it may be correct) that it's easier to deploy a solution to
this problem in the MUA than in the message store - even if,
from a purely technical perspective, it doesn't work as well as
the message store solution.

> For
> several reasons, including the fact that some responses may be
> sent some considerable time after the original message (e.g.
> notification to an RFC author of a potential erratum -- there
> are uncorrected typos in RFC 724 (27 years!), for example), 

Please consider the possibility that nobody cares about RFC 724
anymore - and that the RFC Editor doesn't want to fix typos in
RFCs after they are published.

> and
> as noted yesterday, mailing list subscriptions can change at a
> relatively quick pace.  For "wide" responses ("reply-all"), some
> editing is likely going to be required by the respondent based
> on why he is responding (see below) -- there is unlikely to be
> a "one-size-fits-all" solution for "wide" responses.
> 
> >>and (2) wide responses
> >>possibly including From even when Reply-To is present.
> > 
> > 
> > that's just nuts.
> 
> Oh! Have you never sent a response to the mailbox in the From
> field as well as the Reply-To address(es) when Reply-To was
> present?

Perhaps, but it's been extremely rare - and I probably only did this
when the Reply-To addresses were redundant with other addresses 
that were already in the recipient list.  

> > if reply-to is present, the sender almost certainly
> > intended it to substitute for from, since that's how it almost
> > universally works these days.   replying to both is completely
> > wrong.
> 
> Consider the following scenario:

There are lots of scenarios that could be constructed.  Which ones
deserve to have buttons dedicated to them?  Note also that in the
example you gave it probably makes more sense to say "reply 
ignoring Reply-to" than "reply to both From and Reply-To"

Keith

To: [email-masked]
Xref: clerew local.mime:3621
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Thu, 16 Sep 2004 10:31:19 GMT
Lines: 68
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Charles Lindsey wrote:

>> Well there are at least three places it could put information to help a
>> subsequent MUA:
>>     Reply-To:
>>     Mail-Follouwps-To:
>>     Mail-Copies-To:
>> and if none of those suffices, then we could always invent another one.

>Only one of the infinity of field that you propose is a standard
>field recognized by UAs and MTAs.  Any other than that one would
>require updating all UAs and many MTAs.

Yes, but this is a thread which started with a proposal to introduce some
new standard headers, so proposing new standard headers would seem to be
on topic.

It is clear to me that there is a problem, and that it is only going to be
solved decently by updating MUAs in one way or another. Most other
participants seem to accept that. It may be that, during the transitional
period, things will get worse before they get better, but that may be a
price we have to pay.

>> Speaking *generally*, the list-owner is in the best position to know the
>> culture, and that will affect how he fills in whatever header he chooses
>> to insert.

>No, the list owner has no idea of what the message author intended;
>he might not be subscribed to the list, desiring personal responses
>to be summarized to the list, he might read the list from a web
>archive interface w/o being subscribed to the list, he might be
>sending a notification to one list that a topic of potential interest
>to that list's subscribers is being discussed on another list (with
>discussion supposed to take place on the latter list), etc...

In most cases the list owner will have a sufficiently accurate list of his
contributors that he will be able to do a better job than is done at
present. The only people disadvantaged will be those who post to the list
by unconventional means (a minority) and who may in consequence receive
personal replies that they do not want. Remember that we are speaking of a
list owner who inserts MFT (or Reply-To) containing just the list plus
posters believed to be unsubscribed. And then only if such a header was
not already present, so allowing that minority to fix the matter to their
satisfaction by taking a little extra trouble.

>> But relying on the User to fill in Reply-To would be even worse (indeed
>> any solution that requires manual action by the user on _every_ response
>> to a list is doomed from the start).

>Your assumptions are unfounded. Many UAs provide for an easily-changed
>"identity" that carries a default Reply-To field, or can use a folder-
>specific Reply-To default.

And many user agents don't. And many unsophisticated users will not use
those features even when provided.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3620
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 16 Sep 2004 10:09:59 GMT
Lines: 61
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> A large part of the problem is that some people think that
>>
>> (a)  Reply-To specifies the complete list of recipients that the author
>>      thinks should receive replies
>>
>> while other people think that
>>
>> (b)  Reply-To specifies a list of recipients to be used instead of the
>>      From address when directing replies.

>I'd argue that the proper function is (a) but the reality is (b).

My understanding is the opposite. RFC 2822 seems to me to imply that the
Reply-To address is a substitute for the From address - i.e.(b).

I would never suppose that a Reply-to-All button should do other than what
it says (and certainly that is what both the MUAs available on my machine
do).

>(I seem to recall that Dave Crocker once argued that the intent was 
>(b), but I may recall incorrectly.)

Then I seem to be in good company :-) .

>> Mail-Followup-To seems to fit the bill.

>One of my concerns with MFT is that it's being promoted and used as a 
>way to suppress some kinds of duplicate copies of replies.  There's a 
>conflict between using a field like this to suppress duplicate copies 
>and using the same field to indicate whether the author thinks replies 
>should go to somewhere besides "everyone who received this message":

MFT tells where replies are to be sent in the case of a Reply-to-All (or
maybe a Reply-to-List if avaiable). Its chief merit is that it has the
flexibility to fulfil both the roles you mention, plus the case of
crossposts between several mailing lists. That, of course, assumes that it
is used correctly; ensuring that it is used correctly may turn out to be
its biggest problem (hence the desirability of MUA support for generating
it).

>- The recipient's user interface needs to act differently in these two 
>cases - in the first case it's just a normal "reply all" since 
>everybody is getting a copy of the message.  In the second case the 
>replier needs to be aware that the reply is going to a different set of 
>recipients than is normal, and it seems appropriate for the MUA to 
>provide some kind of alert to that effect.

No problem with an alert, provided I have the option to configure it off.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3619
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 16 Sep 2004 09:42:53 GMT
Lines: 48
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> No, that just illustrates the problem we are discussing. Approximately 
>> 50%
>> of users (or slightly less by my counting) are happy for repliers to 
>> use
>> "reply all". But you must not let the fact that you yourself are in 
>> that
>> 50% blind you to the fact that the other 50% (or slightly more by my
>> counting) are vehemently opposed to any default action that results in
>> their receiving duplicate copies.

>a) I don't have any reason to have confidence that your 50% figure is 
>representative of the preferences of Internet email users.

It seems to be representative of the participants in this thread.

>b) you are conflating at least two things here - one being whether 
>people want to get duplicate copies of a message sent to a particular 
>address (IMHO it's fairly safe to assume that most do not want 
>duplicate copies), another being whether senders prefer that replies 
>reach everyone who received a copy of the original message - or at 
>least, don't mind having this as a default.

Possibly so. But you now seem to accept that the number who find duplicate
replies "obnoxious" is nearer 90% than 50% (which indicates that some
change to protocols and/or practice is definitely needed).

As to the number of people who would routinely intend replies to go to all
of the original recipients, even where mailing lists are not involved, I
would expect that actually to be considerably less than the 50% I allowed.

ISTM that the only reason that people use Reply-to-All when responding to
mailing lists is that it is the only way of ensuring (without inspecting
the headers carefully and cutting/pasting as necessary) that the reply
goes to the list at least. It is just the easiest and safest thing to do,
irrespective of whether others find it "obnoxious".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Wed, 15 Sep 2004 21:11:35 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Charles Lindsey wrote:

> The "less technically oriented" user, and especially a newbie who has just
> joined the list, will do whatever his MUA defaults to. Agreed, an MUA that
> understands MFT should keep a database of lists that the user has had
> occasion to use, and should ask whether that user is subscribed when a new
> list is encountered for the first time. It can then generate an
> appropriate MFT header. That AIUI is how MFT is intended to operate.

Some people use multiple UAs, possibly at multiple locations. Anything
that requires extensive configuration is a problem.  Also, some people
read lists via a web archive; an MUA has no way to determine that.
And people change mailing list subscriptions (e.g. when they go on
vacation).

Date: Thu, 16 Sep 2004 10:29:03 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore wrote:
>>>And FWIW, I'm in agreement with the view that Reply-To is too messed up
>>>to be salvaged.
>>
>>(once again) What are the specific issues that you have in mind?
> 
> 
> The way Reply-To is implemented, it is rarely useful and the behavior can 
> be confusing to repliers.

For clarity, I believe that you mean the way that the behavior
of UAs w.r.t. the Reply-To field is implemented; otherwise it's
difficult to envision what you mean by the "implementation" of the
Reply-To field.

As is usually the case, it pays to differentiate implementation
issues from architectural issues.  You have stated that some UAs
fail to display Reply-To and that that can be a source of
confusion for the users (victims?) of such UAs. That is clearly
an implementation issue, one that should be addressed by the
authors of such UAs.

> But the marginally useful behavior is very
> widely deployed, and there are a few circumstances where it is useful.

We might disagree about "marginally"...

> Changing how reply-to works probably wouldn't work very well because

Again when you speak of "how reply-to works", I believe that
you are discussing UA implementation issues.  To the extent that
some fail to display the field, changing that behavior of the
implementation would be an improvement.  Use of the Reply-To
address list as a middle (neither "narrow" nor "wide") set of
recipients for responses doesn't seem to be any sort of change,
at least for UAs that I am familiar with (given that some do
have some sort of additional "narrow" and/or "wide" types of
response functionality, and in this paragraph I'm not discussing
how the Reply-To field is used for those).

> (a) there's no way to determine the sender's intent (did he want the 
> old behavior or the new behavior?)

Regarding a default set of response recipients (as discussed above),
I see no "old" vs. "new" dichotomy; it's the same behavior (which
in any case is the respondent's (or his UA's) behavior). If the
original author(s) feel(s) that expressing an intent is important,
there are several ways at his.their disposal (as mentioned in a
message to this list yesterday) to so indicate (i.e. "no way to
determine..." isn't quite accurate, regardless of whether there
is any "old" vs. "new").  You have stated (and I agree) that the
respondent's desires w.r.t. responses trump those of the author,
so it is in fact the respondent's interpretation (in the absence
of any sender indication, or where there is disagreement) that
matters.  The authors' intent is at best a recommendation.

> (b) it would make the effect of setting reply-to even less predictable
> than it is now

Specifically for "middle" responses, I see no change. For
"narrow" responses, the From field is usually appropriate; in
some specific instances the Sender field or the envelope address
or some other address (e.g. list maintainer) may be appropriate --
it depends on the respondent's purpose.  There may well be an
issue for "wide" responses (see below), but the recipient list
for such responses will almost always require some editing.

> (c) it would break behavior that is occasionally useful (e.g.,
> setting reply-to on a message with one recipient is unambiguous).

And exactly what "would break"? A "middle" response still
goes to where Reply-To points (or From if there is no Reply-To
field), and a "narrow" response to From mailbox(es) would be
unaffected.

>>Use of From (ignoring Reply-To when present), as you have
>>suggested is a change to the standard response protocols.
> 
> 
> I've suggested lots of things.  I haven't seen any suggestion, by me or
> anybody else, that doesn't have some drawbacks.

True, but as mentioned yesterday, this particular change has
a rather small scope of impact; it affects only a subset of
UAs, has no impact on MTAs, etc.

>>The sole changes are (1) added support for narrow
>>responses to the From field mailboxes for UAs which do not
>>already have such a mechanism, 
> 
> 
> Except that (a) we'd still like to have ways for an author to recommend
> that replies go elsewhere (i.e. a way that actually makes sense when the
> replier chooses "reply all") and (b) lots of people would like to have 
> a simple way of minimizing duplicate copies of replies.

For (b), as I've said, I think you were on the right track when
you stated that that should be handled in the message store. For
several reasons, including the fact that some responses may be
sent some considerable time after the original message (e.g.
notification to an RFC author of a potential erratum -- there
are uncorrected typos in RFC 724 (27 years!), for example), and
as noted yesterday, mailing list subscriptions can change at a
relatively quick pace.  For "wide" responses ("reply-all"), some
editing is likely going to be required by the respondent based
on why he is responding (see below) -- there is unlikely to be
a "one-size-fits-all" solution for "wide" responses.

>>and (2) wide responses
>>possibly including From even when Reply-To is present.
> 
> 
> that's just nuts.

Oh! Have you never sent a response to the mailbox in the From
field as well as the Reply-To address(es) when Reply-To was
present?

> if reply-to is present, the sender almost certainly
> intended it to substitute for from, since that's how it almost universally
> works these days.   replying to both is completely wrong.

Consider the following scenario:

  From: A
  To: B, C, D
  Reply-To: C
  Date: Tue, 14 Sep 2004 12:34:56 -0700

  I'm delegating handling of the widget project to C. Deadline
  is next Thursday.

where A is delegating some action to one of the recipients, with
the intent of having any responses go to C rather than to A (in
the From field).

  From: B
  To: A
  Cc: C, D
  Date: Tue, 14 Sep 2004 12:35:15 -0700

  There may be a problem; C started his two-week vacation on
  Monday, so he won't be back until the week after next. What
  should we do?

Clearly it would be rather pointless for B to respond only to
C.  The Cc to C is so that C can see that the matter has been
addressed (when he checks his email on his return, or if he
checks it while on vacation). The copy to D also informs D of
the issue and may spare A receiving another message notifying
him of C's absence.

So it is not "completely wrong" -- what is appropriate depends
on the respondent's reason for responding.  If neither the
original author-specified recommendation (the "middle" response
recipient set) nor a "narrow" response is appropriate for the
respondent's purpose. he is left with some sort of "wide"
response (which would probably have to be hand-edited) or some
sort of hand-crafted recipient list.  In the case of an edited
"wide" response list, it is generally easier and less error-prone
to delete unwanted elements from a list than it is to manually
re-enter elements which may have been omitted; therefore it is
somewhat better in principle to hand the user a complete list
for editing than to force him to cut&paste or re-keyboard etc.

In the specific scenario above -- and yes, that sort of thing
does happen -- I'm not aware of any UAs that provide a specific
function to address a response as indicated. However, in most
existing UAs it could be generated either from a "narrow"
response with added Ccs or from a "wide" response with some
cutting and pasting (or exchanging some Ccs and Tos).  Which
brings us back to the point about the respondent's purpose -- a
UA can provide a small set of canned mechanisms to cover common
cases such as "middle" responses and "narrow" responses to the
author(s), but because it is not practical to anticipate all
things a respondent might wish to do, it is not practical to
provide for all such things; at best a UA can provide a "blanket"
"wide" response recipient set and make it reasonably convenient
for a respondent to edit that set according to his purpose, in
addition to the small set of canned mechanisms.

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 16 Sep 2004 08:28:54 -0400
To: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

> IMO, when sending to a mailing list, the address of the list should
> normally go in "To:". "Cc:" should be reserved for cases where the 
> message
> is intended for some individual but it is thought the mailing list 
> might
> be interested to hear about it.

more often than not it's appropriate to Cc a list, since To is often 
used for recipients who are expected to act on a message and Cc used 
for recipients who just need to be aware of the content of the message. 
  it's rare that you can expect an entire list to "act on" anything.

Keith

To: [email-masked]
Xref: clerew local.mime:3612
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 15 Sep 2004 14:16:45 GMT
Lines: 108
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>D. J. Bernstein wrote:

>> Specifically: A huge number of today's messages have a suboptimal reply
>> address in From, the desired reply address in Reply-To,

>As suggested by Keith, and as discussed in my earlier message, the
>proposal under discussion is based on individual responses going
>to the mailbox(es) specified in the From field, when the respondent
>specifically wishes to direct a response to the original messages
>author(s).

I think you need to make it clear that you are referring to some
"Reply-To-Author" functionality such as has been mentioned here and which
apparently is available in some agents.

Personally, I am somewhat dubious about such feature because
   a) most users will suppose it is the normal way to reply to ordinary
mails, which it isn't ("Reply-To-From-address" would convey a more
accurate intention of such a button), and
   b) I am very dubious about _any_ automatic method of responding to the
>From address (RFC strongly suggests that it is not normal behaviour for
any sort of reply mechanism, and it seems an odd thing to do when the
normal use of Reply-To by authors, as commonly understood, is "please do
not reply to my From address, use this one instead"). For the occasional
user who has good reason to do otherwise, Cut-and-Paste is plenty good
enough.

>  Default responses would go to the addresses specified
>in Reply-To, whether ... [lots of good reasons snipped].

By "Default response", I presume you mean what the usual "Reply" button
does (and maybe Reply-to-All also).

>> and the desired
>> followup addresses in To etc.

I think at this point it would be useful to establish the proper
distinction between To: and Cc: when sending to a mailing list (to be
documented as BCP somewhere).

IMO, when sending to a mailing list, the address of the list should
normally go in "To:". "Cc:" should be reserved for cases where the message
is intended for some individual but it is thought the mailing list might
be interested to hear about it.

But that is not what currently happens in many cases where a replier
presses "Reply-To-All". In that case, one usually gets the original author
in To: and the mailing list in Cc:, whereas in most situations common
sense would have put them the other way around. The real problem here is
that "Reply-To-All" is the wrong button to use when replying to the list
but, unfortunately, the "Reply" button will usually do the wrong thing.
Hence the reason why we are having this debate, and hence the reason why
any solution to this problem is going to involve extra MUA functionality,
such as a "Reply-to-List" button, or an extra header such as MFT, or
both.

>Wrong. Default responses go to wherever the original message
>sender set Reply-To to point --

Which is no solution at all, as various people have pointed out. Anything
that involves routine manual addition of an extra header everytime someone
posts to a mailing list is doomed to failure, because you will never
educate users to do it. We MUST have a solution where the right thing happens
automatically (possibly after some configuration by the user). MFT might
do it. Mail-Copies-To might do it. But Reply-To already has too much
baggage attached to it, and the only configuration option for it likely to
be available in current MUAs is to set it to some fixed address for _all_
outgoing mails.

>> Moving it means
>> changing and redeploying a huge number of programs, including homegrown
>> mail scripts that haven't been touched for years.

>Whereas none of any of the other proposals to date would require
>any changes whatsoever, right? :-)

It is quite clear to me that _any_solution to the problems we are
dicussing will require changes to MUAs before it becomes effective. MFT is
a nice solution on the face of it, but requires the most change to
existing MUAs. Mail-Copies-To would he easier to introduce, but it does
not do such a good job. Looks like we have to choose some least-harmful
alternative. Reply-To is what we have at the moment, and it is clearly not
working.

>> For comparison: Mail-Followup-To avoids all the costs of that first
>> transition step.

>Nonsense. First it has to be properly defined.

It is well enough defined for us to understand what it would entail. If we
decide it is the way we might want to go, then someone can write a draft
with a view to a Proposed Standard, and then we can discuss it, and maybe
tweak it to do better.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Thu, 16 Sep 2004 09:13:34 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, 15 Sep 2004, Alan Barrett wrote:

> (a)  Reply-To specifies the complete list of recipients that the author
>      thinks should receive replies
> 
> while other people think that
> 
> (b)  Reply-To specifies a list of recipients to be used instead of the
>      From address when directing replies.

[snip]

> Meaning (b) of the Reply-To field is so deeply entrenched that I
> think it would be impossible to get the world to use Reply-To with
> meaning (a).  So we seem to need a new field to have meaning (a).
> Mail-Followup-To seems to fit the bill.
> 
> I would not be opposed to redefining Reply-To to have meaning (b).  Many
> people use it that way already.

FWIW, I entirely agree with Alan's view. 

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 15 Sep 2004 22:27:09 -0400
To: "D. J. Bernstein" <[email-masked]>
Sender: [email-masked]

> Where did you get the idea that Mail-Followup-To communicates anything
> other than this?

your web page on the subject talks about setting MFT automatically, in 
order to suppress duplicate replies.  and that seems to be by far the 
most common use of MFT.

I also doubt that it's reasonable to use a single header field to 
communicate preferences for group replies, because the recipient may 
need to act differently depending on _why_ that field was set, and the 
recipient's UA may need to act differently (say to alert the recipient 
to an exceptional condition) depending on why that field was set.  But 
I'm still thinking about this.

Keith

Date: 16 Sep 2004 01:10:10 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore writes:
> There's a conflict between using a field like this to suppress
> duplicate copies and using the same field to indicate whether the
> author thinks replies should go to somewhere besides "everyone who
> received this message"

Mail-Followup-To specifies an address list for followups, overriding the
usual (Reply-To||From)+To+Cc.

There are many reasons for a sender to set Mail-Followup-To. Maybe the
sender wants to eliminate duplicates. Maybe the sender wants to redirect
discussion somewhere else. Maybe the sender has some other purpose. In
every case, Mail-Followup-To communicates the bottom line: an address
list for followups.

Where did you get the idea that Mail-Followup-To communicates anything
other than this? It doesn't. It says nothing about the sender's reasons.
It simply specifies an address list for followups. End of story.

If you do want to communicate something else, use a new header field.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Wed, 15 Sep 2004 13:56:10 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> > And FWIW, I'm in agreement with the view that Reply-To is too messed up
> > to be salvaged.
> 
> (once again) What are the specific issues that you have in mind?

The way Reply-To is implemented, it is rarely useful and the behavior can 
be confusing to repliers.  But the marginally useful behavior is very 
widely deployed, and there are a few circumstances where it is useful.

Changing how reply-to works probably wouldn't work very well because

(a) there's no way to determine the sender's intent (did he want the 
old behavior or the new behavior?)

(b) it would make the effect of setting reply-to even less predictable
than it is now

(c) it would break behavior that is occasionally useful (e.g.,
setting reply-to on a message with one recipient is unambiguous).

> > Even though the current behavior is very sub-optimal,
> > it is still occasionally useful and there are a lot of people who expect
> > it to work the way it does now.
> 
> Use of From (ignoring Reply-To when present), as you have
> suggested is a change to the standard response protocols.

I've suggested lots of things.  I haven't seen any suggestion, by me or
anybody else, that doesn't have some drawbacks.

> The sole changes are (1) added support for narrow
> responses to the From field mailboxes for UAs which do not
> already have such a mechanism, 

Except that (a) we'd still like to have ways for an author to recommend
that replies go elsewhere (i.e. a way that actually makes sense when the
replier chooses "reply all") and (b) lots of people would like to have 
a simple way of minimizing duplicate copies of replies.

> and (2) wide responses
> possibly including From even when Reply-To is present.

that's just nuts.  if reply-to is present, the sender almost certainly
intended it to substitute for from, since that's how it almost universally
works these days.   replying to both is completely wrong.

Keith

Date: Wed, 15 Sep 2004 10:43:59 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: =?ISO-8859-1?Q?Claus_F=E4rber?= <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Claus Färber wrote:
> Bruce Lilly <[email-masked]> schrieb/wrote:
> 
>>D. J. Bernstein wrote:
>>
>>>Let me emphasize that the goal---followups to [email-masked] and
>>>replies to [email-masked] _not_ achieved by the old protocol ``reply
>>>to Reply-To||From; follow up to To+Cc+(Reply-To||From).''
> 
> 
>>But Reply-To: [email-masked] / From: [email-masked] does work for
>>responses to the list (using Reply-To) or to an individual (using
>>From). Without changing semantics of any fields. Without adding new
>>fields.  Without expecting UAs to pay attention to an undefined field.
>> And which works with existing UAs.
> 
> 
> No, it does not work with existing UAs.

It works fine with at least pine and Kmail using explicitly
provided response functions. Probably others. A respondent who
wishes to respond to the From field mailbox(es) can easily do
so w/o a specific command or button in at least Netscape/Mozilla,
Ximian Evolution, and Microsoft Outlook; probably many others.
N.B. these are not obscure UAs; they are widely used.

> Further, it does not allow something like this:
> 
> | From: [email-masked]
> | To: [email-masked], [email-masked]
> | Reply-To: [email-masked]
> | Mail-Followup-To: [email-masked]

"No, it does not work with existing UAs." Most UAs ignore illegal
fields such as "Mail-Followup-To".  Such UAs that follow established
standard response protocols would send a "narrow" reply to
[email-masked] and their "broad" reply to all addresses in the
standard address fields.  "Mail-Followup-To" is an illegal field
and is therefore ignored by mail protocols.

And the following achieves what I believe you intended using only
standard header fields, with (as discussed) the From field for
narrow responses, Reply-To for default responses, and a user-edited
selection from all addresses for a wide response:

From: [email-masked]
Sender: [email-masked]
To: [email-masked], [email-masked]
Reply-To: [email-masked]

Date: Wed, 15 Sep 2004 11:35:16 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore wrote:
>>D. J. Bernstein wrote:
>>
>>
>>>Specifically: A huge number of today's messages have a suboptimal
>>>reply address in From, the desired reply address in Reply-To,
>>
>>As suggested by Keith, and as discussed in my earlier message, the
>>proposal under discussion is [...]
> 
> 
> I wasn't aware that there was any single proposal under discussion.  I'm
> certainly not ready to settle on a single proposal.  

The scenario to which DJB responded what under discussion. That
incorporated your reply-to-author via the From field mailbox(es)
suggestion.  That does not preclude other proposal, but that is
what was being discussed in the list messages preceding this one
in this thread.

> And FWIW, I'm in agreement with the view that Reply-To is too messed up
> to be salvaged.

(once again) What are the specific issues that you have in mind?

> Even though the current behavior is very sub-optimal,
> it is still occasionally useful and there are a lot of people who expect
> it to work the way it does now.

Use of From (ignoring Reply-To when present), as you have
suggested is a change to the standard response protocols.
A change which is already supported to some extent in many
UAs (those that provide a mechanism to respond to the From
field mailboxes while ignoring Reply-To). A change which,
however, does not require massive changes to essentially
all UAs, plus changes to many MTAs.  Use of
Reply-TO? Reply-To : From as a default response target is
in fact entirely compatible with "the way it does [work]
now".  The sole changes are (1) added support for narrow
responses to the From field mailboxes for UAs which do not
already have such a mechanism, and (2) wide responses
possibly including From even when Reply-To is present.

Date: Wed, 15 Sep 2004 10:59:00 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Charles Lindsey wrote:

> Well there are at least three places it could put information to help a
> subsequent MUA:
>     Reply-To:
>     Mail-Follouwps-To:
>     Mail-Copies-To:
> and if none of those suffices, then we could always invent another one.

Only one of the infinity of field that you propose is a standard
field recognized by UAs and MTAs.  Any other than that one would
require updating all UAs and many MTAs.

>>* Should replies to list postings *generally* go only to the list or to
>>  the list and the user, as a matter of list culture?
> 
> 
> Speaking *generally*, the list-owner is in the best position to know the
> culture, and that will affect how he fills in whatever header he chooses
> to insert.

No, the list owner has no idea of what the message author intended;
he might not be subscribed to the list, desiring personal responses
to be summarized to the list, he might read the list from a web
archive interface w/o being subscribed to the list, he might be
sending a notification to one list that a topic of potential interest
to that list's subscribers is being discussed on another list (with
discussion supposed to take place on the latter list), etc...

> But relying on the User to fill in Reply-To would be even worse (indeed
> any solution that requires manual action by the user on _every_ response
> to a list is doomed from the start).

Your assumptions are unfounded. Many UAs provide for an easily-changed
"identity" that carries a default Reply-To field, or can use a folder-
specific Reply-To default.  There is no *requirement* for manual action;
moreover with UAs that are likely to be heavily used, the defaults set
up (one time) will be appropriate.

> In particular, use of Reply-To is the
> Wrong Thing if the replier really does want to reply to the author and ot
> to the list.

No, a respondent could (and Keith would say "should") use the From
field, not Reply-To, if he specifically wants to respond directly
to the author(s) only.

> OTOH it does work quite well when inserted by the
> list-expander in particular lists with a culture suited to it.

Only -- as we seem to agree -- if an author-supplied field is
never overwritten.

> Mail-Copies-To is all right so far as it goes, but it only tackles some of
> the problems. I think, on balance, I would prefer Mail-Followups-To.

Neither is standardized or recognized by a substantial fraction
of UAs or MTAs.

From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 15 Sep 2004 09:10:21 -0400
To: [email-masked]
Sender: [email-masked]

>> but Reply-To should probably be deprecated in favor of something that
>> specifies the *complete* recipient list rather than just a replacement
>> for From.
>
> A large part of the problem is that some people think that
>
> (a)  Reply-To specifies the complete list of recipients that the author
>      thinks should receive replies
>
> while other people think that
>
> (b)  Reply-To specifies a list of recipients to be used instead of the
>      From address when directing replies.

I'd argue that the proper function is (a) but the reality is (b).

(I seem to recall that Dave Crocker once argued that the intent was 
(b), but I may recall incorrectly.)

> Meaning (b) of the Reply-To field is so deeply entrenched that I
> think it would be impossible to get the world to use Reply-To with
> meaning (a).  So we seem to need a new field to have meaning (a).
> Mail-Followup-To seems to fit the bill.

One of my concerns with MFT is that it's being promoted and used as a 
way to suppress some kinds of duplicate copies of replies.  There's a 
conflict between using a field like this to suppress duplicate copies 
and using the same field to indicate whether the author thinks replies 
should go to somewhere besides "everyone who received this message":

- The recipient's user interface needs to act differently in these two 
cases - in the first case it's just a normal "reply all" since 
everybody is getting a copy of the message.  In the second case the 
replier needs to be aware that the reply is going to a different set of 
recipients than is normal, and it seems appropriate for the MUA to 
provide some kind of alert to that effect.

- If the replier only wishes to reply to some of the recipients, and 
doesn't know which recipient addresses are contained in other recipient 
addresses (via lists or aliasing or whatever), the use of MFT to 
suppress duplicates fails.  It can be argued that this is a marginal 
case and not worth fixing.  However, enough people react strongly to 
receipt of any duplicate copies of a reply that it might still be an 
important case even if it happens rarely.

-Keith

Date: Wed, 15 Sep 2004 13:26:25 +0200
From: Alan Barrett <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Reply-To: [email-masked]
Sender: [email-masked]

On Mon, 13 Sep 2004, Keith Moore wrote:
> but Reply-To should probably be deprecated in favor of something that
> specifies the *complete* recipient list rather than just a replacement
> for From.

A large part of the problem is that some people think that

(a)  Reply-To specifies the complete list of recipients that the author
     thinks should receive replies

while other people think that

(b)  Reply-To specifies a list of recipients to be used instead of the
     From address when directing replies.

I'd argue that Reply-To (as specified in RFC 822 and 2822) was intended
to have meaning (a), and I'd cite the part about "teleconferences" in
RFC 822 section 4.4.3 in support of my position, but I acknowledge that
reasonable people think it has meaning (b).

Meaning (b) of the Reply-To field is so deeply entrenched that I
think it would be impossible to get the world to use Reply-To with
meaning (a).  So we seem to need a new field to have meaning (a).
Mail-Followup-To seems to fit the bill.

I would not be opposed to redefining Reply-To to have meaning (b).  Many
people use it that way already.

--apb (Alan Barrett)

Date: Wed, 15 Sep 2004 12:43:09 +0200
From: Martin Trautmann <[email-masked]>
Cc: [email-masked]
Subject: Re: optional space after header field colon
Sender: [email-masked]

On 2004-09-14 12:58, Charles Lindsey wrote:
> In <[email-masked]> Martin Trautmann <[email-masked]> writes:
> >is there any real rule whether to put an empty space between a field
> >name's colon and the field body?
> 
> It is a custom invariably followed (like I have never yet seen an email
> message that did not include such a space).

Hi Charles,

I got some recently. That's why I asked, since mutt lost the very first
character of the To. There's a mutt patch that fixes it for From/To/CC, but
it's still a problem in the other header fields.

>  However it is strictly speaking optional according to RFC 2822.
 
> Therefore I shall be pressing, when next RFC 2822 comes up for revision,
> for it to be required in mail also (but of course that is for generation -
> it must still be accepted).

Thanks,
Martin

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 15 Sep 2004 00:31:34 -0400
To: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

>>> Yes, but that is the exceptional case. Normally, what the sender 
>>> asks for
>>> should be what the sender gets. Ultimately, if the replier wants to 
>>> do
>>> something special, then he can do it, but that is not the commn case 
>>> and
>>> therefore it should not be what happens if the replier just presses 
>>> one of
>>> the buttons on offer. If the replier wants to do such special 
>>> things, then
>>> let him cut and paste.
>
>> I think you have it sort of backwards.  The exceptional case is
>> where the sender asks for something different than "reply all".  The
>> recipient's MUA should take pains to make the recipient aware that
>> the sender has requested a different kind of reply, while still giving
>> the recipient the ability to easily choose between what the sender
>> asked for, the normal "reply all" behavior, or something else.
>> And "cut and paste" is just too cumbersome.
>
> No, that just illustrates the problem we are discussing. Approximately 
> 50%
> of users (or slightly less by my counting) are happy for repliers to 
> use
> "reply all". But you must not let the fact that you yourself are in 
> that
> 50% blind you to the fact that the other 50% (or slightly more by my
> counting) are vehemently opposed to any default action that results in
> their receiving duplicate copies.

a) I don't have any reason to have confidence that your 50% figure is 
representative of the preferences of Internet email users.

b) you are conflating at least two things here - one being whether 
people want to get duplicate copies of a message sent to a particular 
address (IMHO it's fairly safe to assume that most do not want 
duplicate copies), another being whether senders prefer that replies 
reach everyone who received a copy of the original message - or at 
least, don't mind having this as a default.

Keith

To: [email-masked]
Xref: clerew local.mime:3607
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Tue, 14 Sep 2004 11:46:37 GMT
Lines: 59
Sender: [email-masked]

In <[email-masked]> Simon Josefsson <[email-masked]> writes:

>"Charles Lindsey" <[email-masked]> writes:

>> Speaking *generally*, the list-owner is in the best position to know the
>> culture, and that will affect how he fills in whatever header he chooses
>> to insert.

>I disagree.  My view is that the originator is in the best position to
>decide his or her own wishes for what should happen with the post.

Sure. If the originator has made his view clear by including MFT, or
whatever else we decide upon at the end of this debate, that that is that.
But if the originator is silent, then it is better for the list-owner to
decide what should be the "default" that best suits the culture of his
list.

>The list owner should, ideally, be able to "help" members understand
>the culture used on a specific list, but shouldn't impose it on list
>members (by, for example, adding 'Reply-To: [email-masked]').  This
>is especially important when messages are cross-posted to several
>list, that may have different cultures.

I agree that "Reply-To" is far too blunt a tool to be added as default by
most list-owners but, at the moment, it is the only tool that we have got.

>> Mail-Copies-To is all right so far as it goes, but it only tackles some of
>> the problems. I think, on balance, I would prefer Mail-Followups-To.

>We are in agreement here.

>What appears to be necessary is a mechanism for less technically
>oriented users to end up with a "correct" MFT setting.  Perhaps auto
>populated by the MUA based on some, new, header added by mailing list
>software.  OTOH, perhaps less technically oriented users doesn't care
>about the problems that motivate use of MFT, so they don't need it
>until they realize those problems.

The "less technically oriented" user, and especially a newbie who has just
joined the list, will do whatever his MUA defaults to. Agreed, an MUA that
understands MFT should keep a database of lists that the user has had
occasion to use, and should ask whether that user is subscribed when a new
list is encountered for the first time. It can then generate an
appropriate MFT header. That AIUI is how MFT is intended to operate.

But there is going to be a long transitional period during which such
smart MUAs are going to be rare, and so we need a system in which sensible
things will happen by default in the meantime.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3609
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: optional space after header field colon
Date: Tue, 14 Sep 2004 12:58:10 GMT
Lines: 34
Sender: [email-masked]

In <[email-masked]> Martin Trautmann <[email-masked]> writes:

>Hi all,

>is there any real rule whether to put an empty space between a field
>name's colon and the field body?

It is a custom invariably followed (like I have never yet seen an email
message that did not include such a space). However it is strictly
speaking optional according to RFC 2822.

OTOH, in Netnews (RFC 1036 and also the Usefor drafts) that space is
REQUIRED (because just too much software breaks if it is omitted).

Therefore I shall be pressing, when next RFC 2822 comes up for revision,
for it to be required in mail also (but of course that is for generation -
it must still be accepted). IOW, header fields with that space should
become the norm and header fields without it should be moved to the
obs-syntax (which would have no effect in practice since all current MUAs
I am aware of already do it that way).

And certainly, if you want your email to be gated into News, then that
space had better be there.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3608
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 14 Sep 2004 12:05:58 GMT
Lines: 38
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> Yes, but that is the exceptional case. Normally, what the sender asks for
>> should be what the sender gets. Ultimately, if the replier wants to do
>> something special, then he can do it, but that is not the commn case and
>> therefore it should not be what happens if the replier just presses one of
>> the buttons on offer. If the replier wants to do such special things, then
>> let him cut and paste.

>I think you have it sort of backwards.  The exceptional case is
>where the sender asks for something different than "reply all".  The
>recipient's MUA should take pains to make the recipient aware that
>the sender has requested a different kind of reply, while still giving
>the recipient the ability to easily choose between what the sender
>asked for, the normal "reply all" behavior, or something else.  
>And "cut and paste" is just too cumbersome.

No, that just illustrates the problem we are discussing. Approximately 50%
of users (or slightly less by my counting) are happy for repliers to use
"reply all". But you must not let the fact that you yourself are in that
50% blind you to the fact that the other 50% (or slightly more by my
counting) are vehemently opposed to any default action that results in
their receiving duplicate copies.

That is the problem we are discussing. It is evidently a real problem that
therefore needs to be fixed. You do not fix it by assuming that what
slightly more than 50% of people want is "exceptional".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Tue, 14 Sep 2004 15:43:37 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> 
> D. J. Bernstein wrote:
> 
> > Specifically: A huge number of today's messages have a suboptimal
> > reply address in From, the desired reply address in Reply-To,
> 
> As suggested by Keith, and as discussed in my earlier message, the
> proposal under discussion is [...]

I wasn't aware that there was any single proposal under discussion.  I'm
certainly not ready to settle on a single proposal.  

And FWIW, I'm in agreement with the view that Reply-To is too messed up
to be salvaged.  Even though the current behavior is very sub-optimal,
it is still occasionally useful and there are a lot of people who expect
it to work the way it does now.

Date: Tue, 14 Sep 2004 12:42:24 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

D. J. Bernstein wrote:

> Specifically: A huge number of today's messages have a suboptimal reply
> address in From, the desired reply address in Reply-To,

As suggested by Keith, and as discussed in my earlier message, the
proposal under discussion is based on individual responses going
to the mailbox(es) specified in the From field, when the respondent
specifically wishes to direct a response to the original messages
author(s).  Default responses would go to the addresses specified
in Reply-To, whether that is because the author prefers that set
of addresses because of some "optimization" issue, because of
delegation, because he feels that default responses should go to
one or more list exploders, etc. -- and if he wishes to indicate
a reason, he can use a standard Comments field, or he can embed
the addresses in a named group with a descriptive phrase, or he
can use a parenthesized comment (although the latter are
deprecated in standard address fields).

> and the desired
> followup addresses in To etc.

No. The To field indicates original recipients, not "followup"
addresses.

>  What happens when these messages are
> interpreted according to your protocol? Answer: not only do replies go
> to a suboptimal address, but also followups are completely misdirected.

Wrong. Default responses go to wherever the original message
sender set Reply-To to point -- and as noted above that could
be an "optimized" mailbox, a list expander, a delegated person
or group of people, etc., depending on what the original message
author has determined to be appropriate for the case at hand (and
Keith has noted that the non-standard, undefined "Mail-Followup-To"
isn't appropriate for all circumstances, or for all authors [in
addition to the fact that it is not supported by most UAs and
MTAs]).

> ``But the desired reply address could go into From, leaving Reply-To
> empty!'' you scream. Yes, it _could_ go into From, but in _reality_ a
> huge number of today's messages have it in Reply-To.

I'm not screaming.  And yes, the premise is that the mailbox(es)
for direct responses to the message authors (as distinct from
default responses) would be placed in the original message's From
field.

> Moving it means
> changing and redeploying a huge number of programs, including homegrown
> mail scripts that haven't been touched for years.

Whereas none of any of the other proposals to date would require
any changes whatsoever, right? :-)

> Only _after_ that's
> done would it be safe to start using the name Reply-To for something
> else---in particular, for MUAs to switch from To+Cc+(Reply-To||From) to
> Reply-To||(To+Cc+From) for followups.

No, default responses would go to Reply-To? Reply-To : From, which
is supported by essentially all UAs.  Wide responses that cover
original message recipients, which as several participants in this
discussion have noted would involve editing by the respondent,
could be initialized via a "reply-all" function as now, and
(Reply-To? Reply-to : From) + To + Cc -- as now used by most MUAs --
is not unreasonable; Reply-To + From + To + Cc might be a tad
better.  Responses directly to the original message authors (From
field) are already supported by several MUAs and is a feature of
several proposals discussed here.

> I'm not saying that your protocol is inherently broken. I'm just saying
> that it's disastrously incompatible with current practice.

I believe you're wrong about that. You certainly haven't presented
any convincing argument to support that assertion.

> For comparison: Mail-Followup-To avoids all the costs of that first
> transition step.

Nonsense. First it has to be properly defined. Then the existing
standards that specify use of Reply-To? Reply-To : From would
have to be replaced. MUAs would have to have support added, not
only to use the field for some sorts of responses, but also simply
to display the field (otherwise, an unsuspecting user will be
confounded when a response goes to a place which isn't visibly
specified anywhere). MTAs that modify address fields would have
to be modified.

> It's safe for MUAs to switch to Mail-Followup-To||...
> for followups; many MUAs have done this already,

Many more (i.e. most) have not done so.

> saving time for their
> users.

Spare us the marketing BS.

> The use of a _new name_ makes the Mail-Followup-To protocol much
> less expensive to deploy than the protocol you're advocating.

No, as noted above it requires many changes -- to existing protocol
standards, to all MUAs, to MTAs, etc.

> P.S. I pointed all this out, although not in as much detail, in my first
> ``Understanding response protocols'' message. This discussion would make
> more progress if you started paying attention.

That was of the form "I want...", and didn't address the issues
brought up in recent discussion.

Date: 14 Sep 2004 01:38:34 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: optional space after header field colon
Sender: [email-masked]

Russ Allbery writes:
> I think Martin meant the space after the colon, rather than the one before
> it.

Oops, sorry; I misread.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

To: [email-masked]
Subject: Re: optional space after header field colon
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 13 Sep 2004 18:07:55 -0700
Sender: [email-masked]

D J Bernstein <[email-masked]> writes:
> Martin Trautmann writes:

>> is there any real rule whether to put an empty space between a field
>> name's colon and the field body?

> Including spaces is a really bad idea: Cyrus imapd and AMS and metamail
> and mpack have been reported to choke on spaces. 822 allowed spaces but
> 2822 doesn't. http://cr.yp.to/immhf/field.html covers all this.

I think Martin meant the space after the colon, rather than the one before
it.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: 14 Sep 2004 00:46:42 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: optional space after header field colon
Sender: [email-masked]

Martin Trautmann writes:
> is there any real rule whether to put an empty space between a field
> name's colon and the field body?

Including spaces is a really bad idea: Cyrus imapd and AMS and metamail
and mpack have been reported to choke on spaces. 822 allowed spaces but
2822 doesn't. http://cr.yp.to/immhf/field.html covers all this.

> It's common behavior to include one here,

Common where? I've heard rumors, so I recommend that readers accept
spaces, but I've never seen confirmation of the rumors.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Mon, 13 Sep 2004 20:03:40 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Martin Trautmann <[email-masked]>
CC: [email-masked]
Subject: Re: optional space after header field colon
Sender: [email-masked]

Martin Trautmann wrote:
> 
> Hi all,
> 
> is there any real rule whether to put an empty space between a field
> name's colon and the field body?
> 
> It's common behavior to include one here,
> but it's unclear - or even purpose (A.5.) - that none is required.

In structured fields, whitespace is significant only as a separator
between other lexical tokens (in early standards, whitespace was also
allowed within logical tokens, but that lead to unresolvable
ambiguities).

> According to obsolete A.6.3 WSP is (or was, according to B.21.) even
> allowed between header field and colon.

RFC 2822 requires parsing fields with whitespace between the field
name and colon, but does not permit it during generation. Early
standards even permitted multi-word (whitespace-separated) field
names.

> There may be special rules for special header fields, but to my knowledge
> there's none for all.
> 
> Is the leading space of a field body part of the field body or not?

As noted above, whitespace simply delimits tokens in structured
fields.  So while any whitespace immediately following the colon which
follows the field name is part of the field body of a structured field,
such whitespace carries no protocol information.

In unstructured fields, whitespace is simply part of the field body.

Date: Mon, 13 Sep 2004 12:13:24 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> 
> In <[email-masked]> Keith Moore <[email-masked]> writes:
> 
> >There really is a conflict sometimes between what the sender thinks
> >should happen in the event of a reply and what the recipient wants to
> >happen with the reply he composes.  In that circumstance, the recipient
> >needs to win. 
> 
> Yes, but that is the exceptional case. Normally, what the sender asks for
> should be what the sender gets. Ultimately, if the replier wants to do
> something special, then he can do it, but that is not the commn case and
> therefore it should not be what happens if the replier just presses one of
> the buttons on offer. If the replier wants to do such special things, then
> let him cut and paste.

I think you have it sort of backwards.  The exceptional case is
where the sender asks for something different than "reply all".  The
recipient's MUA should take pains to make the recipient aware that
the sender has requested a different kind of reply, while still giving
the recipient the ability to easily choose between what the sender
asked for, the normal "reply all" behavior, or something else.  
And "cut and paste" is just too cumbersome.

> >I think we are in agreement that user agents should uniformly
> >implement two reply functions (along with being able to edit the
> >reply address list);
> 
> >- reply to author 
> >- wide reply (more or less "reply to everyone")
> 
> No we are not in such agreement. Firstly, if by "reply to author" you mean
> "reply to From", then that is certainly not correct 

it certainly _is_ correct, presuming the author used From correctly.

> (a replier that wants
> to override the Reply-To should be made to jump through some extra hoop,
> just to be usre he knows what he is doing).

no, a replier should be made aware that Reply-To was set so that he can
make the choice of whom to reply to in light of the knowledge that the
sender has requested that he do something unusual.  but Reply-To 
should probably be deprecated in favor of something that specifies
the *complete* recipient list rather than just a replacement for From.

> And secondly, there are still some who would like an explicit "reply to
> list" - "reply to all" is just too wide and should be reserved for the
> cases where "all" is really, really what you want.

I don't really have a problem with that, I just think it's of marginal
utility.

Keith

Date: Mon, 13 Sep 2004 12:07:19 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> > * Is the user a member of the mailing list to which they sent the mail?
> >   ............
> 
> >   The mailing list manager can answer this question itself in some
> >   circumstances (skipping the problem of people subscribed under
> >   different addresses than they send mail, which is uncommon in the
> >   situations where I see this the most, but which is a tricky problem
> >   when it happens).  However, it doesn't really have anywhere to *put*
> >   that information for the use of MUAs.
> 
> Well there are at least three places it could put information to help a
> subsequent MUA:
>     Reply-To:
>     Mail-Follouwps-To:
>     Mail-Copies-To:

no, no, and no.  lists have no business setting headers that are intended
for the message author.

Date: Mon, 13 Sep 2004 17:48:13 +0200
From: Martin Trautmann <[email-masked]>
To: [email-masked]
Subject: optional space after header field colon
Sender: [email-masked]

Hi all,

is there any real rule whether to put an empty space between a field
name's colon and the field body?

It's common behavior to include one here,
but it's unclear - or even purpose (A.5.) - that none is required.
According to obsolete A.6.3 WSP is (or was, according to B.21.) even
allowed between header field and colon.

There may be special rules for special header fields, but to my knowledge
there's none for all.

Is the leading space of a field body part of the field body or not?
There's only a rule for folding WSP in multiple line field bodys.
Thus any current leading space should be part of the field body.

Is there any need to improve this description?

Kind regards
Martin

Date: 13 Sep 2004 15:03:21 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Charles Lindsey writes:
> OTOH, it would make good sense for the list-owner to fill it in it not
> provided by the user (because the list-owner shouls know whether that
> user is on the list).

Your assumption is wrong, your logic is wrong, and your conclusion is
wrong.

The list distributor does _not_ know whether the sender is on the list:
consider sublists, HTTP subscriptions, etc. Even if the distributor
_does_ know that the sender is on the list, the distributor shouldn't
add Mail-Followup-To; there are several issues here, the most obvious
being that some senders _do_ want copies of followups.

Didn't you learn anything from the Reply-To mess? If you want to add
information to a message in transit, stick to the envelope: Return-Path,
Received, List-*, etc. Don't touch the sender's header fields.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Mon, 13 Sep 2004 16:13:01 +0200
Lines: 54
Cancel-Lock: sha1:WzlCCwU7XRlX+5c0+Xh4JvT896I=
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> writes:

>> * Should replies to list postings *generally* go only to the list or to
>>   the list and the user, as a matter of list culture?
>
> Speaking *generally*, the list-owner is in the best position to know the
> culture, and that will affect how he fills in whatever header he chooses
> to insert.

I disagree.  My view is that the originator is in the best position to
decide his or her own wishes for what should happen with the post.
The list owner should, ideally, be able to "help" members understand
the culture used on a specific list, but shouldn't impose it on list
members (by, for example, adding 'Reply-To: [email-masked]').  This
is especially important when messages are cross-posted to several
list, that may have different cultures.

>> * Does the individual user want copies of list postings?  This is what
>>   MFT expresses clearly when used fully, and it deals with such issues as
>>   "crossposts" between multiple mailing lists.  This should probably
>>   override the list default in nearly all cases, if expressed.
>
> Yes, MFT can do the best job when used correctly, but it only works best
> when used in conjunction with a MUA that is pre-configured with a list of
> known mailing lists and instructions as to how that user wants each one
> treated (and it is the _only_ method with any chance of processing
> cross-posts to several lists correctly and automatically).
>
> But I guess attempts by a user to fill MFT in manually would be too much
> for 'unsophisticated' users. OTOH, it would make good sense for the
> list-owner to fill it in it not provided by the user (because the
> list-owner shouls know whether that user is on the list).
>
> But relying on the User to fill in Reply-To would be even worse (indeed
> any solution that requires manual action by the user on _every_ response
> to a list is doomed from the start). In particular, use of Reply-To is the
> Wrong Thing if the replier really does want to reply to the author and ot
> to the list. OTOH it does work quite well when inserted by the
> list-expander in particular lists with a culture suited to it.
>
> Mail-Copies-To is all right so far as it goes, but it only tackles some of
> the problems. I think, on balance, I would prefer Mail-Followups-To.

We are in agreement here.

What appears to be necessary is a mechanism for less technically
oriented users to end up with a "correct" MFT setting.  Perhaps auto
populated by the MUA based on some, new, header added by mailing list
software.  OTOH, perhaps less technically oriented users doesn't care
about the problems that motivate use of MFT, so they don't need it
until they realize those problems.

Thanks,
Simon

To: [email-masked]
Xref: clerew local.mime:3596
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 13 Sep 2004 11:53:43 GMT
Lines: 41
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>There really is a conflict sometimes between what the sender thinks
>should happen in the event of a reply and what the recipient wants to
>happen with the reply he composes.  In that circumstance, the recipient
>needs to win. 

Yes, but that is the exceptional case. Normally, what the sender asks for
should be what the sender gets. Ultimately, if the replier wants to do
something special, then he can do it, but that is not the commn case and
therefore it should not be what happens if the replier just presses one of
the buttons on offer. If the replier wants to do such special things, then
let him cut and paste.

>I think we are in agreement that user agents should uniformly
>implement two reply functions (along with being able to edit the
>reply address list);

>- reply to author 
>- wide reply (more or less "reply to everyone")

No we are not in such agreement. Firstly, if by "reply to author" you mean
"reply to From", then that is certainly not correct (a replier that wants
to override the Reply-To should be made to jump through some extra hoop,
just to be usre he knows what he is doing).

And secondly, there are still some who would like an explicit "reply to
list" - "reply to all" is just too wide and should be reserved for the
cases where "all" is really, really what you want.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3597
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ***SPAM-3*** Re: Understanding response protocols
Date: Mon, 13 Sep 2004 11:54:56 GMT
Lines: 23
Sender: [email-masked]

In <[email-masked]> Nathaniel Borenstein <[email-masked]> writes:

>This is something that we worked very hard on in Andrew during the 
>1980's.  Although the protocols have only become more complex since 
>then, at that time we found that it was possible to devise an algorithm 
>that did an extremely satisfactory job at what we then called "Wide 
>Replies" using only a single non-standard extension to the email 
>protocols.  The non-standard header we used was

>	X-Andrew-Wide-Reply:  <addrlist>

That looks rather like Mail-Followups-To to me.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3594
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Mon, 13 Sep 2004 11:30:16 GMT
Lines: 68
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>There are more pieces missing than just a header like MFT, I think.  At
>the least, I think we need some way of representing the following:

> * Is the user a member of the mailing list to which they sent the mail?
>   ............

>   The mailing list manager can answer this question itself in some
>   circumstances (skipping the problem of people subscribed under
>   different addresses than they send mail, which is uncommon in the
>   situations where I see this the most, but which is a tricky problem
>   when it happens).  However, it doesn't really have anywhere to *put*
>   that information for the use of MUAs.

Well there are at least three places it could put information to help a
subsequent MUA:
    Reply-To:
    Mail-Follouwps-To:
    Mail-Copies-To:
and if none of those suffices, then we could always invent another one.

But, in all cases, the List Expander should only insert such a header if
the original User had not already done so.

> * Should replies to list postings *generally* go only to the list or to
>   the list and the user, as a matter of list culture?

Speaking *generally*, the list-owner is in the best position to know the
culture, and that will affect how he fills in whatever header he chooses
to insert.

> * Does the individual user want copies of list postings?  This is what
>   MFT expresses clearly when used fully, and it deals with such issues as
>   "crossposts" between multiple mailing lists.  This should probably
>   override the list default in nearly all cases, if expressed.

Yes, MFT can do the best job when used correctly, but it only works best
when used in conjunction with a MUA that is pre-configured with a list of
known mailing lists and instructions as to how that user wants each one
treated (and it is the _only_ method with any chance of processing
cross-posts to several lists correctly and automatically).

But I guess attempts by a user to fill MFT in manually would be too much
for 'unsophisticated' users. OTOH, it would make good sense for the
list-owner to fill it in it not provided by the user (because the
list-owner shouls know whether that user is on the list).

But relying on the User to fill in Reply-To would be even worse (indeed
any solution that requires manual action by the user on _every_ response
to a list is doomed from the start). In particular, use of Reply-To is the
Wrong Thing if the replier really does want to reply to the author and ot
to the list. OTOH it does work quite well when inserted by the
list-expander in particular lists with a culture suited to it.

Mail-Copies-To is all right so far as it goes, but it only tackles some of
the problems. I think, on balance, I would prefer Mail-Followups-To.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3595
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 13 Sep 2004 11:45:23 GMT
Lines: 38
Sender: [email-masked]

In <[email-masked]> "Eric A. Hall" <[email-masked]> writes:

>Right. In theory you can do this with a single list by looking for a
>List-* header and matching it with an address in the TO header, but if
>there are any other addresses in the TO/CC blocks (especially any other
>list addresses for which there are no list-* header) it fails completely.
>So what you really need is a way to overload the TO/CC blocks with
>additional information, or really what would be better would be to define
>new recipient header such as List or Group or whatnot, and which you could
>match with more decisively, and which would survive multiple mailing lists
>that pass through multiple servers. See the original message again; most
>of this stuff is easier to think about in terms of "later".

These problems would certainly be simpler if it were possible to tell by
inspection whether a message had been sent to a mailing list, and if to to
how many of them. Overloading TO/CC blocks would certainly do it, but the
only way to do that compatibly with existing practive would be to use the
Group syntax:

   To: LISTS: [email-masked], [email-masked];,
       PERSONS: [email-masked];

But what chance of getting that convention universally adopted? Perhaps if
lists were to publish their submission addresses as
"LIST: [email-masked];" it might work, but then you would get someone
trying to include the whole of that between angle-brackets, which does not
work.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Sun, 12 Sep 2004 20:59:02 -0400
To: [email-masked]
Sender: [email-masked]

>> But if we really want to have recipients' MUAs suppress duplicates 
>> when
>> composing replies, we should do it differently than with the
>> Wide-Reply-To or Mail-Followup-To field.  For instance, we could have 
>> a
>> field of the form
>>
>> Suppress-Duplicate: address1, [address2, address3, ... ]
>>
>> which says that if a reply is being sent to _any_ of address1, 
>> address1,
>> etc., don't send a separate copy to the From address.
>
> That has the same lack of traction that affects Wide-Reply-To and
> Mail-Followup-To -- every UA has to be modified for it to work.
> Though MTAs shouldn't munge address fields, it also requires MTAs
> that do so to be aware of the field and its syntax and semantics
> and to modify it in a manner consistent with any modifications to
> other address fields (and envelope addresses).

You are of course correct.  I think this is better than 
Mail-Followup-To for suppressing duplicates, but I didn't say it was 
without problems.

The nice thing about suppressing duplicates at recipients' MUAs or 
message stores (rather than at the MUAs where replies are generated) is 
that the benefit is immediately by those whose MUAs or message stores 
are upgraded to support this.  But as we've seen, that approach also 
has problems.

Keith

To: [email-masked]
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
Subject: Re: Understanding response protocols
Date: 12 Sep 2004 14:13:00 +0200
Lines: 27
Sender: [email-masked]

Bruce Lilly <[email-masked]> schrieb/wrote:
> D. J. Bernstein wrote:
>> Let me emphasize that the goal---followups to [email-masked] and
>> replies to [email-masked] _not_ achieved by the old protocol ``reply
>> to Reply-To||From; follow up to To+Cc+(Reply-To||From).''

> But Reply-To: [email-masked] / From: [email-masked] does work for
> responses to the list (using Reply-To) or to an individual (using
> From). Without changing semantics of any fields. Without adding new
> fields.  Without expecting UAs to pay attention to an undefined field.
>  And which works with existing UAs.

No, it does not work with existing UAs. Most UAs will direct their
"narrow" reply to the Reply-To field and their "broad" reply to either
the address in the Reply-To field or to all addresses.

Further, it does not allow something like this:

| From: [email-masked]
| To: [email-masked], [email-masked]
| Reply-To: [email-masked]
| Mail-Followup-To: [email-masked]

Claus
-- 
http://www.faerber.muc.de

Date: 12 Sep 2004 03:33:26 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Bruce Lilly writes:
> Reply-To: [email-masked] / From: [email-masked] does work

We could certainly use the name Reply-To instead of Mail-Followup-To in
a completely new mail system.

The problem is that we're not designing a completely new mail system.
Your proposed protocol, sending followups to Reply-To and replies to
From, has horrible effects when it interacts with today's software.

Specifically: A huge number of today's messages have a suboptimal reply
address in From, the desired reply address in Reply-To, and the desired
followup addresses in To etc. What happens when these messages are
interpreted according to your protocol? Answer: not only do replies go
to a suboptimal address, but also followups are completely misdirected.

``But the desired reply address could go into From, leaving Reply-To
empty!'' you scream. Yes, it _could_ go into From, but in _reality_ a
huge number of today's messages have it in Reply-To. Moving it means
changing and redeploying a huge number of programs, including homegrown
mail scripts that haven't been touched for years. Only _after_ that's
done would it be safe to start using the name Reply-To for something
else---in particular, for MUAs to switch from To+Cc+(Reply-To||From) to
Reply-To||(To+Cc+From) for followups.

I'm not saying that your protocol is inherently broken. I'm just saying
that it's disastrously incompatible with current practice.

For comparison: Mail-Followup-To avoids all the costs of that first
transition step. It's safe for MUAs to switch to Mail-Followup-To||...
for followups; many MUAs have done this already, saving time for their
users. The use of a _new name_ makes the Mail-Followup-To protocol much
less expensive to deploy than the protocol you're advocating.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

P.S. I pointed all this out, although not in as much detail, in my first
``Understanding response protocols'' message. This discussion would make
more progress if you started paying attention.

Date: Sat, 11 Sep 2004 18:51:17 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Nathaniel Borenstein <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Nathaniel Borenstein wrote:
> 
> In trying to project the seemingly unlimited set of possible reply
> semantics onto the visibly limited set of concepts that are
> comprehensible to the typical user, I keep coming back to the notion
> that there are really only 3 cases that are, at a first approximation,
> comprehensible to most mortals:
> 
> -- Reply to the user who sent the message.
> 
> -- Reply to the "discussion community" of the message (see below)
> 
> -- Reply highly idiosyncratically (i.e. let the user self-edit the headers)
> 
> That is, I'm hypothesizing (fairly confidently) that the vast majority
> of users won't be willing or able to differentiate beyond these three
> cases (and most won't even use the third).
[...]
> How would people feel about a strategy of clarifying a "default"
> algorithm for followup mail, and standardizing a "Wide-Reply-To"
> override?  -- Nathaniel

You started with 3 alternatives: "default", "wide", and "narrow"
might be appropriate terms, where the default or "recommended"
response could be set by the original message author(s), narrow
would be a response to the author(s), and wide would be a response
including the default plus additional original message recipients
(and would probably be edited by respondents).  Those three happen
to be exactly what the MUA "pine" supports, and there are other
MUAs that support those three plus others.  In terms of existing
fields, "narrow" responses would go to mailboxes specified in the
original message From field (MUAs might provide additional types
of narrow responses for advanced users, such as using Sender or
Return-Path), the recommended addresses could be specified by the
author via Reply-To, and wide responses would go to Reply-To+To+Cc.

That imposes no new requirements on MTAs, and MUA support for
narrow replies (for MUAs that do not already provide such
capability) is the only addition.  While such support is being
added to MUAs, the existing semantics of "plain" responses
correspond to the default/recommended type. "Reply-all" will
continue to correspond to wide responses.

Date: Sat, 11 Sep 2004 18:03:23 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore wrote:

> I can think of other ways to handle this at the MUA than trusting
> to/cc/bcc fields - for instance: when you send a message to an address
> your MUA knows is a list, have your MUA associate a priority with the
> outgoing message-id.  Then when a message comes back that is a reply to
> that message id, file it with the list mail.  Though this wouldn't treat
> private replies differently from "wide" replies.

Which MUA? How is my home MUA used for reading responses supposed
to determine the "priority" of a message sent by my MUA at work?
Or, for that matter, even if I use multiple MUAs at the same
location?

> None of this is perfect at suppressing duplicates, of course.  For that
> matter, neither is mail-followup-to.
> 
> I do think we're going to see a lot more sophistication in future MUAs.
>  It's fairly clear that we haven't scratched the surface yet.

I think you were on the right track earlier in suggesting that
suppression of duplicates should be done in the message store.
In fact Cyrus IMAP can be configured to do so.

Date: Sat, 11 Sep 2004 17:57:42 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore wrote:

> If the only thing anyone wants to do with it is
> suppress duplicates that are  caused by mailing lists, it more-or-less
> works.  But that's not the only reason people want to redirect replies. 
> And when the header gets overloaded for multiple purposes, the recipient
> has no way to sort this out.  Why does this header contain what it does?
>  Is it  because the sender wants to eliminate duplicates, or because 
> the sender thinks that discussion should naturally take place on a
> particular list (and the recipient might disagree).

Regardless of the original message author's motivations, if he
indicates that default responses are recommended to go to some
set of mailboxes (which the recipient can of course override),
a responding recipient can choose to comply with that recommendation
or override it (for whatever reasons).

> Also, it seems like overloading is at the heart of the problems
> with Reply-To, so I'd like us to not go down that path again.

Which problems, specifically?

> I think we are in agreement that user agents should uniformly
> implement two reply functions (along with being able to edit the
> reply address list);
> 
> - reply to author 
> - wide reply (more or less "reply to everyone")
> 
> The first should go to From,

OK...

> though for the sake of a clean transition
> it might be acceptable for recipient MUAs to honor Reply-To.  But use
> of Reply-to in new messages should be discouraged.
> 
> The second should default to From+To+Cc.

But Keith, that won't work for the specific case of eliminating
duplicates...

> But if we really want to have recipients' MUAs suppress duplicates when
> composing replies, we should do it differently than with the
> Wide-Reply-To or Mail-Followup-To field.  For instance, we could have a
> field of the form
> 
> Suppress-Duplicate: address1, [address2, address3, ... ]
> 
> which says that if a reply is being sent to _any_ of address1, address1,
> etc., don't send a separate copy to the From address.

That has the same lack of traction that affects Wide-Reply-To and
Mail-Followup-To -- every UA has to be modified for it to work.
Though MTAs shouldn't munge address fields, it also requires MTAs
that do so to be aware of the field and its syntax and semantics
and to modify it in a manner consistent with any modifications to
other address fields (and envelope addresses).

Date: Sat, 11 Sep 2004 17:41:38 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "D. J. Bernstein" <[email-masked]>
Subject: Re: Understanding response protocols
Sender: [email-masked]

D. J. Bernstein wrote:

> Let me emphasize that the goal---followups to [email-masked] and
> replies to [email-masked] _not_ achieved by the old protocol ``reply
> to Reply-To||From; follow up to To+Cc+(Reply-To||From).''

But Reply-To: [email-masked] / From: [email-masked] does work for
responses to the list (using Reply-To) or to an individual (using
From). Without changing semantics of any fields. Without adding
new fields.  Without expecting UAs to pay attention to an undefined
field.  And which works with existing UAs.

> No matter what
> I put into my message, the old protocol produces a followup address list
> that includes the reply address list, so it fails to achieve the goal.

No, see above.

Date: Fri, 10 Sep 2004 16:26:16 -0400
From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> Keith Moore writes:
> > There really is a conflict sometimes between what the sender thinks
> > should happen in the event of a reply and what the recipient wants
> > to happen with the reply he composes.  In that circumstance, the
> > recipient needs to win. 
> 
> Time for a reality check.
> 
> If the sender wants some addresses to not receive followups, he can
> send blind carbon copies to those addresses. The public recipient is
> given no hint of those addresses.
>
> How is the recipient supposed to ``win''? Is his MUA supposed to spy
> on the sender's computer and see where the message was actually sent?

I'm not sure what question you're asking.  If the sender doesn't want
recipients to see those addresses, the mail system is doing what the
sender wants and honoring his intention.  This is as it should be.
If the sender does want recipients to see those addresses, and yet
suggest that they not be copied on followups, the mail system doesn't
support the ability to do that at present.

The point is I was trying to make is that whoever is sending a message
has the right to choose (i.e. "win" the argument) which recipients get
that message.  This is also true of someone sending a reply.  I used 
the word "recipient" in the text you quoted above to distinguish him 
from the "sender" who sent the subject message, but the "recipient" of 
the subject message is also the "sender" of the reply.  It just seemed 
awkward to use the word "sender" in two different contexts.

> Blaming Mail-Followup-To for this is silly. 

Nobody's blaming Mail-Followup-To for anything.   It's not widely 
enough deployed at present to do any significant harm.

What I've been doing is pointing out (a) the problems with using the 
Mail-Followup-To for multiple purposes and (b) the limitations 
associated with using Mail-Followup-To for duplicate suppression.

Keith

Date: 10 Sep 2004 18:14:17 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Keith Moore writes:
> There really is a conflict sometimes between what the sender thinks
> should happen in the event of a reply and what the recipient wants to
> happen with the reply he composes.  In that circumstance, the recipient
> needs to win. 

Time for a reality check.

If the sender wants some addresses to not receive followups, he can send
blind carbon copies to those addresses. The public recipient is given no
hint of those addresses.

How is the recipient supposed to ``win''? Is his MUA supposed to spy on
the sender's computer and see where the message was actually sent?

Similarly, in the unusual case that the sender wants followups going to
more places than his own message, he can put those addresses into To or
Cc without actually sending the message there. Once again: How is the
recipient supposed to ``win''?

Blaming Mail-Followup-To for this is silly. There's no Mail-Followup-To
in these examples. There's no way for the Internet mail system to stop
the sender from putting some addresses into the header and other
addresses into envelopes.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 10 Sep 2004 01:21:28 -0400
To: Russ Allbery <[email-masked]>
Sender: [email-masked]

On Sep 10, 2004, at 1:08 AM, Russ Allbery wrote:

> Keith Moore <[email-masked]> writes:
>
>> well, I'm not sure if I found the message that explains _why_ you 
>> don't
>> want to see them, but I did find a message that explains that you want
>> replies to list mail to end up in a list folder and not in your inbox.
>
> I can expand a little bit; I'm not sure how much I said before.
>
> I think of mail folders a little bit like newsgroups, in the sense 
> that my
> mail folders are not only a convenient way of sorting topics together, 
> but
> also acquire different priorities, invoke different quantities of 
> guilt if
> messages sit unresponded-to, and are read at different times and to
> different degrees.
[...]

Okay, that makes sense.  I actually do much the same thing; it just 
happens that I want replies to mail I send (whether from a list or not) 
to be looked at at "inbox" priority.  All of the list traffic that 
isn't addressed to me is handled at a lower priority.

And that explains why having messages move from your inbox to the list 
doesn't help much if you happen to have read your mail in the meantime 
- since you're trying to avoid having replies to list traffic trigger 
interrupts at a higher priority than you intend.

I can think of other ways to handle this at the MUA than trusting 
to/cc/bcc fields - for instance: when you send a message to an address 
your MUA knows is a list, have your MUA associate a priority with the 
outgoing message-id.  Then when a message comes back that is a reply to 
that message id, file it with the list mail.  Though this wouldn't 
treat private replies differently from "wide" replies.

None of this is perfect at suppressing duplicates, of course.  For that 
matter, neither is mail-followup-to.

I do think we're going to see a lot more sophistication in future MUAs. 
  It's fairly clear that we haven't scratched the surface yet.

Keith

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 09 Sep 2004 22:08:35 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> well, I'm not sure if I found the message that explains _why_ you don't
> want to see them, but I did find a message that explains that you want
> replies to list mail to end up in a list folder and not in your inbox.

I can expand a little bit; I'm not sure how much I said before.

I think of mail folders a little bit like newsgroups, in the sense that my
mail folders are not only a convenient way of sorting topics together, but
also acquire different priorities, invoke different quantities of guilt if
messages sit unresponded-to, and are read at different times and to
different degrees.

A conversation like this, for example, I want to live entirely in the
mailing list folder because talking about how to implement things with
mail is not part of my job or one of my primary hobbies.  I'm currently
interested in this discussion, so I'm reading this folder regularly, but
at some other time when I don't feel like thinking about mail, I may leave
this folder to sit fallow or even delete its contents unread since I'm
busy with other things.  There are a different set of folders for work
that I read every day during the weekdays, but may not read at all on the
weekends or while I'm on vacation.  And personal e-mail I read at a very
high priority and feel guilty when I've received mail that I've not yet
responded to.

When someone copies me on a reply to routine list mail, such as this
discussion, they are in essence forcing a higher priority on their message
than it deserves.  Now, this isn't their fault per se; I don't expect them
to be psychic and understand how I use mail and how I prioritize it.  But
I would like to keep that from being the common reply method in mail
clients so that I don't have to keep manually correcting the
misprioritization (by reading the message, observing it was cc'd to the
mailing list and therefore not the beginning of private correspondance,
and deleting the stray, misfiled copy).

If I'm having one of these conversations, and I decide I'm tired of the
topic, don't have the time to talk about it any more, and want to stop,
the traffic should cease completely when I unsubscribe from the list.
When I'm being cc'd, I can continue to get e-mail for quite some time (and
even about different topics than the original one) when I no longer care
at all.

Plus, I notice that even though I am consciously aware of things like
this, and can manually correct, this method of handling e-mail makes so
much intuitive sense to me that I find myself reacting to it without even
meaning to.  For example, I'm replying to this message immediately in part
because you sent me a private copy and I checked mail before going home; I
wasn't intending to, and wouldn't have, replied to any other routine list
e-mail, and didn't realize I was doing that until I was already partway
through the message.  This isn't a huge deal (if it were, I would have
exercised more self-control), but it can be annoying (not that it's at all
your fault, other than that you use a reply method that I think is
substantially less than ideal).

Now, one solution to this is, of course, to abandon all of the advances
that have been made in mail sorting and sort mail by To and Cc header
contents instead of by the older (Sender, Return-Path) or newer and
standardized (List-Id) headers designed for that purpose.  Then I'd just
end up with two copies of the same message in one folder, still annoying
but something that my MUA can actually deal with automatically.  However,
I would contend that this is *also* broken for all of the same reasons
that List-Id was invented in the first place.  It breaks for mailing lists
that have multiple submission addresses (particularly ones with multiple
and constantly changing submission addresses, like mailing lists that are
actually the recipients of mail to per-ticket addresses for a trouble
ticketing system, for instance), it breaks when the message is Bcc'd to
the mailing list, and the To and Cc addresses often change faster than the
List-Id header.

Overall, I don't like the current situation at all.  I either end up with
fairly routine misprioritized e-mail that feels like it's "intruding" into
a space where it doesn't belong, or I have to take a couple of giant steps
backwards into the dark days of mail filtering and write rules to match
To/Cc headers for all mailing lists (in addition to the List-Id rules,
since I still want to catch those Bccs and changing list submission
addresses) and still have occasional misses.  I don't think it's possible
to solve this entirely at the receiving MUA without any changes on the
part of the senders.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 10 Sep 2004 00:53:22 -0400
To: Russ Allbery <[email-masked]>
Sender: [email-masked]

>> I guess it depends what the purpose is in suppressing duplicates.  I
>> suspect people don't want to see multiple copies of the same message 
>> in
>> the same folder.
>
> Well, you don't have to suspect.  I've already explained in this
> discussion why I don't want to see multiple copies of the same message,
> and that isn't it.  :)

well, I'm not sure if I found the message that explains _why_ you don't 
want to see them, but I did find a message that explains that you want 
replies to list mail to end up in a list folder and not in your inbox.

I agree that it would be somewhat tricky to have recipient-side 
duplicate suppression work in the way you'd like - either a message 
would mysteriously disappear from your inbox and move to a list folder, 
or you'd have to delay incoming mail that looked like it might have 
been copied to a list.   probably the former.

though I could certainly imagine a user agent being able to "hide" 
messages in one folder if they appeared in another, I don't know how 
much interest there would be for such a feature.

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 09 Sep 2004 21:29:59 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> I guess it depends what the purpose is in suppressing duplicates.  I
> suspect people don't want to see multiple copies of the same message in
> the same folder.

Well, you don't have to suspect.  I've already explained in this
discussion why I don't want to see multiple copies of the same message,
and that isn't it.  :)

Not to mention that they're not in the same folder, since putting them in
the same folder would involve using fragile and non-standardized
mechanisms for mail sorting that break with such things as Bccs to mailing
lists or resent messages, and I use the standardized mechanism of List-Id.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 10 Sep 2004 00:20:27 -0400
To: Russ Allbery <[email-masked]>
Sender: [email-masked]

> Suppressing duplicates in the MUA is extremely difficult to do 
> properly,
> to the degree that I would contend it's impossible to do with the 
> current
> e-mail protocol in a way that would make sense to the casual user.  
> It's
> necessary to suppress the personal copy, since the list copy is the one
> that will sort correctly using the List-Id header and may have 
> additional
> information or modifications made in the course of processing by the
> mailing list management software.  However, the personal copy almost
> always arrives first, so doing this right requires temporary quarantine
> and possible later release of mail, something that adds a tremendous
> amount of complexity to mail handling.

I guess it depends what the purpose is in suppressing duplicates.   I 
suspect people don't want to see multiple copies of the same message in 
the same folder.  So when the personal copy arrives, no need to 
quarantine it - just store it and index it by the message-id.  When the 
list copy arrives, realize that there's another message with the same 
message-id, and link both of them to the same line in the message 
summary.  When the user clicks on that message, the MUA can say "there 
are two slightly different copies of this message", do you want to see 
the other one?  (much like Google does when it identifies 
nearly-identical documents at multiple sites).

If the message store is worried about conserving disk space, it can 
just store the first message it receives along with the diffs between 
that and the subsequent copies.  (this works better if the message 
store does it than if the MUA does it)

And yes, this only works if the message-id is properly maintained.  
Most of the time, it is.  But if the diffs are too great, or the list 
alters the message-id, the message store can treat them as separate 
messages.  As long as this only happens occasionally I don't think it's 
a horrible thing.

Keith

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 09 Sep 2004 20:19:46 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> Ideally duplicate suppression would be implemented in the recipient's
> MUA (NOT the MUA composing replies) or in the recipient's message store.
> One reason I believe this is that there are several other sources of
> duplicate messages than mailing lists.  Another reason I believe this is
> that I think MUAs should be able to chase down threads that cross folder
> boundaries (for instance between INBOX, Sent, and a list folder) - and
> if they do that, they're within epsilon of being able to suppress
> duplicates anyway.

Suppressing duplicates in the MUA is extremely difficult to do properly,
to the degree that I would contend it's impossible to do with the current
e-mail protocol in a way that would make sense to the casual user.  It's
necessary to suppress the personal copy, since the list copy is the one
that will sort correctly using the List-Id header and may have additional
information or modifications made in the course of processing by the
mailing list management software.  However, the personal copy almost
always arrives first, so doing this right requires temporary quarantine
and possible later release of mail, something that adds a tremendous
amount of complexity to mail handling.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Thu, 9 Sep 2004 22:17:13 -0400
From: Keith Moore <[email-masked]>
To: Nathaniel Borenstein <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> How would people feel about a strategy of clarifying a "default" 
> algorithm for followup mail, and standardizing a "Wide-Reply-To" 
> override?  -- Nathaniel

I am dubious of it, for the same reasons I am dubious about
Mail-Followup-To.  If the only thing anyone wants to do with it is
suppress duplicates that are  caused by mailing lists, it more-or-less
works.  But that's not the only reason people want to redirect replies. 
And when the header gets overloaded for multiple purposes, the recipient
has no way to sort this out.  Why does this header contain what it does?
 Is it  because the sender wants to eliminate duplicates, or because 
the sender thinks that discussion should naturally take place on a
particular list (and the recipient might disagree).

There really is a conflict sometimes between what the sender thinks
should happen in the event of a reply and what the recipient wants to
happen with the reply he composes.  In that circumstance, the recipient
needs to win. 

Now I agree that having recipients edit the list of reply addresses
is a rare case, but to some degree I think this is for two reasons:

1) user interfaces are still poor (but are slowly improving)
2) most people haven't been using email long enough to have developed
a shared sense of etiquette about such things such as exists for 
paper messages. (I think this will also improve)

I don't want to see the mail protocol changed to further discourage
editing of the reply list, since for many of the problems with
reply it seems like having recipients edit the reply list is the 
only way to solve them.

Also, it seems like overloading is at the heart of the problems
with Reply-To, so I'd like us to not go down that path again.

I think we are in agreement that user agents should uniformly
implement two reply functions (along with being able to edit the
reply address list);

- reply to author 
- wide reply (more or less "reply to everyone")

The first should go to From, though for the sake of a clean transition
it might be acceptable for recipient MUAs to honor Reply-To.  But use
of Reply-to in new messages should be discouraged.

The second should default to From+To+Cc.  It would be useful to provide
the sender with a way to override this - but this should be used only in
*rare* cases similar to the examples  in RFC 822: e.g. replies get
redirected to a secretary, or someone keeping track of the guest list at
a party, that sort of thing.  And when a recipient tries to reply to a
message with the override, his user agent should alert him to the fact
that this is an exceptional case - the reply isn't going to go where he
assumed it would go.  And it should give the recipient a chance to
ignore the override and send the reply to where he thinks it should go.

Because this is an exceptional case, this override SHOULD NOT be used
for duplicate suppression.  

Ideally duplicate suppression would be implemented in the recipient's
MUA (NOT the MUA composing replies) or in the recipient's message store.
One reason I believe this is that there are several other sources of 
duplicate messages than mailing lists.  Another reason I believe this
is that I think MUAs should be able to chase down threads that cross
folder boundaries (for instance between INBOX, Sent, and a list folder)
- and if they do that, they're within epsilon of being able to 
suppress duplicates anyway.

But if we really want to have recipients' MUAs suppress duplicates when
composing replies, we should do it differently than with the
Wide-Reply-To or Mail-Followup-To field.  For instance, we could have a
field of the form

Suppress-Duplicate: address1, [address2, address3, ... ]

which says that if a reply is being sent to _any_ of address1, address1,
etc., don't send a separate copy to the From address.

This would avoid overloading Wide-Reply-To (since it would distinguish
the exceptional case from the common case of wanting to suppress
duplicates), and it would allow duplicates to be suppressed even if the
recipient edited the list of reply addresses.

Keith

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 10 Sep 2004 00:35:56 +0200
Lines: 16
Cancel-Lock: sha1:ARZHcRiXQ+4E57/UvKHl0Zp5Iog=
Sender: [email-masked]

Nathaniel Borenstein <[email-masked]> writes:

> How would people feel about a strategy of clarifying a "default" 
> algorithm for followup mail, and standardizing a "Wide-Reply-To" 
> override?

What advantage would that have over standardizing Mail-Followup-To?
It appears to be the same idea to me.  If it is the same idea, then I
believe it would be simpler to standardize Mail-Followup-To.  MFT has
already been deployed in some communities.  If WRT isn't the same
idea, I think we need to understand how it differ from MFT, in the
same way we looked at how NR differ from MFT.  That exercise showed,
at least to me, that unmodified NR isn't a good enough solution.

Thanks,
Simon

Date: 9 Sep 2004 22:30:59 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Philip Hazel writes:
> I wanted to reply ONLY to the list (because I know that's what djb wants).

Right. Despite Keith's comments about ``trust,'' this isn't some sort of
battle between the sender and receiver. We're working together to have
followups sent to [email-masked] and not to [email-masked]:

   * I added [email-masked] to an MUA configuration file a long time
     ago.

   * My MUA, seeing that [email-masked] was in the recipient list for
     my message, copied the recipient list to Mail-Followup-To, leaving
     out [email-masked].

   * Philip followed up, and edited his message to omit [email-masked]
     from the recipient list. He wouldn't have had to do this manually
     if his MUA had supported Mail-Followup-To.

Let me emphasize that the goal---followups to [email-masked] and
replies to [email-masked] _not_ achieved by the old protocol ``reply
to Reply-To||From; follow up to To+Cc+(Reply-To||From).'' No matter what
I put into my message, the old protocol produces a followup address list
that includes the reply address list, so it fails to achieve the goal.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Cc: [email-masked]
From: Nathaniel Borenstein <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 9 Sep 2004 16:39:06 -0400
To: Philip Hazel <[email-masked]>
Sender: [email-masked]

In trying to project the seemingly unlimited set of possible reply 
semantics onto the visibly limited set of concepts that are 
comprehensible to the typical user, I keep coming back to the notion 
that there are really only 3 cases that are, at a first approximation, 
comprehensible to most mortals:

-- Reply to the user who sent the message.

-- Reply to the "discussion community" of the message (see below)

-- Reply highly idiosyncratically (i.e. let the user self-edit the 
headers)

That is, I'm hypothesizing (fairly confidently) that the vast majority 
of users won't be willing or able to differentiate beyond these three 
cases (and most won't even use the third).

If we eliminate the option of giving users way more options than they 
can handle, most of the complexity of this debate is then encapsulated 
as a debate over the definition of what I above call the "discussion 
community"  of a message.  I think there is a natural -- though 
grotesquely oversimplified -- tendency for users to assume that each 
message "naturally" defines such a community.  Though I think that the 
definition is neither natural nor simple, particularly given the 
baroqueness of our email protocols, I think it is our job as designers 
of protocols and systems to try, as best we can, to devise a consensus 
definition of such a community.

To put it another way, I think we should take it as a user-level 
requirement, for most users, that there can be a limited number of 
types of "reply" command, and that one of those few types should be one 
that does the best job possible of matching naive user expectations 
about the behavior of a simply named "reply to all" function (which is 
isomorphic to my notion of a "discussion community").

This is something that we worked very hard on in Andrew during the 
1980's.  Although the protocols have only become more complex since 
then, at that time we found that it was possible to devise an algorithm 
that did an extremely satisfactory job at what we then called "Wide 
Replies" using only a single non-standard extension to the email 
protocols.  The non-standard header we used was

	X-Andrew-Wide-Reply:  <addrlist>

The idea here was to permit the originating MUA (or an intermediate 
agent rewriting a message's headers, such as a list server) to use 
knowledge available at composition time to "override" the standard 
algorithm for calculating what "Reply to All" meant.  This fallback 
meant that even if our usual algorithm didn't work for a few cases, 
those cases were generally avoidable by having the originating software 
explicitly specify the wide-reply address.  (This eliminated, for 
example, the annoyingly common case of getting two copies of a message 
when someone replies to your mailing list post.  It also facilitated 
news-to-mail gatewaying by providing an email equivalent to 
"Followup-To".)

We never pushed this idea in the broader email community, but I still 
think that standardizing something like a "Wide-Reply-To" header, in 
order to gain some control on the sending side over the various 
algorithms that might define wide-reply semantics on the receiving 
side, would be a more constructive solution than a proliferation of 
user-level reply commands.  I just don't believe that users are going 
to be able to handle significantly more than a binary distinction 
(between "reply" and "reply to all"), and therefore I'd rather devote 
our efforts to making that paradigm work better, rather than towards a 
proliferation of incomprehensible options.

How would people feel about a strategy of clarifying a "default" 
algorithm for followup mail, and standardizing a "Wide-Reply-To" 
override?  -- Nathaniel

Date: Thu, 9 Sep 2004 17:03:44 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Thu, 9 Sep 2004, Bruce Lilly wrote:

> Or, in response to pine's "use Reply-To or From?" question,
> you could specify use of From.

Oh, I turned off that annoying prompt years ago. If there's a Reply-To, 
I always want to use it instead of From. However, that is not relevant 
in this case. There was no Reply-To in the message, and I did not want 
to reply to From (djb), I wanted to reply ONLY to the list (because I 
know that's what djb wants).

Regards,
Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Thu, 09 Sep 2004 11:11:54 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Eric A. Hall wrote:

> In theory you can do this with a single list by looking for a
> List-* header and matching it with an address in the TO

Bear in mind the fact that the List- fields and message address
fields specify very different things. Address fields may specify
a single mailbox (e.g. Sender), a list of mailboxes (e.g. From),
or a list of addresses (e.g. To) [addresses include named groups].
List- fields specify a list of bracketed URIs.  Comparing lists
of similar things can be tricky enough; comparing URIs with either
mailboxes or addresses is like comparing apples and oranges. Aside
from the fact that some URIs have nothing in common with mail
addresses or mailboxes (http, ftp, news, nntp schemes, etc.), even
if one limits consideration to mailto scheme URIs, one has to deal
with URI encoding in general and (rather poorly specified) mailto
URI encoding in particular.  After which one has on the one hand
a mailto URI which specifies a *message* (prototype) -- which
need not include *any* address fields -- vs. a list of addresses
or mailboxes.

Date: Thu, 09 Sep 2004 10:59:52 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Philip Hazel <[email-masked]>
CC: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Philip Hazel wrote:
> On Wed, 8 Sep 2004, D. J. Bernstein wrote:
> 
> 
>>rather than having to edit
>>
>>   To: [email-masked]
>>   Cc: [email-masked]
> 
> 
> In my case (Pine 4.61) it is worse. I have to edit
> 
> To      : "D. J. Bernstein" <[email-masked]>
> Cc      : [email-masked]
> 
> after "reply-to-all". Sure, I could leave a Cc: address without a To:, 
> but I don't like being untidy like that.

Or, in response to pine's "use Reply-To or From?" question,
you could specify use of From.

Date: Thu, 09 Sep 2004 09:04:54 -0400
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On 9/8/2004 10:17 PM, D. J. Bernstein wrote:

> Eric A. Hall writes:
> 
>>One thing I've noodled on is a "reply-to-list" option
> 
> Why? Do you think the user often wants to say ``I'd like my response to
> be visible to everyone who read the original message---but not the
> sender if he's a non-subscriber to this list, and not the subscribers of
> other lists if this message was crossposted''?

It should be clear from what I wrote in the message that you replied to
what I'm thinking about here, and that's not it.

> Even for single-list messages, I can't see whether ``reply to list'' is
> doing what I want unless I have extra information from the sender---

Right. In theory you can do this with a single list by looking for a
List-* header and matching it with an address in the TO header, but if
there are any other addresses in the TO/CC blocks (especially any other
list addresses for which there are no list-* header) it fails completely.
So what you really need is a way to overload the TO/CC blocks with
additional information, or really what would be better would be to define
new recipient header such as List or Group or whatnot, and which you could
match with more decisively, and which would survive multiple mailing lists
that pass through multiple servers. See the original message again; most
of this stuff is easier to think about in terms of "later".

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Thu, 9 Sep 2004 09:16:14 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Wed, 8 Sep 2004, D. J. Bernstein wrote:

> rather than having to edit
> 
>    To: [email-masked]
>    Cc: [email-masked]

In my case (Pine 4.61) it is worse. I have to edit

To      : "D. J. Bernstein" <[email-masked]>
Cc      : [email-masked]

after "reply-to-all". Sure, I could leave a Cc: address without a To:, 
but I don't like being untidy like that.

Regards,
Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Thu, 9 Sep 2004 09:13:14 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Nathaniel Borenstein <[email-masked]>
cc: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

On Tue, 7 Sep 2004, Nathaniel Borenstein wrote:

> At this point, I hypothesize that two kinds of reply -- roughly "the sender"
> and "everyone" -- is about as sophisticated a distinction as it is reasonable
> to inflict on the average user.

But, as in all these things, we should bear in mind that non-average 
users do exist.

Regards,
Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 8 Sep 2004 22:38:52 -0400
To: "D. J. Bernstein" <[email-masked]>
Sender: [email-masked]

> Even for single-list messages, I can't see whether ``reply to list'' is
> doing what I want unless I have extra information from the sender---
> information that can't be communicated through List-Post (because it's
> envelope information added by list managers) but that is communicated
> successfully through Mail-Followup-To.

You can't see whether "followup" is doing what you want either, even 
with Mail-Followup-To.  You may decide to trust it to do what you want, 
but when you do so you're implicit assuming that the sender who set 
Mail-Followup-To happens to want followups to go to the same place(s) 
that you do.  For instance, you can't use Mail-Followup-To to decide 
whether someone is a member of a particular list.

Keith

Date: 9 Sep 2004 02:17:52 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

Eric A. Hall writes:
> One thing I've noodled on is a "reply-to-list" option

Why? Do you think the user often wants to say ``I'd like my response to
be visible to everyone who read the original message---but not the
sender if he's a non-subscriber to this list, and not the subscribers of
other lists if this message was crossposted''?

Sure, there are _occasions_ when I decide to omit some recipients from
my followup, but the situations where I _don't_ want to do that are much
more common.

Even for single-list messages, I can't see whether ``reply to list'' is
doing what I want unless I have extra information from the sender---
information that can't be communicated through List-Post (because it's
envelope information added by list managers) but that is communicated
successfully through Mail-Followup-To.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

To: [email-masked]
Xref: clerew local.mime:3489
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Thu,  9 Sep 2004 00:01:22 +0000 (UCT)
Sender: [email-masked]

[email-masked]>   <[email-masked]>   <[email-masked]>   <[email-masked]>         <[email-masked]>  [email-masked]>fffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Date: Fri,  3 Sep 2004 02:14:59 +0000 (UCT)
X-ATT-Spam: Gauge=IIIIIII, Probability=7%, Report='__HAS_XOIP 0, X_AUTH_WARNING 0, __TO_MALFORMED_2 0, FWD_MSG 0, __HAS_MSGID 0, __SANE_MSGID 0, __C230066_P5 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, SIGNATURE_SHORT_DENSE 0'
Date: Thu, 2 Sep 2004 15:15:33 GMT
Lines: 26
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

FrontBridge Recognized in Prestigious Leaders Quadrant in Top Analyst Report on Enterprise Spam Filtering
For more details: Visit www.frontbridge.com

To: [email-masked]
Xref: clerew local.mime:3489
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Thu,  9 Sep 2004 00:01:22 +0000 (UCT)
Sender: [email-masked]

[email-masked]>   <[email-masked]>   <[email-masked]>   <[email-masked]>         <[email-masked]>  [email-masked]>fffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Date: Fri,  3 Sep 2004 02:14:59 +0000 (UCT)
X-ATT-Spam: Gauge=IIIIIII, Probability=7%, Report='__HAS_XOIP 0, X_AUTH_WARNING 0, __TO_MALFORMED_2 0, FWD_MSG 0, __HAS_MSGID 0, __SANE_MSGID 0, __C230066_P5 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, SIGNATURE_SHORT_DENSE 0'
Date: Thu, 2 Sep 2004 15:15:33 GMT
Lines: 26
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

FrontBridge Recognized in Prestigious Leaders Quadrant in Top Analyst Report on Enterprise Spam Filtering
For more details: Visit www.frontbridge.com

Date: Wed, 08 Sep 2004 16:37:24 -0400
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On 9/8/2004 3:00 PM, D. J. Bernstein wrote:

> Sometimes I want my response visible to everyone who read the original
> message. In standard USENET terminology, that's a ``followup,'' although
> I'd call it ``respond'' in an MUA.

<tangent>

One thing I've noodled on is a "reply-to-list" option, whereby the MUA
recognizes that one of the addresses is a list address and provides an
option to reply to that address only. This would align mailing lists with
the usenet model pretty tightly, which is a reasonable goal, if not the
subject of immediate discussion.

Lots of problems with this, not least of which is that not everybody in
the larger recipient list is necessarily a member of one of the mailing
lists cited in the incoming message. Thus, this only works until somebody
outside the list is added, and then it stops working entirely. There are
also problems with filling in numerous gaps in the header/protocol space
needed for this to work, and so deferring the problem for a replacement
message/protocol is easiest.

</tangent>

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: [email-masked]
Subject: Re: Understanding response protocols
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 08 Sep 2004 13:21:46 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> The protocol we're moving to---``reply to Mail-Reply-To||Reply-To||From;
>> follow up to Mail-Followup-To||(To+Cc+(Mail-Reply-To||Reply-To||From))''
>> ---solves all of these problems.

> What's this "we" stuff, white man?

There are multiple people moving to this protocol besides djb, including a
substantial portion of the Debian developer community, so I think "we" is
defensible here.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Wed, 8 Sep 2004 15:54:59 -0400
From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> 
> Nathaniel Borenstein writes:
> > Most users don't have a very complex mental model about this stuff.  
> 
> And experts are supposed to be an exception?
> 
> Sometimes I want my response visible to everyone who read the original
> message. In standard USENET terminology, that's a ``followup,'' although
> I'd call it ``respond'' in an MUA.
> 
> Sometimes I want my response visible only to the sender of the original
> message. In standard USENET terminology, that's a ``reply,'' although
> I'd call it ``respond only to sender'' in an MUA.
> 
> Those two cases cover almost every response I send. Yes, there are some
> occasions where I want to do something more complicated, but those
> occasions are rare enough that I don't mind handling them manually.
> 
> Of course, the followup address list and the reply address list are
> based on information provided by the sender. (I can't expect to send my
> message to the original Bcc addresses, for example!) This information is
> provided through a protocol. Do the protocol details really matter? Yes,
> they do:
> 
>    * The sender has to be able to specify a followup address list that
>      doesn't include the reply address list. 

Now you're making a leap.  You are presuming not only that this functionality
needs to be implemented in the recipient's MUA, you are also presuming the
form of data structure that the sender "has" to be able to specify to the
recipient's MUA.

If you phrased this a different way, e.g.

     * The sender would like to be able to arrange that he does not 
       receive duplicates of messages that are sent to multiple addresses,
       even if the sender is reachable through more than one of those
       addresses.

... then you'd be closer to something that there's general agreement on.

> The protocol we're moving to---``reply to Mail-Reply-To||Reply-To||From;
> follow up to Mail-Followup-To||(To+Cc+(Mail-Reply-To||Reply-To||From))''
> ---solves all of these problems.

What's this "we" stuff, white man?

Keith

Date: 8 Sep 2004 19:00:20 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Understanding response protocols
Sender: [email-masked]

Nathaniel Borenstein writes:
> Most users don't have a very complex mental model about this stuff.  

And experts are supposed to be an exception?

Sometimes I want my response visible to everyone who read the original
message. In standard USENET terminology, that's a ``followup,'' although
I'd call it ``respond'' in an MUA.

Sometimes I want my response visible only to the sender of the original
message. In standard USENET terminology, that's a ``reply,'' although
I'd call it ``respond only to sender'' in an MUA.

Those two cases cover almost every response I send. Yes, there are some
occasions where I want to do something more complicated, but those
occasions are rare enough that I don't mind handling them manually.

Of course, the followup address list and the reply address list are
based on information provided by the sender. (I can't expect to send my
message to the original Bcc addresses, for example!) This information is
provided through a protocol. Do the protocol details really matter? Yes,
they do:

   * The sender has to be able to specify a followup address list that
     doesn't include the reply address list. For example, the correct
     followup address list for this message is [email-masked]; the
     correct reply address list is [email-masked].

     Any protocol that doesn't allow this---for example, ``reply to
     Reply-To||From; follow up to To+Cc+(Reply-To||From)'', which was
     the de-facto standard---is inherently broken.

     Of course, I can say ``Please take [email-masked] out of the cc list
     if you're sending mail to [email-masked].'' Anyone following up
     can do this manually. But this human protocol is much less pleasant
     than something handled automatically by the MUAs.

   * There's a huge installed base of software that writes messages (and
     of messages already generated by that software). There's also a
     huge installed base of software that reads messages.

     A protocol that has horrible effects when it interacts with today's
     software---for example, ``reply to From; follow up to Reply-To''---
     isn't broken per se but would impose huge transition costs. Yes,
     the simplicity would be nice, but it's much more difficult to
     deploy than other protocols.

   * There's a small but noticeable installed base of mailing-list
     software that inserts the list address as Reply-To. This breaks
     ``reply to Reply-To||From,'' among other things.

     This software should be stamped out anyway, but in the meantime
     it's helpful for a protocol to provide a workaround.

The protocol we're moving to---``reply to Mail-Reply-To||Reply-To||From;
follow up to Mail-Followup-To||(To+Cc+(Mail-Reply-To||Reply-To||From))''
---solves all of these problems. It allows the sender to specify an
independent followup address list; it doesn't hurt existing software;
and it provides a workaround to Reply-To insertion.

As a practical matter, my MUA inserts Mail-Followup-To: [email-masked]
into this message, since I told it a long time ago that I didn't want
copies of messages sent to [email-masked]. If you follow up, and your
MUA supports Mail-Followup-To, then you'll be faced with the correct

   To: [email-masked]

rather than having to edit

   To: [email-masked]
   Cc: [email-masked]

down to the desired address list. Nobody has presented any reasons that
the protocol should be modified; the bottom line is that it works.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Cc: [email-masked]
From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Tue, 7 Sep 2004 23:09:09 -0400
To: Alan Barrett <[email-masked]>
Sender: [email-masked]

Please bear in mind  that the average user isn't going to have the 
slightest clue how to choose from among all these reply functions.  
(And consider the various potential types of "reply" when an MUA allows 
a user to select multiple messages at once and then choose a "reply" 
command.)  If an MUA must provide lots of reply types, it should at 
least check to see which kinds of reply yield identical results for the 
message(s) in question, and only offer one of any set of N types of 
replies that are functionally equivalent.  But I'd advocate a much 
simpler default interface for non-geek users.

Most users don't have a very complex mental model about this stuff.  
Back on the Andrew project, in the days when our users were dodging 
dinosaurs, we managed to rationalize our way to three different reply 
commands:

	Reply to Sender
	Reply to All
	Reply to Both

Users were understandably confused as to what the latter meant, and it 
only seemed to make sense to us at the time because we were totally 
geeky about what these commands meant.

At this point, I hypothesize that two kinds of reply -- roughly "the 
sender" and "everyone" -- is about as sophisticated a distinction as it 
is reasonable to inflict on the average user.  It should, however, be 
possible to define standard semantics for those two kinds of reply.  -- 
Nathaniel

On Sep 6, 2004, at 6:22 AM, Alan Barrett wrote:

>
> On Tue, 31 Aug 2004, Bruce Lilly wrote:
>> I know of at least two MUAs that provide three reply options:
>>     Kmail 1.7          Ximian Evolution 1.4.6
>> ---------------------------------------------
>> Reply to Author           Reply to Sender
>> Reply to All              Reply to All
>> Reply to Mailing List     Reply to List
>
> I especially do not want a "Reply to sender" function that is
> incorrectly labeled "Reply to author", or vice versa.
>
> I want at least five reply options:
>
>   "Reply"            (uses Reply-To header, falls back to From header)
>   "Reply to author"  (uses From header)
>   "Reply to sender"  (used Sender header, falls back to From header)
>   "Reply to all"     (uses all possible addresses, lets me edit the 
> list)
>   "Followup"         (somehow figures out how to send to mailing list)
>
> --apb (Alan Barrett)
>
>
>

Date: Tue, 7 Sep 2004 16:57:37 +0200
From: Martin Trautmann <[email-masked]>
Cc: 822 <[email-masked]>
Subject: Re: References, In-Reply-To, and Resent-Message-ID: responses and message fragmentation/reassembly
Sender: [email-masked]

On 2004-09-06 19:51, Russ Allbery wrote:
> 
> Jacob Palme <[email-masked]> writes:
> 
> > If you resend a message as a body part with an added comment, this is
> > rather similar to writing a reply to that message, and in the case of a
> > reply, both are included in References.
> 
> I would say that if you resend a message with an added comment, you're not
> resending, you're forwarding, and therefore you would not include Resent-*
> headers and that case would be handled very differently.

On the other hand I feel it's very reasonable to use
References/In-Reply-To for forwarded messages as well.
It should be highly encouraged by the RFC.

Concerning resent messages: I'm not very sure whether the In-Reply-To
should contain the original or the Resent ID. I could imagine both
situations as reasonable:

- resending a message for someone who lost the original:

As soon as he will reply to a resent message, while others (e.g. on a
mailing list) have the original one only, their thread is slightly broken.
Thus it's required that References contain at least

References: <former IDs> <original message-id> <resent-id>

In this situation here I'd vote more for the original message id within
the references.

- resending the message for someone else:

he may reply to this resent message. But again, if I resent a message to
someone else (which is named as 'bounce' in my mail tool) I won't keep a
copy of this resent message in my own box. Thus the Resent ID is not even
available here

- forwarding

... is a completely different story, creating a new message-id of its own.

I just checked RFC2822 for the Resent details:

   "The purpose of using resent fields is to have the message appear to
   the final recipient as if it were sent directly by the original sender,
   with all of the original fields remaining the same."

As I understand this, it's a rather strong argument to use the original
message-id for the In-Reply-To.

   '"Reply-To:", "Message-ID:", and other fields.  The resent fields are
   only informational and MUST NOT be used in the normal processing of
   replies.'

So you want to change this? Otherwise you MUST NOT use the
Resent-Message-ID for In-Reply-To!?

Kind regards
Martin

Date: Tue, 07 Sep 2004 07:53:42 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: Russ Allbery <[email-masked]>
CC: 822 <[email-masked]>
Subject: Re: References, In-Reply-To, and Resent-Message-ID: responses and message fragmentation/reassembly
Sender: [email-masked]

Russ Allbery wrote:
> Bruce Lilly <[email-masked]> writes:
> 
> 
>>I further believe that in the case of a response to a message containing
>>at least one Resent-Message-ID field, the msg-id placed in the response
>>In-Reply-To and/or References fields should be that of the most recent
>>Resent-Message-ID rather than that in the Message-ID field (if present)
>>or any other Resent-Message-ID field which might be present.
> 
> 
> I don't believe those semantics would be nearly as useful as following the
> standard References semantics.

On reflection, Resent-Message-ID shouldn't be used in responses.

However, I think there is still a problem w.r.t. message/partial.

To: 822 <[email-masked]>
Subject: Re: References, In-Reply-To, and Resent-Message-ID: responses and  message fragmentation/reassembly
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 06 Sep 2004 19:51:34 -0700
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> If you resend a message as a body part with an added comment, this is
> rather similar to writing a reply to that message, and in the case of a
> reply, both are included in References.

I would say that if you resend a message with an added comment, you're not
resending, you're forwarding, and therefore you would not include Resent-*
headers and that case would be handled very differently.

I don't see a problem with including both message IDs in the case of
responding to a forwarded message (although most commonly software will
refer to only the message ID of the forwarded message since the forward
operation normally doesn't construct a References header), but I don't
think the case of a forwarded message with additional comments is
equivalent to a resent message.

Resending is intended to be more "invisible" to mail semantics,
retroactively adding additional recipients to the message, and I think the
construction of the References header should follow that principle.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Tue, 7 Sep 2004 04:46:44 +0200
To: Russ Allbery <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: References, In-Reply-To, and Resent-Message-ID: responses and  message fragmentation/reassembly
Cc: 822 <[email-masked]>
Sender: [email-masked]

At 11.21 -0700 04-09-06, Russ Allbery wrote:
>Bruce Lilly <[email-masked]> writes:
>
>> I further believe that in the case of a response to a message containing
>> at least one Resent-Message-ID field, the msg-id placed in the response
>> In-Reply-To and/or References fields should be that of the most recent
>> Resent-Message-ID rather than that in the Message-ID field (if present)
>> or any other Resent-Message-ID field which might be present.
>
>I don't believe those semantics would be nearly as useful as following the
>standard References semantics.  Consider the case where someone resends a
>mailing list message to someone who didn't receive the original, and the
>recipient then responds to the message, cc'ing the mailing list.  If the
>References header is constructed in the traditional fashion, the reply of
>the person to whom the message was resent will thread correctly for all of
>the readers of the mailing list.  If the References header is constructed
>from the Resent-Message-ID field, it will not.

A related case is if a message with Message-ID A is included as
a body-part in a new message B, and resent in that fashion.
Since References and In-Reply-To naturally use the Message-ID
of the enclosing message, there will be no link to the original
Message-ID, and recipients of it will not be able to threrad
if they only have the original message.

Would not a good solution to both this, and the Resent-Message-ID
case, be to include both Message-IDs in References, but only
the most recent in In-Reply-To.

If you resend a message as a body part with an added comment,
this is rather similar to writing a reply to that message,
and in the case of a reply, both are included in References.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Mon, 6 Sep 2004 18:46:55 -0400
To: ietf-822 <[email-masked]>
Sender: [email-masked]

>>> In at least some situations, using a "work" address in messages
>>> sent from "home" or vice versa or similar dichotomies would
>>> likely be looked upon with a jaundiced eye; far worse in some
>>> cases.
>>
>>
>> Yes, that's true - but I don't think it's up to the mail system
>> to enforce such rules, any more than I think it's up to the
>> snail-mail postal service to check whether a residental customer
>> is sending out mail on company letterhead.
>
> I'm not suggesting that the mail system as such should implement
> such forms of enforcement; merely that some configurations do
> so.

Understood.  I'm suggesting that those configurations should be 
declared dysfunctional and encouraged to change.  Again, I think we're 
not going to fix any of these problems unless we discourage some 
existing behavior and recommend some new behavior to replace it.  In 
this case we could fix this problem in either of two ways:

1) insist that From should be settable by the author, and invent a new 
field to do what Sender was supposed to do, but in a better way

2) declare that From has become what Sender is supposed to be, and 
invent a new field (maybe call it Authors:) to specify the authors' 
addresses

I happen to prefer the first one, as it is both consistent with the 
original design and compatible with existing user agents.  I'd rather 
break a few dysfunctional private mail systems than break everyone's 
user agent.  If #2 were chosen senders could put the authors' addresses 
in Reply-To in addition to the Authors: field (assuming they didn't 
want to redirect replies to somewhere else).  But this would overload 
Reply-To even more than it is already.

>> The reason we're having these problems is because of overloading
>> of various fields - reply-to, from, sender, mail from - to the
>> point that they've become ambiguous.  I suspect we're not going to 
>> solve
>> the problems without discouraging some of the overloading.  And that
>> in turn probably means we'll have to define some new ways of doing
>> some of the things we used to overload these fields for.
>
> Not merely header fields are overloaded, as discussed on mail-ng,
> the message header itself is overloaded.

very true.

>  To the point that it's
> nigh impossible to separate them (see the recent list message
> regarding Resent-Message-ID and message/partial for a hint). I
> don't think it's possible to provide a clean solution short of
> a new design that takes into account the lessons learned in the
> past three decades.

And I don't think it's possible for any solution to be successful 
unless it considers transition issues.  We're not going to get 10**9 
email users to change if it involves very much pain, and especially not 
if old user agents can't easily exchange mail with new ones, and vice 
versa.  And I consider having replies work in an unsurprising and 
effective manner part of what it means to "exchange mail".

Keith

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: reply options
Date: Mon, 6 Sep 2004 18:31:01 -0400
To: Alan Barrett <[email-masked]>
Sender: [email-masked]

> On Mon, 06 Sep 2004, Keith Moore wrote:
>> The recipient typically doesn't have a button that implements 
>> "ordinary
>> reply" - he has two buttons which implement
>>
>> 	"To+Cc+(Reply-to?Reply-to:From)"
>>
>> (typically labeled "reply all") and
>
> Labelling that button "reply all" is an error, because it fails to
> include the From address in the list.

Agreed.  In addition, reply-to can cause "reply all" (if it's 
implemented in this way) to do something besides "reply all".

>> b) "reply to originator"	
>>
>> This would probably go to the Return-Path - though strictly speaking,
>> that's the address where errors should go.  We don't really have an
>> address for the originator.  Sender is effectively deprecated - it's
>> far more widely misused (by lists) than used correctly.
>
> Sender is supposed to be the originator.  Lists should leave the header
> Sender alone, and adjust the envelope sender (or Return-Path).  Sadly,
> some don't do that.

Understood.  For a variety of reasons, including not only the behavior 
of certain lists but also changes in the way mail tends to be submitted 
these days, I think it's too late to restore the original function of 
Sender.  I think we need a new field that is set by the MSA, and I 
think it needs to be defined very carefully in order to strike a 
balance between privacy and traceability.

>> c) "reply"			
>>
>> This would be like your "ordinary reply", I think - it would do the
>> right thing in the vast majority of cases.  If defined in terms of
>> today's email header fields it would be something like
>>
>> 	Reply-to?Reply-to:(To+Cc+From)
>
> You are assuming that an ordinary reply should go to to+cc+from (if
> there is no Reply-to).  I assume that an ordinary reply should go to 
> the
> From address (if there is no Reply-to).

I think "ordinary" has a lot to do with the nature of the message.  But 
in email "reply to the author and most recipients" seems more commonly 
to be the right thing than "reply only to the author" (even if the 
author can override this with Reply-To).

> I think my assumption is closer
> to how things work with paper mail, but I think that both options are
> useful.

With paper mail it's so laborious to construct replies anyway that the 
effort required to think about what the "right thing" is (i.e. where 
replies should go) is marginal.  Email makes it so easy to reply that 
it becomes easier to not think about where replies should go.

>> - (maybe) the author should be able to specify alternate addresses
>>
>> I say "maybe" because while useful for delegation, experience seems
>> to suggest that this is a rare case.  I wonder if it's worth the
>> additional complexity it requires, especially if (as I am starting to
>> believe) overloading Reply-to to do both that _and_ excluding unwanted
>> recipients is a bad idea.
>
> When I send mail with Reply-To set, what I mean is "please think
> carefully before replying to any address other than the one I specified
> in the Reply-To field".  I suppose I'd like the recipient's user agent
> to ask some kind of "are you sure?" question if the recipient invokes
> any kind of reply function that would end up sending to some other
> address.

As long as Reply-To were only used for the rare case of delegation, I 
think that would be fine.  I think it would be annoying if Reply-to 
were used as a matter of course to do things like redirect replies to a 
list.

>   [snip example]
>> Now maybe that's an exceptional case which isn't worth worrying about,
>> but it illustrates that "wrong split".  Reply-to doesn't tell the
>> recipient or the recipient's UA _why_ certain addresses should or
>> should not see replies - it only tells what to do in the ordinary
>> case.  In any case except the one the author deems "ordinary", the UA
>> will often do the wrong thing by default, and the recipient is left to
>> guess.
>
> The recipient can be guided by natural language explanantions in the
> body of the message.  The UA needs to make it easy for the recipient to
> specify exactly where to send the reply.
>
> Some sort of Reply-case header might help:
>
> 	Reply-case: Public discussion: list@domain ;,
> 	            Respond to author: author@domain ;,
> 		    Register for the event: secretary@domain ;
>
> User agents would display the list of cases and ask which one (or more)
> was appropriate.

Maybe.  What I'm thinking of is slightly different.  Maybe a hint that 
says "B is contained in Y; please don't CC address B if you're sending 
to address Y".

>> In all cases I think the person composing the reply should be able
>> to (a) see the original addresses and (b) override the default
>> reply recipient list - no matter which kind of reply is chosen.
>
> Yes, and also see which header field each original address came from.
> If a user agent does all this, then I can use my own judgement to
> make replies go to the right place.

Yes, I think this is essential no matter what else we might come up 
with.

Keith

Date: Tue, 7 Sep 2004 00:12:20 +0200
From: Alan Barrett <[email-masked]>
To: [email-masked]
Subject: Re: reply options
Sender: [email-masked]

On Mon, 06 Sep 2004, Keith Moore wrote:
> The recipient typically doesn't have a button that implements "ordinary 
> reply" - he has two buttons which implement
> 
> 	"To+Cc+(Reply-to?Reply-to:From)"
> 
> (typically labeled "reply all") and 

Labelling that button "reply all" is an error, because it fails to
include the From address in the list.

> 	"Reply-to?Reply-to:From" 
> 
> (typically labeled "reply").

This button implements what I called an ordinary reply.

> b) "reply to originator"	
> 
> This would probably go to the Return-Path - though strictly speaking,
> that's the address where errors should go.  We don't really have an
> address for the originator.  Sender is effectively deprecated - it's
> far more widely misused (by lists) than used correctly.

Sender is supposed to be the originator.  Lists should leave the header
Sender alone, and adjust the envelope sender (or Return-Path).  Sadly,
some don't do that.

> c) "reply"			
> 
> This would be like your "ordinary reply", I think - it would do the
> right thing in the vast majority of cases.  If defined in terms of
> today's email header fields it would be something like
> 
> 	Reply-to?Reply-to:(To+Cc+From)

You are assuming that an ordinary reply should go to to+cc+from (if
there is no Reply-to).  I assume that an ordinary reply should go to the
>From address (if there is no Reply-to).  I think my assumption is closer
to how things work with paper mail, but I think that both options are
useful.

> - (maybe) the author should be able to specify alternate addresses
>
> I say "maybe" because while useful for delegation, experience seems
> to suggest that this is a rare case.  I wonder if it's worth the
> additional complexity it requires, especially if (as I am starting to
> believe) overloading Reply-to to do both that _and_ excluding unwanted
> recipients is a bad idea.

When I send mail with Reply-To set, what I mean is "please think
carefully before replying to any address other than the one I specified
in the Reply-To field".  I suppose I'd like the recipient's user agent
to ask some kind of "are you sure?" question if the recipient invokes
any kind of reply function that would end up sending to some other
address.

  [snip example]
> Now maybe that's an exceptional case which isn't worth worrying about,
> but it illustrates that "wrong split".  Reply-to doesn't tell the
> recipient or the recipient's UA _why_ certain addresses should or
> should not see replies - it only tells what to do in the ordinary
> case.  In any case except the one the author deems "ordinary", the UA
> will often do the wrong thing by default, and the recipient is left to
> guess.

The recipient can be guided by natural language explanantions in the
body of the message.  The UA needs to make it easy for the recipient to
specify exactly where to send the reply.

Some sort of Reply-case header might help:

	Reply-case: Public discussion: list@domain ;,
	            Respond to author: author@domain ;,
		    Register for the event: secretary@domain ;

User agents would display the list of cases and ask which one (or more)
was appropriate.

> In all cases I think the person composing the reply should be able
> to (a) see the original addresses and (b) override the default 
> reply recipient list - no matter which kind of reply is chosen.

Yes, and also see which header field each original address came from.
If a user agent does all this, then I can use my own judgement to
make replies go to the right place.

> I also think that such an interface would make it easier for UAs to be
> more flexible about replies.  Right now for the typical GUI there's a
> limit on screen real estate - five reply buttons is just too many, and
> if some of the least frequently used functions are placed elsewhere
> they just won't be used.  Putting the functionality in a compose
> window (again with immediate feedback) would make it reasonable to
> give the user more choices.  Also, it puts the functionality where
> it belongs - since choosing a recipient list is very much part of
> composing a message.

I agree with what I think you are saying.  A GUI user agent should
probably have one big reply button, and after you press it, you should
get a way of deciding which address to reply to, and you should be able
to change your mind before sending.  A command based user agent can have
as many commands as it likes.

--apb (Alan Barrett)

Date: Mon, 06 Sep 2004 18:11:35 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: ietf-822 <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Keith Moore wrote:

>>In at least some situations, using a "work" address in messages
>>sent from "home" or vice versa or similar dichotomies would
>>likely be looked upon with a jaundiced eye; far worse in some
>>cases.
> 
> 
> Yes, that's true - but I don't think it's up to the mail system
> to enforce such rules, any more than I think it's up to the 
> snail-mail postal service to check whether a residental customer
> is sending out mail on company letterhead.

I'm not suggesting that the mail system as such should implement
such forms of enforcement; merely that some configurations do
so.

> The reason we're having these problems is because of overloading
> of various fields - reply-to, from, sender, mail from - to the
> point that they've become ambiguous.  I suspect we're not going to solve
> the problems without discouraging some of the overloading.  And that
> in turn probably means we'll have to define some new ways of doing 
> some of the things we used to overload these fields for.

Not merely header fields are overloaded, as discussed on mail-ng,
the message header itself is overloaded.  From a start (RFC 56)
where it consisted of author-specified front matter, it has had
various other functions -- transport trace information (Mail-From,
Received, Return-Path), recipient MUA directives
(Disposition-Notification-Options, Disposition-Notification-To),
sender front matter (List-*), body metadata (most of the MIME
fields), magic tokens for gateways (most of the MIXER fields),
and more than a little cruft (primarily marketing fluff such as
Posting-Version, User-Agent, etc.).  To the point that it's
nigh impossible to separate them (see the recent list message
regarding Resent-Message-ID and message/partial for a hint). I
don't think it's possible to provide a clean solution short of
a new design that takes into account the lessons learned in the
past three decades.

Date: Mon, 6 Sep 2004 15:43:42 -0400
From: Keith Moore <[email-masked]>
To: ietf-822 <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> > users should be able to set the From field on a per-message basis.
> > (it's not forgery if the address belongs to you)
> 
> In at least some situations, using a "work" address in messages
> sent from "home" or vice versa or similar dichotomies would
> likely be looked upon with a jaundiced eye; far worse in some
> cases.

Yes, that's true - but I don't think it's up to the mail system
to enforce such rules, any more than I think it's up to the 
snail-mail postal service to check whether a residental customer
is sending out mail on company letterhead.

> >> Now you might say "forge From" instead of using Reply-To, but that
> >> won't work with some times of authentication and spam filtering.
> > 
> > 
> > most forms of spam filtering are too broken to use anyway.  and any
> > authentication mechanism that restricts the setting of From is
> > broken. From is clearly not intended to be used for that purpose.
> 
> In some cases, the setting that affects the From header field also
> affects SMTP MAIL FROM, and that is sometimes (rightly or wrongly)
> used as a weak form of authentication.

The reason we're having these problems is because of overloading
of various fields - reply-to, from, sender, mail from - to the
point that they've become ambiguous.  I suspect we're not going to solve
the problems without discouraging some of the overloading.  And that
in turn probably means we'll have to define some new ways of doing 
some of the things we used to overload these fields for.

Keith

Date: Mon, 6 Sep 2004 15:39:49 -0400
From: Keith Moore <[email-masked]>
To: Alan Barrett <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: reply options
Sender: [email-masked]

> > >I want at least five reply options:
> > >
> > >  "Reply"            (uses Reply-To header, falls back to From
> > >  header)
> > >  "Reply to author"  (uses From header)
> > >  "Reply to sender"  (used Sender header, falls back to From
> > >  header)
> > >  "Reply to all"     (uses all possible addresses, lets me
> > >                     edit the list)
> > >  "Followup"         (somehow figures out how to send to mailing
> > >                     list)
> > 
> > I'm curious - when would you use "Reply" or "Reply to sender"?  or
> > to ask the question another way, what assumptions are you making
> > about how "Reply-to" and "Sender" fields are used that would cause
> > you to want those functions?
> 
> The Reply-To header says where the author suggests that ordinary
> replies should go.  "Ordinary" replies are whatever the author thinks
> will be the most common type of reply to this particular message.

I think this illustrates the "wrong split" I was talking about in an
earlier message when I wrote:

> > I think the current typical user interface has the wrong split
> > between what the author of a message specifies and what the
> > recipient specifies when he's composing a reply.

The recipient typically doesn't have a button that implements "ordinary 
reply" - he has two buttons which implement

	"To+Cc+(Reply-to?Reply-to:From)"

(typically labeled "reply all") and 

	"Reply-to?Reply-to:From" 

(typically labeled "reply").  Neither function does what is needed, and
both functions are mislabeled in that they don't always do what the user
thinks they will do.  And because reply-to affects both of them "reply
all" the way it does, its applicability is greatly reduced.

My list would be similar to yours but I would want

a) "reply to author(s)"	

This would go to the From address(es).

b) "reply to originator"	

This would probably go to the Return-Path - though strictly speaking,
that's the address where errors should go.  We don't really have an
address for the originator.  Sender is effectively deprecated - it's
far more widely misused (by lists) than used correctly.  We probably
need some kind of address for the originator to be added by the MSP -
though getting the right balance between tracability and anonymity
is hard.

c) "reply"			

This would be like your "ordinary reply", I think - it would do the
right thing in the vast majority of cases.  If defined in terms of
today's email header fields it would be something like

	Reply-to?Reply-to:(To+Cc+From)

But it might be the case that some new fields should be defined
to make this work better.

Basically, ordinary reply should be "reply to all" with the following
exceptions:

- (maybe) the author should be able to specify alternate addresses

I say "maybe" because while useful for delegation, experience seems 
to suggest that this is a rare case.   I wonder if it's worth
the additional complexity it requires, especially if (as I am
starting to believe) overloading Reply-to to do both that _and_ 
excluding unwanted recipients is a bad idea.

- it should exclude certain recipients who should not get replies.

One kind of recipient who should not get replies is an author who has
said "don't reply to me if you're also replying to any of these
addresses".

Another kind of recipient who should not get replies is a recipient who
the author has said "don't send replies to this recipient".

Another kind of recipient who should not get replies is a list that has
said "don't reply to this list".  Though I don't see any way to
implement that in the recipients' user agents for recipients who don't
get the message from the list.

Even if "reply" is defined as

	Reply-to?Reply-to:(To+Cc+From)

it doesn't suffice for all cases.  For instance, say a message is sent
to recipients A, B, X, and Y where X and Y are mailing lists, A is a
member of list X, and B is a member of list Y.  Let's further say that A
doesn't wish to be copied on messages to list X and B doesn't wish to be
copied on messages to list Y.

Perhaps the author of the message is aware of A and B's	preferences so
he sets reply-to to X and Y only.  But if the person sending the reply
decides that his reply is not appropriate for list Y, he has no way of
knowing whether he should copy B.  The reply-to field doesn't tell the
recipient whether B wants copies of messages sent to Y, it only says
what to do under "ordinary" circumstances.  

Now maybe that's an exceptional case which isn't worth worrying about,
but it illustrates that "wrong split".  Reply-to doesn't tell the
recipient or the recipient's UA _why_ certain addresses should or 
should not see replies - it only tells what to do in the ordinary
case.  In any case except the one the author deems "ordinary", the
UA will often do the wrong thing by default, and the recipient is 
left to guess.

-- 

In all cases I think the person composing the reply should be able
to (a) see the original addresses and (b) override the default 
reply recipient list - no matter which kind of reply is chosen.
			
--

Another thing I'd want a UA to do is to be able to change "reply modes"
during and after message composition, rather than having to choose
the reply mode before message composition.  There are two reasons for
this.  First, I'm often finding after composing a message that I 
want to make it public (if I originally hit "reply") or private 
(if I originally hit "reply all").  Second, I think that if UAs had
buttons or a menu at the top of a compose window that let the user
select which kind of reply to send (and provided immediate feedback
about how this changed the recipient list) it would help the recipient 
make appropriate choices about who should and should not receive replies.

I also think that such an interface would make it easier for UAs to 
be more flexible about replies.  Right now for the typical GUI there's
a limit on screen real estate - five reply buttons is just too many,
and if some of the least frequently used functions are placed elsewhere
they just won't be used.  Putting the functionality in a compose window
(again with immediate feedback) would make it reasonable to give the
user more choices.  Also, it puts the functionality where it belongs -
since choosing a recipient list is very much part of composing a message.

Keith

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Mon, 6 Sep 2004 15:34:12 -0400
Cc: Alan Barrett <[email-masked]>
Sender: [email-masked]

On Mon September 6 2004 06:22, Alan Barrett wrote:
> 
> On Tue, 31 Aug 2004, Bruce Lilly wrote:
> > I know of at least two MUAs that provide three reply options:
> >     Kmail 1.7          Ximian Evolution 1.4.6
> > ---------------------------------------------
> > Reply to Author           Reply to Sender
> > Reply to All              Reply to All
> > Reply to Mailing List     Reply to List
> 
> I especially do not want a "Reply to sender" function that is
> incorrectly labeled "Reply to author", or vice versa.

For the record, Kmail's Reply To Author does use the From field.
There is aslo a "Reply", which uses Reply-To is present.

Pine by default asks each time whether to use From or Reply-To.

The "Reply to Sender" in Evolution does *not* use the Sender field.
It uses Reply-To.
 
> I want at least five reply options:
> 
>   "Reply"            (uses Reply-To header, falls back to From header)
>   "Reply to author"  (uses From header)
>   "Reply to sender"  (used Sender header, falls back to From header)
>   "Reply to all"     (uses all possible addresses, lets me edit the list)
>   "Followup"         (somehow figures out how to send to mailing list)

So, other than Reply To Sender, Kmail may be a viable MUA for you.

Date: Mon, 06 Sep 2004 14:45:31 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: ietf-822 <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Keith Moore wrote:

> users should be able to set the From field on a per-message basis.
> (it's not forgery if the address belongs to you)

In at least some situations, using a "work" address in messages
sent from "home" or vice versa or similar dichotomies would
likely be looked upon with a jaundiced eye; far worse in some
cases.

>> Now you might say "forge From" instead of using Reply-To, but that
>> won't work with some times of authentication and spam filtering.
> 
> 
> most forms of spam filtering are too broken to use anyway.  and any
> authentication mechanism that restricts the setting of From is broken. 
> From is clearly not intended to be used for that purpose.

In some cases, the setting that affects the From header field also
affects SMTP MAIL FROM, and that is sometimes (rightly or wrongly)
used as a weak form of authentication.

To: 822 <[email-masked]>
Subject: Re: References, In-Reply-To, and Resent-Message-ID: responses and message fragmentation/reassembly
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 06 Sep 2004 11:21:54 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> I further believe that in the case of a response to a message containing
> at least one Resent-Message-ID field, the msg-id placed in the response
> In-Reply-To and/or References fields should be that of the most recent
> Resent-Message-ID rather than that in the Message-ID field (if present)
> or any other Resent-Message-ID field which might be present.

I don't believe those semantics would be nearly as useful as following the
standard References semantics.  Consider the case where someone resends a
mailing list message to someone who didn't receive the original, and the
recipient then responds to the message, cc'ing the mailing list.  If the
References header is constructed in the traditional fashion, the reply of
the person to whom the message was resent will thread correctly for all of
the readers of the mailing list.  If the References header is constructed
from the Resent-Message-ID field, it will not.

I think the best way of looking at the process of resending a message from
the perspective of thread integrity is that it is the after-the-fact
addition of recipients to an equivalent of an MUA Bcc field.  In effect,
the distribution of the original message is being expanded retroactively.
It's useful to include those trace headers so that a recipient of a resent
message can figure out what happened, but I believe if the conversation
then continues, much more is gained by unifying the replies to the
original and the replies to the resent message into a single thread than
distinguishing replies to one from the other.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Mon, 6 Sep 2004 19:58:07 +0200
From: Alan Barrett <[email-masked]>
To: [email-masked]
Subject: Re: reply options
Sender: [email-masked]

On Mon, 06 Sep 2004, Keith Moore wrote:
> >I want at least five reply options:
> >
> >  "Reply"            (uses Reply-To header, falls back to From header)
> >  "Reply to author"  (uses From header)
> >  "Reply to sender"  (used Sender header, falls back to From header)
> >  "Reply to all"     (uses all possible addresses, lets me edit the 
> >                     list)
> >  "Followup"         (somehow figures out how to send to mailing list)
> 
> I'm curious - when would you use "Reply" or "Reply to sender"?  or to 
> ask the question another way, what assumptions are you making about how 
> "Reply-to" and "Sender" fields are used that would cause you to want 
> those functions?

The Reply-To header says where the author suggests that ordinary replies
should go.  "Ordinary" replies are whatever the author thinks will be
the most common type of reply to this particular message.  A missing
Reply-To means just use the From address.  Authors often want to suggest
that ordinary replies should go somewhere other than the From address;
for example, to a mailing list.

If the author has suggested that replies should go elsewhere, but I
really want to contact the author, then I want to invoke a "Reply to
author" function in my mailer, and that function should use the From
address.  This can easily happen when the author suggests that ordinary
replies (say discussing the meat of a proposal) should go to a mailing
list, but I want to make a response of a different sort (say discussing
the formatting of the proposal, or pointing out a typo that the mailiing
list doesn't need to discuss).

If my response is related to the addressing of the message (say I have
recently changed addresses, or will soon change addresses), or the
formatting of the email wrapper around the author's work, then I want to
send my response to the Sender.

I am aware that some user agents don't allow senders to override the
>From field, and that Reply-To gets used in cases where I would advocate
overriding the From.  I am also aware that, when a message has a
Reply-To field, some user agents make it difficult to reply to the
author or sender.  I think that people should not use such user agents.

--apb (Alan Barrett)

Date: Mon, 06 Sep 2004 11:03:11 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: 822 <[email-masked]>
Organization: Bruce Lilly
To: 822 <[email-masked]>
Subject: References, In-Reply-To, and Resent-Message-ID: responses and message fragmentation/reassembly
Sender: [email-masked]

RFC 2822 discusses In-Reply-To and References header fields with respect to
the Message-ID field.  I believe that ignores the situation where at least
one Resent-Message-ID field exists in addition to (or possibly in lieu of)
a Message-ID field.  I further believe that in the case of a response to a
message containing at least one Resent-Message-ID field, the msg-id placed
in the response In-Reply-To and/or References fields should be that of the
most recent Resent-Message-ID rather than that in the Message-ID field (if
present) or any other Resent-Message-ID field which might be present. Also
in the case where at least one Resent-Message-ID field is present, response
message In-Reply-To and References fields should be prepared as described
above whether or not the message being responded to has a Message-ID field.
I propose that whereas RFC 2822 text regarding this topic says:

   The "In-Reply-To:" and "References:" fields are used when creating a
   reply to a message.  They hold the message identifier of the original
   message and the message identifiers of other messages (for example,
   in the case of a reply to a message which was itself a reply).  The
   "In-Reply-To:" field may be used to identify the message (or
   messages) to which the new message is a reply, while the
   "References:" field may be used to identify a "thread" of
   conversation.

   When creating a reply to a message, the "In-Reply-To:" and
   "References:" fields of the resultant message are constructed as
   follows:

   The "In-Reply-To:" field will contain the contents of the "Message-
   ID:" field of the message to which this one is a reply (the "parent
   message").  If there is more than one parent message, then the "In-
   Reply-To:" field will contain the contents of all of the parents'
   "Message-ID:" fields.  If there is no "Message-ID:" field in any of
   the parent messages, then the new message will have no "In-Reply-To:"
   field.

    The "References:" field will contain the contents of the parent's
   "References:" field (if any) followed by the contents of the parent's
   "Message-ID:" field (if any).  If the parent message does not contain
   a "References:" field but does have an "In-Reply-To:" field
   containing a single message identifier, then the "References:" field
   will contain the contents of the parent's "In-Reply-To:" field
   followed by the contents of the parent's "Message-ID:" field (if
   any).  If the parent has none of the "References:", "In-Reply-To:",
   or "Message-ID:" fields, then the new message will have no
   "References:" field.

The successor to RFC 2822 should probably say something like:

   The "In-Reply-To:" and "References:" fields are used when creating a
   reply to a message.  They hold the most recent message identifier of
   the original message and the most recent message identifiers of other
   messages (for example, in the case of a reply to a message which was
   itself a reply).  The "In-Reply-To:" field may be used to identify
   the message (or messages) to which the new message is a reply, while
   the "References:" field may be used to identify a "thread" of
   conversation.

   When creating a reply to a message, the "In-Reply-To:" and
   "References:" fields of the resultant message are constructed as
   follows:

   The "In-Reply-To:" field will contain the field body of the most recent
   "Resent-Message-ID:" field if any such field is present in the message
   to which this one is a reply (the "parent message"), or, if no
   "Resent-Message-ID" field is present in the parent message, the
   field body of the "Message-ID:" field of the parent message.  If there
   is more than one parent message, then the "In-Reply-To:" field will
   contain the field bodies of all of the parents' most recent "Resent-
   Message-ID:" or "Message-ID:" fields.  If there are no
   "Resent-Message-ID:" or "Message-ID:" field in any of the parent
   messages, then the new message will have no "In-Reply-To:" field.

   The "References:" field will contain the field body of the parent's
   "References:" field (if any) followed by the field body of the parent's
   most recent "Resent-Message-ID:" or "Message-ID:" field (if any).  If
   the parent message does not contain a "References:" field but does
   have an "In-Reply-To:" field containing a single message identifier,
   then the "References:" field will contain the field body of the parent's
   "In-Reply-To:" field followed by the field body of the parent's most
   recent "Resent-Message-ID:" or "Message-ID:" field (if any).  If the
   parent has none of the "References:", "In-Reply-To:",  "Resent-Message-ID:",
   or "Message-ID:" fields, then the new message will have no
   "References:" field.

Note that I have replaced the undefined term "contents" with the
RFC 2822-defined term "field body".

While responses to multiple messages were discussed briefly in June 2003
on this mailing list, I am not addressing that issue here.

Also in June of last year, the issue of message fragmentation and reassembly
using the MIME message/partial media type was briefly discussed. RFC 2046
specifies special treatment for a limited set of header fields, that set
having been amended by RFC 3798 (formerly 2298).  Message-ID is part of
that set, while Resent-Message-ID is not.  In order to survive a
fragmentation/reassembly cycle, the Resent-Message-ID field (and indeed all
fields not part of the set specified in 2046/3798) must be copied (or
moved) to the header of the first fragment.  That means that in addition
to the issue of the semantics of the Date field mentioned last year, the
first part will also attain the semantics associated with Resent-Date
and other Resent- fields.  In the case of the Resent-Message-ID field(s),
that means that the first fragment has the same Resent- msg-id identifiers
as the unfragmented message, violating the principle of uniqueness. Note
that that does not happen when there are no Resent-Message-ID fields in
the unfragmented message, because the Message-ID field is in the set of
fields mentioned above, which are taken from the header of the
encapsulated message during reassembly.

I believe the fragmentation/reassembly issue is more challenging, as
it does not appear to be possible to preserve transparency across
a fragmentation/reassembly cycle while maintaining message origination
date and identification semantics with the current (2046/3798)
fragmentation/reassembly rules; at least one of the three -- transparency,
semantics, or rules -- would have to change.  I believe that it would be
possible to preserve transparency and semantics, but ensuring
interoperability would entail a new media type similar to message/partial
but with different fragmentation/reassembly rules (or a MIME-Version
change with updated rules applying to message/partial; unfortunately
MIME-Version semantics for a version other than 1.0 aren't provided for).

There are probably other header fields where the message/partial rules
may lead to problems; I expect to be able to summarize several of those
in a future message; I'm concentrating on Resent-Message-ID here.

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: reply options
Date: Mon, 6 Sep 2004 12:19:18 -0400
To: Alan Barrett <[email-masked]>
Sender: [email-masked]

> I want at least five reply options:
>
>   "Reply"            (uses Reply-To header, falls back to From header)
>   "Reply to author"  (uses From header)
>   "Reply to sender"  (used Sender header, falls back to From header)
>   "Reply to all"     (uses all possible addresses, lets me edit the 
> list)
>   "Followup"         (somehow figures out how to send to mailing list)

I'm curious - when would you use "Reply" or "Reply to sender"?  or to 
ask the question another way, what assumptions are you making about how 
"Reply-to" and "Sender" fields are used that would cause you to want 
those functions?

Keith

Date: Mon, 6 Sep 2004 12:22:11 +0200
From: Alan Barrett <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

On Tue, 31 Aug 2004, Bruce Lilly wrote:
> I know of at least two MUAs that provide three reply options:
>     Kmail 1.7          Ximian Evolution 1.4.6
> ---------------------------------------------
> Reply to Author           Reply to Sender
> Reply to All              Reply to All
> Reply to Mailing List     Reply to List

I especially do not want a "Reply to sender" function that is
incorrectly labeled "Reply to author", or vice versa.

I want at least five reply options:

  "Reply"            (uses Reply-To header, falls back to From header)
  "Reply to author"  (uses From header)
  "Reply to sender"  (used Sender header, falls back to From header)
  "Reply to all"     (uses all possible addresses, lets me edit the list)
  "Followup"         (somehow figures out how to send to mailing list)

--apb (Alan Barrett)

Date: Mon, 6 Sep 2004 13:50:51 +0900
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: draft-crocker-email-arch
Sender: [email-masked]

Folks,

CD> <http://www.ietf.org/internet-drafts/draft-crocker-email-arch-01.txt>
CD> That is a work in progress - obviously.

Thanks for mentioning this, Cyrus.

In fact I would like to progress the document, but have not gotten
enough feedback to justify claiming that it represents community
consensus.

PLEASE comment on it.  The first round of comments resulted in
substantial changes.  I'm more than happy to have that happen again
(as long as it looks like convergence, of course.)

Then again, a wave of "looks fine"s won't be met with hostility,
either...

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

From: Keith Moore <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Sun, 5 Sep 2004 17:39:19 -0400
To: ietf-822 <[email-masked]>
Sender: [email-masked]

>> As it's implemented today, Reply-to is little more than a surrogate
>> From.  Actually, we would probably be better off without it
>
> I strongly disagree. It is often necessary to specify that replies 
> should
> go elsewhere than the mailbox(es) in the From field:
> 1. a message sent from work, responses desired at home or vice versa

users should be able to set the From field on a per-message basis.
(it's not forgery if the address belongs to you)

> 2. multiple authors, responses should go to one author

potentially useful, but rarely used

> 3. the case in point, message sent from an individual, responses should
>    go to a list mailbox

fair enough.  though presumably the list is one of the recipients of 
the message, and if there were a way to say "don't reply to the author" 
that would also work.

there are indeed cases where it would be useful if the author could 
redirect replies (say, to a secretary) but the way Reply tends to be 
implemented by user agents, this isn't likely to work well anyway.

I think the current typical user interface has the wrong split between 
what the author of a message specifies and what the recipient specifies 
when he's composing a reply.

> Now you might say "forge From" instead of using Reply-To, but that
> won't work with some times of authentication and spam filtering.

most forms of spam filtering are too broken to use anyway.  and any 
authentication mechanism that restricts the setting of From is broken.  
 From is clearly not intended to be used for that purpose.

>>> Now it happens to be the case that most MUAs have two types of reply
>>> functions corresponding to the two cases.
>>
>> Both of which do the wrong thing.  "plain reply" should probably be
>> (and be labeled) "reply to author".
>
> Nothing prevents MUA authors from implementing that -- indeed, pine
> can be configured so, and Kmail provides a working "Reply to Author"
> in addition to other types of responses.

maybe other MUA authors need encouragement?

>> The other "reply" (call it "group
>> reply") should probably have some way of excluding recipients that, 
>> for
>> whatever reason, should not receive replies.
>
> Are you suggesting a field that modifies the interpretation of a 
> different
> field? I thought you were opposed to that.

everything else being equal, I would prefer something like To-NoReply. 
but I am trying to keep an open mind about other possibilities.

>> It might be the case that
>> "group reply" should be the default, though this would probably be too
>> big a departure from existing behavior.
>
> We probably ought not to specify such details of UA design as which 
> type
> of response is the default.

not clear.  lack of uniformity in UA behavior causes problems.  I don't 
think we should specify details like what the interface should look 
like, where the buttons should be, whether it's a command-line or GUI 
interface, etc.  I do think it might be useful to encourage some degree 
of uniformity as to which functions are provided, and I do think it 
might be useful to say "please provide ways of doing these things".

>> Many MUAs don't even display reply-to fields when viewing
>> a message.
>
> The MUAs mentioned above, as well as several others, do.  In any
> event, when a response is being composed, surely the recipient(s)
> is/are displayed in any sensible MUA -- advice to MUA authors
> comes into play if there are any MUAs that don't display recipients 
> when
> composing a response.

often there's no easy way to tell how the recipients of a reply relate 
to the sender and recipients of the original message.  that is why 
reply behavior can be surprising.

> I haven't use MacOS of any flavor for sending mail, but I've had no
> problems with doing so, including cutting and pasting addresses in
> (and *between*) common MUAs on several flavors of MS Windows
> and under the X Window System.   Taht aside, we should differentiate
> architectural issues from implementation issues.  Architecturally, 
> there
> is nothing preventing a user from viewing or setting message header
> fields. Implementation issues may well warrant advice to MUA authors.

I agree that these are implementation issues.

Keith

To: [email-masked]
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: 05 Sep 2004 22:35:00 +0200
Lines: 43
Sender: [email-masked]

Keith Moore <[email-masked]> schrieb/wrote:
> Or to put it another way: MUAs really need a "reply author" button,
> but they don't have one.  The typical "reply" button doesn't quite
> work like it should because the "narrow reply" really doesn't map to
> what the recipient is likely to want to do.

> (The only time I ever use (narrow) "reply" is when I really want
> "reply to author".

Granted, there are very few cases when a "narrow reply" is not a "reply
to the from address". But there are examples:

. The more common case is where Reply-To is an alternative address for
  the author. You could use this address in From, too, but some
  environments (MUA, ISP, whatever) unfortunatly don't allow this.

  | From: [email-masked]
  | To: [email-masked]
  | Reply-To: [email-masked]
  | Mail-Followup-To: [email-masked]

  Whether we like it or not, this use is quite common.

. The author is actually writing on behalf of a different person or
  a group of persons. In this case, "narrow replies" often should be
  direct not to the author but to the person(s) on behalf of which the
  message was written.

  | From: [email-masked]
  | To: [email-masked], [email-masked]
  | Reply-To: [email-masked]
  | Mail-Followup-To: [email-masked]

  | From: [email-masked]
  | To: [email-masked], [email-masked]
  | CC: [email-masked]
  | Reply-To: [email-masked]
  | Mail-Followup-To: [email-masked]

Claus
-- 
http://www.faerber.muc.de

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Sun, 5 Sep 2004 11:30:38 -0400
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

On Sat September 4 2004 20:20, Keith Moore wrote:

> > No, the assumption I'm making is that the message author(s) know(s) 
> > where he wants plain replies (as opposed to reply-to-all) to go and is 
> > capable of setting Reply-To accordingly.
> 
> Perhaps, but that's nearly useless, as there's no way to encourage 
> users to use "plain reply".

There's no difference if the only mailbox in To+Cc is the list mailbox
in the situation under discussion  -- and that is likely to be the usual
case in that situation.
 
> As it's implemented today, Reply-to is little more than a surrogate 
> From.  Actually, we would probably be better off without it

I strongly disagree. It is often necessary to specify that replies should
go elsewhere than the mailbox(es) in the From field:
1. a message sent from work, responses desired at home or vice versa
2. multiple authors, responses should go to one author
3. the case in point, message sent from an individual, responses should
   go to a list mailbox
4. delegation
etc.

Now you might say "forge From" instead of using Reply-To, but that
won't work with some times of authentication and spam filtering.

> > Now it happens to be the case that most MUAs have two types of reply 
> > functions corresponding to the two cases.
> 
> Both of which do the wrong thing.  "plain reply" should probably be 
> (and be labeled) "reply to author".

Nothing prevents MUA authors from implementing that -- indeed, pine
can be configured so, and Kmail provides a working "Reply to Author"
in addition to other types of responses.

> The other "reply" (call it "group  
> reply") should probably have some way of excluding recipients that, for 
> whatever reason, should not receive replies.

Are you suggesting a field that modifies the interpretation of a different
field? I thought you were opposed to that.

> It might be the case that  
> "group reply" should be the default, though this would probably be too 
> big a departure from existing behavior.

We probably ought not to specify such details of UA design as which type
of response is the default.
 
> > No. regardless of how Reply-To is set, anyone can easily copy-and-paste
> > an address, or call it up from an address book, etc.
> 
> For most of the MUAs I've seen, "easily" is a huge stretch.  First, the 
> recipient composing the reply has to notice that reply-to is set.  this 
> is difficult because few MUAs bother to provide any kind of alert to 
> this effect.

Mozilla, Kmail, Evolution show Reply-To.  Probably many others as
well.

> Many MUAs don't even display reply-to fields when viewing  
> a message.

The MUAs mentioned above, as well as several others, do.  In any
event, when a response is being composed, surely the recipient(s)
is/are displayed in any sensible MUA -- advice to MUA authors
comes into play if there are any MUAs that don't display recipients when
composing a response.

> Copying and pasting is not necessarily easy even if the  
> recipient notices - especially on systems where you have to click a 
> window to select it, where clicking also raises the window and buries 
> other windows.   I've even see cases where copying an address and 
> pasting in another window *of the same app* didn't paste the same text 
> that was copied.  Now maybe that's just an isolated bug, but in my 
> experience with windows, macosx, and X11 systems - copy and paste 
> basically sucks on all of them.  Then there are of course systems where 
> copy and paste doesn't exist.

I haven't use MacOS of any flavor for sending mail, but I've had no
problems with doing so, including cutting and pasting addresses in
(and *between*) common MUAs on several flavors of MS Windows
and under the X Window System.   Taht aside, we should differentiate
architectural issues from implementation issues.  Architecturally, there
is nothing preventing a user from viewing or setting message header
fields. Implementation issues may well warrant advice to MUA authors.

Date: 05 Sep 2004 15:33:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Bruce Lilly)  wrote on 04.09.04 in <[email-masked]>:

> Russ Allbery wrote:
>
> > However, by doing so, I am making it difficult for anyone to send a
> > private reply to me should they have something they don't feel is
> > appropriate for the list.
> [...]
> > I want to
> > indicate a preference that if the message is sent to the mailing list, I
> > not recieve an extra *copy*.
> >
> > There is no way of representing those semantics with Reply-To in the way
> > that you describe
> [...]
> > Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>
>                 ^^^^^^^^^^^^^^^^
> All of a sudden it's "difficult" to click on a mailto URI like the
> one above?  Or to right-click on the mailbox in the From line and
> select "compose mail to"?

Not difficult. Impossible, for example for me. This client here doesn't  
understand a mouse. Nor does it even try to find stuff in unstructured  
text that looks like an address.

(Incidentally, I don't see any mailto URI here. Just a naked address.)

There's generic cut&paste ... it's usually significantly easier to use the  
address book.

MfG Kai

Date: Sat, 04 Sep 2004 20:30:18 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Russ Allbery <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Russ Allbery wrote:

> However, by doing so, I am making it difficult for anyone to send a
> private reply to me should they have something they don't feel is
> appropriate for the list.
[...]
> I want to
> indicate a preference that if the message is sent to the mailing list, I
> not recieve an extra *copy*.
> 
> There is no way of representing those semantics with Reply-To in the way
> that you describe
[...]
> Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>
                ^^^^^^^^^^^^^^^^
All of a sudden it's "difficult" to click on a mailto URI like the
one above?  Or to right-click on the mailbox in the From line and
select "compose mail to"?  With a "reply to author" function that
works (i.e. using the From field), what precisely is the problem?

There's no way to specify what you say you want using standard fields
*other* than with Reply-To as described.  If a new field adding some
nuance were added tomorrow, the standardized current behavior for
responses which is based solely on the existing standard fields
would continue to be used until a new standard taking the
hypothetical new field into account were written, plus software
implementing that in UAs was written -- and widely deployed.
Any such scheme would have to account for the diversity of senders'
desires, so that you can indicate what you want, Keith can indicate
what he wants, etc.

Adding properly implemented "reply to author" to UAs is likely to
happen faster that any such field addition + standards revision +
UA software rewrites.  Assuming the hypothetical standards revision
wouldn't entail any interoperability problems...

It looks like the "least pain" solution still involves user
education + advice to UA authors; followed by action by UA
authors to implement "reply to author" where is has not already
been properly implemented.

Cc: Keith Moore <[email-masked]>, Russ Allbery <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Sat, 4 Sep 2004 20:20:03 -0400
To: [email-masked]
Sender: [email-masked]

>> It sounds like you're making the assumption that there are two types 
>> of
>> reply (individual and to-all), and Reply-To should be used to send 
>> them to
>> the appropriate location with the only difference being whether 
>> people in
>> the To and Cc headers are included.
>
> No, the assumption I'm making is that the message author(s) know(s) 
> where he wants plain replies (as opposed to reply-to-all) to go and is 
> capable of setting Reply-To accordingly.

Perhaps, but that's nearly useless, as there's no way to encourage 
users to use "plain reply".

As it's implemented today, Reply-to is little more than a surrogate 
From.  Actually, we would probably be better off without it - because 
adding reply-to to a message results in less predictable behavior on 
the part of the recipient.

> Now it happens to be the case that most MUAs have two types of reply 
> functions corresponding to the two cases.

Both of which do the wrong thing.  "plain reply" should probably be 
(and be labeled) "reply to author".  The other "reply" (call it "group 
reply") should probably have some way of excluding recipients that, for 
whatever reason, should not receive replies.  It might be the case that 
"group reply" should be the default, though this would probably be too 
big a departure from existing behavior.

>> The use that you're making of Reply-To works fine for  individual 
>> e-mail,
>> but when used in the list context, it breaks private reply.
>
> No. regardless of how Reply-To is set, anyone can easily copy-and-paste
> an address, or call it up from an address book, etc.

For most of the MUAs I've seen, "easily" is a huge stretch.  First, the 
recipient composing the reply has to notice that reply-to is set.  this 
is difficult because few MUAs bother to provide any kind of alert to 
this effect.  Many MUAs don't even display reply-to fields when viewing 
a message.  Copying and pasting is not necessarily easy even if the 
recipient notices - especially on systems where you have to click a 
window to select it, where clicking also raises the window and buries 
other windows.   I've even see cases where copying an address and 
pasting in another window *of the same app* didn't paste the same text 
that was copied.  Now maybe that's just an isolated bug, but in my 
experience with windows, macosx, and X11 systems - copy and paste 
basically sucks on all of them.  Then there are of course systems where 
copy and paste doesn't exist.

Keith

To: [email-masked]
Cc: Keith Moore <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 04 Sep 2004 16:50:01 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> Now it might be ever so slightly more work to send to an author who has
> explicitly set Reply-To to point elsewhere -- presumably because he
> doesn't want personal responses -- than if Reply-To isn't set; but why
> *shouldn't* that be the case given that authors preference for not
> receiving personal responses?

Your presumption is frequently wrong.  That's my point.

For example, in order to get you to stop sending me copies of mail to the
mailing list, you think I should add a Reply-To header pointing to the
list.  However, by doing so, I am making it difficult for anyone to send a
private reply to me should they have something they don't feel is
appropriate for the list.  I have no desire to do this, and I do *not*
want to indicate a preference for no personal responses.  I want to
indicate a preference that if the message is sent to the mailing list, I
not recieve an extra *copy*.

There is no way of representing those semantics with Reply-To in the way
that you describe, and I have no desire to force people to cut and paste
my address from somewhere else to send me personal mail where appropriate.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 04 Sep 2004 19:43:15 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Russ Allbery <[email-masked]>
CC: [email-masked], Keith Moore <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Russ Allbery wrote:
> Bruce Lilly <[email-masked]> writes:
> 
> 
>>Assuming that there is such a thing as a "list preference" for replies
>>to the list, that can be easily achieved by haying the list expander
>>insert a Reply-To field pointing to the list mailbox if and only if
>>there is no (author-provided) Reply-To field in the message.
> 
> 
> It sounds like you're making the assumption that there are two types of
> reply (individual and to-all), and Reply-To should be used to send them to
> the appropriate location with the only difference being whether people in
> the To and Cc headers are included.

No, the assumption I'm making is that the message author(s) know(s)
where he wants plain replies (as opposed to reply-to-all) to go and
is capable of setting Reply-To accordingly.  Now it happens to be
the case that most MUAs have two types of reply functions corresponding
to the two cases.  A few have a third which uses some preconfigured
mailbox (or address, or mailbox-list or address-list  or mailto URI).
Some may well have other capabilities in addition.

> The use that you're making of Reply-To works fine for  individual e-mail,
> but when used in the list context, it breaks private reply.

No. regardless of how Reply-To is set, anyone can easily copy-and-paste
an address, or call it up from an address book, etc.  Nothing "breaks".
Now it might be ever so slightly more work to send to an author who
has explicitly set Reply-To to point elsewhere -- presumably because
he doesn't want personal responses -- than if Reply-To isn't set; but
why *shouldn't* that be the case given that authors preference for not
receiving personal responses?

> You could, of course, argue that private reply should be implemented by
> ignoring the Reply-To header, and in fact one MUA has already made that
> choice

I wouldn't argue that per se, but I see nothing wrong with a *properly*
*implemented* "reply-to-author" function that uses From rather than
Reply-To (since From is where author information is located) in addition
to the usual reply functions.  Indeed the desirability of such capability
is mentioned in at least one of the references recently mentioned here
if I recall correctly.

Date: Sat, 04 Sep 2004 19:30:03 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Keith Moore wrote:

> There are fewer problems with lists that only insert reply-to
> if it isn't there already, but some problems still remain.
> 
> (see http://www.cs.utk.edu/~moore/opinions/reply-problem-list.html ,
> items B3, B4, and B5)

Bearing in mind the context of the discussion:
1. a hypothetical list consensus for reply-to-list as default
implemented by
2. list expansion adds a Reply-To field pointing to the list
   submission mailbox iff there is no Reply-To field in the
   message

Let's look at those:

B3.	If a message is sent to multiple recipients, one
        or more of which is a mailing list, and one of
        those mailing lists adds a Reply-To field,
        members of that mailing list have difficulty
        replying to all recipients of the original
        message. This thwarts cross-list discussions,
        which are sometimes desirable.

If the sender doesn't set Reply-To and the lists don't
set Reply-To, then a reply-all reaches all recipients
plus the author(s) plus and other original message recipients.
Whereas a plain "reply" would go only to the author(s).
In the situation posited, some list sets Reply-To;
presumably To and Cc are not corrupted.  Therefore a
reply-to-all will still go to all recipients plus the
author(s) plus any other original recipients, with no
particular difficulty involved. A plain "reply", however
will only go to the one list that set Reply-To.  If the
sender recognizes that multiple lists may be involved, he
can forestall the situation by including a Reply-To
field that points to all lists (or to the highest
precedence list which includes sublists).

B4.	If a mailing list leaves an existing Reply-To
        field in place, but supplies a Reply-To field
        if one is missing, there's no way for the
        recipient's UA to know whether the field was
        added by the list or not. The results can be
        surprising.
        (If Reply-To points to the list and the recipient
        presses a button labeled "reply to author",
        there's a good chance he doesn't want the
        response to go to the list.)

Agreed that failing a comment or some other indication
that a list expanded added a Reply-To field -- "no way"
overstates the case -- a user can't tell where the Reply-To
field came from.  Why should he need to know or care?
As for the hypothetical UA that has a button labeled
"reply to author" but which uses the Reply-To field when
it is pressed, that UA is broken; the From field -- not
Reply-To -- indicates the message author(s).  Reply-To
is not and never has been guaranteed to point to the
message author.  Now if that hypothetical "reply to
author" button uses the From field, which is what a
button with such a label ought to do, B4 as a "problem"
vanishes in a puff of smoke.  Likewise if the label
says simply "reply" and Reply-To is used -- that is how
a reply is normally constructed.

B5.	If a message is sent to a mailing list that
        adds or mungs Reply-To, and the author of
        that message is not on the mailing list, any
        replies that go just to Reply-To won't go to
        the author. Even replies that go to
        Reply-To+To+Cc won't go to the author of the
        subject message unless the author has included
        himself in the To or Cc list.

Such an author who does not want replies other than to
the list will be happy as a pig in manure.  An author
who wants only personal replies can add a Reply-To
field -- remember, we're talking about a list expander
that does *not* add Reply-To if one exists -- and an
author who wants both list and personal replies can
set Reply-To to include list and personal addresses if
he wishes that to be the case for a plain "reply", or
he can -- as you suggest -- simply put his address in
To or Cc (leaving out Reply-To or setting it to point
to the list mailbox) if he wants plain replies to go
to the list and reply-all replies to go to the list
plus his mailbox.

Now it may be the case that some UAs might not make it
easy to set Reply-To.  That may warrant some advice to
UA authors.  The UAs that I tend to use have no serious
problems in that regard; most have the ability to set a
default Reply-To field on a per-"identity" basis and
provide an easy-to-use means of switching identities.
Some have the ability to set the default Reply-To field
on a per-folder basis without changing "identity".  The
ones with GUIs have the ability to copy-and-paste
between address fields, so starting with reply-to-all,
it is simple enough to copy the list mailbox and paste
it over Reply-To whether or not there is a default.
That leaves non-GUI MUAs with no means to set a default
Reply-To field on a per-folder or per-identity basis or
which otherwise make it difficult to switch identities.
The non-GUI UAs that I am familiar with that are likely
to be used by anybody that receives a significant amount
of mail all have at least some sort of "address book"
that can be used to select the appropriate list mailbox
for a Reply-To field, once it has been entered one time
in the address book.  So while it's possible that somewhere
there's a UA that makes setting Reply-To difficult, I
don't recall having used it (and if I did use it, the lack
of such basic functionality would have been a good reason
to have moved on to something else).

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Sun, 05 Sep 2004 00:52:58 +0200
Lines: 42
Cancel-Lock: sha1:rH/YhEUviH5bk/rqY0vYKmkRY74=
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> I only know a few mailing lists where personal copies are actively
>> encouraged as part of the culture, and in one of those they're still
>> supposed to be selective (including only the people who have action items
>> in the mail being sent). 
>
> I'd like to dig down a bit here:
>
> - to me, whether you want personal copies on a reply to a list seems
>   like a sender preference rather than a list preference.  it depends
>   on how much mail you get, how you process mail, etc.  for me, it's
>   obvious that I do want separate copies, because I have all of my
>   list mail sent to sub-folders, and I like to arrange things so that
>   my inbox has a history of all of my correspondence and the replies
>   to my correspondence, while my list folders are complete archives
>   of the list.  but I can certainly imagine how someone with a single
>   mail folder would not want to see duplicates.

As another view, I also have many folders for mailing lists, but I
generally don't want to receive duplicates of replies in personal
mail.  My reasoning is that things discussed in public on mailing
lists have no business in my private inbox.  Having copies of all
discussions I've participated on mailing lists in my private inbox
would make it more difficult to find real personal mail.

This just show that even users with presumably large amounts of
e-mail, and many folders, don't agree on how to organize their mail.
Which I guess is what you should expect, but I'm not sure it has been
all that clear.

So I agree that receiving copies of mailing list discussions is a
sender preference, but it seems it is not easy to categorize senders
to know what their preferences are.  I mean, here we have two
presumably "power users" that don't agree on whether they want copies
or not.  I don't know what kind of (useful) categories one would have
to define in order to separate our two preferences.  Perhaps it is not
useful to think of the preference decision as being related to any
kind of user category, at all.

Thanks,
Simon

To: [email-masked]
Cc: Keith Moore <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 04 Sep 2004 13:57:53 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> Assuming that there is such a thing as a "list preference" for replies
> to the list, that can be easily achieved by haying the list expander
> insert a Reply-To field pointing to the list mailbox if and only if
> there is no (author-provided) Reply-To field in the message.

It sounds like you're making the assumption that there are two types of
reply (individual and to-all), and Reply-To should be used to send them to
the appropriate location with the only difference being whether people in
the To and Cc headers are included.  While this may be correct for
individual e-mail, this is manifestly not the case for list e-mail.

There are similarly two different styles of reply for list mail, but
they're a *different* two.  They are exactly analogous to the two styles
of reply to a Usenet posting, namely "private reply" and "public reply."
(And there is, in fact, a third, rarer type of reply, namely the list
equivalent of reply to all that includes any additional people or lists
addressed in the message, but let's put that aside for the moment.)

The use that you're making of Reply-To works fine for individual e-mail,
but when used in the list context, it breaks private reply.  Now, I
realize that there are some lists where private replies are always
inappropriate, but again one cannot generalize from one particular type of
mailing list, and there are many where this is *not* the case.

You could, of course, argue that private reply should be implemented by
ignoring the Reply-To header, and in fact one MUA has already made that
choice, but then you get into all sorts of other trouble since that use is
not anticipated by any mail standard and the MUA cannot adequately
distinguish between personal e-mail (where this is wrong) and list mail
(where this may be arguably correct).

Different people have different priorities, but I personally consider
private reply to be vitally important and any solution that breaks private
reply to not be a solution at all.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 4 Sep 2004 16:54:36 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> > If an MFT spec were adopted, I can't imagine that it would recommend such
> > behavior.  It might even discourage such behavior.
> 
> Maybe.  But it hasn't been adopted, it isn't specified in any RFC or
> draft; heck it isn't even fully specified anywhere.  The reality is
> that MFT proponents send unsolicited "you need to use MFT" messages.

Personally I've only seen such messages from one person.  While those
messages don't exactly make MFT look more attractive to me, I'd rather
evaluate such proposals on their technical merits rather than on tbe
behavior of their proponents.

Keith

Date: Sat, 04 Sep 2004 16:25:44 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Keith Moore wrote:

> If an MFT spec were adopted, I can't imagine that it would recommend such
> behavior.  It might even discourage such behavior.

Maybe.  But it hasn't been adopted, it isn't specified in any RFC or
draft; heck it isn't even fully specified anywhere.  The reality is
that MFT proponents send unsolicited "you need to use MFT" messages.
That tends to discourage support for MFT for precisely the same
reason that other types of spam tends to discourage support for the
products and services that those messages hawk.

I wouldn't be at all surprised if adoption caused the "you need to
use MFT" messages to become more strident and annoying.

Date: Sat, 4 Sep 2004 16:08:57 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> Assuming that there is such a thing as a "list preference" for
> replies to the list, that can be easily achieved by haying the
> list expander insert a Reply-To field pointing to the list
> mailbox if and only if there is no (author-provided) Reply-To
> field in the message. 

Only if authors somehow learn to always insert reply-to when 
they don't want the list to override it.  Even then, there's 
potential for confusion among recipients who might be willing
to override a list preference, but not an author preference.
(or vice versa).

> It doesn't require umpteen different
> fields which modify the semantics of other fields or which
> modify the behavior of the *recipient's* UA.  Some list
> expanders do insert Reply-To fields; the contentious issue
> seems to be ignoring the "if and only if" part that effectively
> causes such list expanders to override individual preference.

There are fewer problems with lists that only insert reply-to
if it isn't there already, but some problems still remain.

(see http://www.cs.utk.edu/~moore/opinions/reply-problem-list.html ,
items B3, B4, and B5)

Keith

Date: Sat, 4 Sep 2004 16:04:48 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> Keith Moore <[email-masked]> writes:
> 
> > These days for many mailing lists, this isn't even feasible - the list
> > will filter traffic from non-subscribers.  The list might or might not
> > get so much spam that manual approval of the non-subscriber traffic is
> > feasible.  And whether the sender wants a copy of replies depends
> > heavily on the nature of the list.
> 
> Be careful not to focus too much on the public Internet case here. 

good point.

Keith

Date: Sat, 4 Sep 2004 16:04:27 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> Keith Moore <[email-masked]> writes:
> 
> > - to me, whether you want personal copies on a reply to a list seems
> >   like a sender preference rather than a list preference.  it
> >   depends on how much mail you get, how you process mail, etc.
> 
> Although one thing that has to factor into this is whether the person
> is on the mailing list at all.  I always want personal copies of mail
> to lists that I'm not on, for instance.
> 
> >   for me, it's obvious that I do want separate copies, because I
> >   have all of my list mail sent to sub-folders, and I like to
> >   arrange things so that my inbox has a history of all of my
> >   correspondence and the replies to my correspondence, while my list
> >   folders are complete archives of the list.  but I can certainly
> >   imagine how someone with a single mail folder would not want to
> >   see duplicates.
> 
> Of course, part of the problem is that it's obvious to you, but not
> obvious to anyone corresponding with you. 

Nor is it obvious to someone corresponding with me whether I'm
subscribed to the list.  (For instance, I post to the ietf list once in
awhile, and I occasionally even "reply" to messages, but I'm not
subscribed any more.  I scan the archives every few days.)

> One could jump to the
> conclusion that you do because you send them, but that frequently
> isn't the case; there are people who send them and don't want them 

True.

> I'm not sure whether you're right that personal copies are always a
> sender preference.  You may be.  I can't think of a good
> counter-argument right now.  (Whether replies should go *only* to the
> individual or also to the list is often a list preference, however.)

There are certainly lists for which it is never appropriate to copy them
on replies.  For instance, there are announcement-only lists.
 
> Incidentally, it's not just a question of single folder vs. multiple
> folders.

Agree.  I am just citing that as a convenient example.

(aside: I keep wanting an MUA that will give me views of messages
independently of folders.   For instance, I want a view that contains
every message in every thread I've contributed to, even though those
messages might actually be in a variety of folders.  If I had that
kind of MUA, I might be quite happy to not be cc'ed on replies that
included any list I happened to be subscribed to, because my MUA 
would find the message in the folder for that list.  OTOH, such an
MUA would certainly need to be able to detect duplicates anyway.)

> > - a separate issue is whether an address continues to get copied
> >   on subsequent replies.  (A sends a message to the list, B
> >   replies with a message To A and CC the list, C replies to B's
> >   message, CC'ing A and the list.  A gets CC'ed on subsequent
> >   messages in that thread).  *that* might well be a list preference.
> 
> Good point.  It would indeed be better to deal with that as a separate
> issue, since that's where most of the complaints come from that I see.
> The quantity of mail is larger if Cc's keep being preserved, so while
> people are willing to delete one message, they get annoyed by deleting
> multiple messages.

One wrinkle might be that this is sometimes related to topic drift.
some folks are fine with the first few cc's but as the discussion
changes focus those people are less relevant.  I don't have any good
ideas for how to deal with that in the context of email discussion
groups - for a discussion medium to deal with that problem reliably and 
effectively I suspect it needs a very different architecture than
either email or usenet.

> > - different communities do have different ideas on the best way
> >   to handle these issues.   often this is  a reflection of
> >   the technical sophistication of each community and the kinds of
> >   tools they tend to use.   at other times it's a reflection of
> >   the kinds of conversations those communities want to have. 
> 
> In my experience it really is more the latter than the former.  Much
> is made in this debate of how one side or the other believes what they
> do because they don't understand how mail works, but that hasn't been
> my experience.

My experience is that users with different levels of sophistication
will want to solve the same problem in different ways.  A more 
sophisticated group will be more likely to file incoming messages
into folders, set up filters to cull out messages they don't want
to see, etc. - because they want more flexibility out of email.
A less sophisticated group will want reply-to to point to the list,
subject fields to be munged to include the list name, etc.  They 
may or not be aware of the problems caused by these things (some
are, some aren't) but in either they don't care about the problems
because they don't miss the functionality they're losing.

> >   I don't necessarily think it's useful or appropriate for technical
> >   standards to accommodate everybody's different ways of dealing
> >   with a problem. I think the technical standards need to define a
> >   small number of ways to deal with the problem (ideally one way)
> >   and try to make sure that that way will work for the diverse sets
> >   of users out there.
> 
> That being said, I think any solution to the list reply problem that
> doesn't deal with list preference for personal replies, list
> preference for replies back to the list, personal preference for
> copies of list replies, and personal preference for no copies of list
> replies, plus still copying people who aren't on the list, is
> insufficient to the task.

Hmm.  It might be useful to try to design  a system with those
parameters and see what it looks like.  I'm thinking that if an author
says he wants a personal reply, he should definitely get one - but if
the list says that  the author should not get a personal reply, maybe
the personal replies should be Bcc'ed (or Cc-No-Reply'ed).  Or to put it
another way, maybe the list's preference is properly not whether
personal replies should be sent, but whether personal replies should be
visible to the list.

Keith

Date: Sat, 04 Sep 2004 15:52:20 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Russ Allbery <[email-masked]>
CC: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Russ Allbery wrote:
> Keith Moore <[email-masked]> writes:

>>and even assuming that list culture has a genuine interest here, how to
>>deal with the conflict between individual user preference and list
>>preference?
> 
> 
> I would say that individual preference would always override.

Assuming that there is such a thing as a "list preference" for
replies to the list, that can be easily achieved by haying the
list expander insert a Reply-To field pointing to the list
mailbox if and only if there is no (author-provided) Reply-To
field in the message.  It doesn't require umpteen different
fields which modify the semantics of other fields or which
modify the behavior of the *recipient's* UA.  Some list
expanders do insert Reply-To fields; the contentious issue
seems to be ignoring the "if and only if" part that effectively
causes such list expanders to override individual preference.

Date: Sat, 4 Sep 2004 20:46:23 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

On Fri, 3 Sep 2004, Keith Moore wrote:

> maybe there's no substitute for thinking?

Agreed. Pity thinking is in such short supply... :-)

Regards,
Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 04 Sep 2004 11:47:37 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> You are mistaken on both points: the URL above is a rant page
> specifically about the non-standard "mail-followup-to" field.  And I
> have not sent Bernstein copies of mailing list mail, as you could easily
> have determined from the mailing list copy; the message was sent *to*
> Bernstein with a *copy* to the list.  And that is exactly what would be
> expected from a response to a message (his) which contained no Reply-To
> field indicating that responses should go anywhere but to him (with
> reply-all copying the list).  As specified for the semantics of Reply-To
> and responses in RFC 724 [sect II.C.. paragraph 3)], RFC 733 [IV.A.2.c],
> RFC 822 [4.4.3], RFC 2822 [3.6.2], and RFC 3834 [sections 3.1.2 and 4].
> None of which mention "Mail-Followup-To".

I couldn't have possibly come up with a better illustration of my point.
Thank you!

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 04 Sep 2004 13:57:37 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Russ Allbery <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Russ Allbery wrote:
> Bruce Lilly <[email-masked]> writes:
> 
> 
>>It is harmful because it results in an increase in spam; e.g.:
> 
> 
>>"Hi. This is the qmail-send program at cr.yp.to.
>>I'm afraid I wasn't able to deliver your message to the following addresses.
>>This is a permanent error; I've given up. Sorry it didn't work out.
> 
> 
>><djb-internal/[email-masked]>:
>>See http://cr.yp.to/docs/copies.html.
> 
> 
> That has nothing to do with MFT and everything to do with Dan Bernstein
> not being interested in you sending him copies of mailing list mail.

You are mistaken on both points: the URL above is a rant page specifically
about the non-standard "mail-followup-to" field.  And I have not sent
Bernstein copies of mailing list mail, as you could easily have determined
from the mailing list copy; the message was sent *to* Bernstein with a *copy*
to the list.  And that is exactly what would be expected from a response
to a message (his) which contained no Reply-To field indicating that
responses should go anywhere but to him (with reply-all copying the
list).  As specified for the semantics of Reply-To and responses in
RFC 724 [sect II.C.. paragraph 3)], RFC 733 [IV.A.2.c], RFC 822 [4.4.3],
RFC 2822 [3.6.2], and RFC 3834 [sections 3.1.2 and 4].  None of which
mention "Mail-Followup-To".

> That is, incidentally, something that you do on all the mailing lists that
> you're on, and it's incredibly obnoxious.  I haven't gotten to the point
> of bouncing your mail back to you yet, but I wish you'd quit it too.

Like many mailing list participants, I use a "reply-all" function to
send list responses unless there is a good reason to do otherwise, and
generally trimming extraneous recipients (typically recipients who had
been copied on earlier list messages, but for whom the response being
composed isn't necessarily relevant).  There are several typical cases
of mailing list messages that might be responded to:
1. Reply-To set to the list address, no To or Cc. This is typically
   how an author would indicate that responses should be sent to the
   list only.  In some cases, multiple addresses might be specified
   in the Reply-To field.
2. Reply-To not set, a single author's single mailbox in a From field,
   To or Cc set to a list mailbox  That indicates that the author
   wishes to receive responses (reply or reply-all) and that reply-all
   responses should copy the list address.
3. Reply-To set to the list address and one or more additional mailboxes
   specified in To and/or Cc fields. A "reply" response would go to the
   list only, whereas reply-all would go to the list and the additional
   mailboxes.  This typically arises due to a response to type 2 above,
   i.e. where the mailboxes in the type 3 message had been indicated in
   the earlier type 2 messages as requests for copies.
4. Reply-To not set, a single author's single mailbox in a From field,
   list mailbox in either To or Cc, and additional mailboxes specified
   in To and/or Cc.  This may occur as a response to a type 2 message
   where the respondent wishes to have responses to his list message
   sent to him, with reply-all responses sent to him, to the list, and
   to the additional mailboxes specified.
5+. In the case of multiple authors, a Sender field is necessary regardless
   of To/Cc/Reply-To fields.  Because of different interpretations of
   the Sender field, it would be advisable for the authors to include a
   Reply-To field.  This is a very unusual situation; I have only seen
   it a few times.

If you are receiving direct responses as well as mailing list copies,
and you didn't intend that to be the result, you are probably sending
type 2 or type 4 messages when you probably should have been sending
type 1 or type 3 (i.e. you failed to include a Reply-To field indicating
that responses should be sent somewhere other than the mailbox in your From
field).

Responses to mailing lists aren't magical or mysterious; they are handled
in accordance with the specified semantics referenced above.  There is
really no viable alternative (at present, hence this thread). You seem to
want to be magically excluded from responses without simply specifying
(via Reply-To) where you want responses to go instead.  In theory,
It might have been possible in pre-spam days for a response composer to
a. find the MX host(s) for the mailing list mailbox
b. telnet to the MX hosts(s), issuing an EXPN SMTP command for the list
    mailbox
c. save the results
d. find the MX hosts for each specified message recipient
e. telnet to each MX host, again issuing EXPN SMTP commands, and again
   saving the results
f. recursively process the saved results, again issuing SMTP EXPN commands
   to appropriate MX hosts until no further expansions result
g. compare results of the expansions and eliminate recipients who would
   be included in the lists expansion, any subsequent additional expansions,
   aliasing, etc.
Nowadays, EXPN mostly doesn't work, so that can't be done.  Hopefully
you can see that it it impractical, even if it were possible.  At minimum,
the mailing list subscriber list might change between the time it is first
expanded and the time that the recipient list is edited. Ditto for any
intermediate expansions and aliasing.  There simply is no way for a list
recipient (who is not also a list maintainer) to determine who is and
who is not a list recipient. Specifically, I don't know which mailing lists
you receive at any given moment. And to address your assertion, you don't
know "all the mailing lists" that I am subscribed to at any moment. The
difference is that I don't expect you to know or to jump through hoops
in a futile attempt to find out.

Moreover, as has been recently stated in this discussion, at least one
mailing list recipient who sends type 2 messages *does* expect responses
sent to him with copies to the list. Since that is precisely the expected
sort of response to a type 2 message, the only way *you* can expect
anybody else to know that *your* wishes are different is to so indicate,
preferably by using the standard, well-documented Reply-To field, which
has been available for that purpose for more than 27 years.

What is really obnoxious is the apparent expectation that every list
recipient will go through steps a-g above to suit senders who can't be
bothered to set the Reply-To field on their list messages if they don't
wish to receive responses. That isn't going to happen and shouldn't be
expected -- clearly this is another case where some user education is
needed.

And to return to the topic at hand, the sort of magic that you seem to
expect won't happen (i.e. the From mailbox will still receive responses
in the absence of a Reply-To field) even *with* Keith's proposed noReply
fields.

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 04 Sep 2004 11:22:05 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> These days for many mailing lists, this isn't even feasible - the list
> will filter traffic from non-subscribers.  The list might or might not
> get so much spam that manual approval of the non-subscriber traffic is
> feasible.  And whether the sender wants a copy of replies depends
> heavily on the nature of the list.

Be careful not to focus too much on the public Internet case here.  The
number of public mailing lists that I'm on that allow mail from
non-subscribers has been steadily dropping, but the *total* number of
mailing lists that I'm on that allow mail from non-subscribers has been
increasing and I expect will continue to increase.

Mail internal to organizations doesn't have the spam problem, but can use
the same tools.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 04 Sep 2004 11:19:04 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> - to me, whether you want personal copies on a reply to a list seems
>   like a sender preference rather than a list preference.  it depends
>   on how much mail you get, how you process mail, etc.

Although one thing that has to factor into this is whether the person is
on the mailing list at all.  I always want personal copies of mail to
lists that I'm not on, for instance.

>   for me, it's obvious that I do want separate copies, because I have
>   all of my list mail sent to sub-folders, and I like to arrange things
>   so that my inbox has a history of all of my correspondence and the
>   replies to my correspondence, while my list folders are complete
>   archives of the list.  but I can certainly imagine how someone with a
>   single mail folder would not want to see duplicates.

Of course, part of the problem is that it's obvious to you, but not
obvious to anyone corresponding with you.  One could jump to the
conclusion that you do because you send them, but that frequently isn't
the case; there are people who send them and don't want them (usually
people who don't understand mail very well).

I've overridden the default in my mail client for this message so that
you'll get a copy, but I don't currently have any way of configuring this
per-recipient.

I'm not sure whether you're right that personal copies are always a sender
preference.  You may be.  I can't think of a good counter-argument right
now.  (Whether replies should go *only* to the individual or also to the
list is often a list preference, however.)

Incidentally, it's not just a question of single folder vs. multiple
folders.  I keep all list traffic in one folder and personal mail in
another folder, and if someone sent the mail to the list, I don't want it
to show up in my personal folder.  I therefore encounter two problems:
there is no *good* way to file personal responses into the list folder
because they don't have List-Id headers or other similar filter fodder
(basing it off of the To and Cc lines is unreliable and defeats the whole
purpose of the List-Id header), and even if I do manage to do that, I now
have useless duplicate messages in the list folder.

This is definitely where the personal preference aspect comes in.  I can
see why you want your mail to work the way that you do, but I treat
mailing lists equivalently to newsgroups, completely with scoring rules to
score up replies to my own messages, and the personal copies are outside
of that system and don't contribute to it.  It's just more mail I have to
delete.

> - a separate issue is whether an address continues to get copied
>   on subsequent replies.  (A sends a message to the list, B
>   replies with a message To A and CC the list, C replies to B's
>   message, CC'ing A and the list.  A gets CC'ed on subsequent
>   messages in that thread).  *that* might well be a list preference.

Good point.  It would indeed be better to deal with that as a separate
issue, since that's where most of the complaints come from that I see.
The quantity of mail is larger if Cc's keep being preserved, so while
people are willing to delete one message, they get annoyed by deleting
multiple messages.

> - different communities do have different ideas on the best way
>   to handle these issues.   often this is  a reflection of
>   the technical sophistication of each community and the kinds of
>   tools they tend to use.   at other times it's a reflection of
>   the kinds of conversations those communities want to have. 

In my experience it really is more the latter than the former.  Much is
made in this debate of how one side or the other believes what they do
because they don't understand how mail works, but that hasn't been my
experience.  Sure, many people aren't sophisticated with all of the
nuances of headers, but my users often want Reply-To set to point to the
mailing list not because they don't understand the problems with that, but
because they do see the problems, consider them unlikely or unimportant,
and care more about getting replies to go to the right place.

>   I don't necessarily think it's useful or appropriate for technical
>   standards to accommodate everybody's different ways of dealing with a
>   problem. I think the technical standards need to define a small number
>   of ways to deal with the problem (ideally one way) and try to make
>   sure that that way will work for the diverse sets of users out there.

That being said, I think any solution to the list reply problem that
doesn't deal with list preference for personal replies, list preference
for replies back to the list, personal preference for copies of list
replies, and personal preference for no copies of list replies, plus still
copying people who aren't on the list, is insufficient to the task.

>>  * Is the user a member of the mailing list to which they sent the mail?
>>    MFT lets the user express this indirectly by answering the related but
>>    not identical question "do you want copies of responses on the list,"

> I see the questions as orthogonal.  But I imagine it could help a
> recipient decide whether to trim a particular address from a Cc list.

I think this is a pretty significant issue.  Even with mailing lists that
are very strongly opposed to personal copies of e-mail, people want to
send personal copies if the person isn't on the list.  Admittedly, the
number of lists in the Internet in general that allow one to mail them
without being a member is dropping steadily, but there are many other uses
of mailing-list-like systems (such as role addresses or internal
discussion lists in organizations) that don't have that problem.

> and even assuming that list culture has a genuine interest here, how to
> deal with the conflict between individual user preference and list
> preference?

I would say that individual preference would always override.  But then,
I'm a Usenet person.  That's what we implemented on Usenet, and it works
pretty well.

For all that mail and news are different, I would argue that the ideal
mailing list semantics are remarkably similar to Usenet, with perhaps some
more configuration on the mailing list side.  People on Usenet can request
personal copies of postings with Mail-Copies-To, by default replies go to
the newsgroups, and a poster can indicate that replies should just go to
them personally with Followup-To: poster.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 4 Sep 2004 13:36:57 -0400
From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> > MFT turns this into a function defined by the sender of the message -
> 
> That's a content-free statement. 

no, it's a value-free statement.

> Are you next going to argue that Date
> displays don't work because Date is ``defined by the sender''?

I presume that Date is the date at which the sender _thinks_ he sent the
message :)

But a Date that is set by the sender doesn't change the recipient's user 
interface (though it might affect the recipient's interpretation of the
message).
 
> What I'm saying is that, when both MUAs fully support Mail-Followup-To,
> the behavior that's by far _most commonly desired_ in each situation is
> also the _default_:

You are assuming that everybody wants to use MFT for the same purpose,
and in the same way.  You want to optimize the default behavior for a
single case - one that may be commonly desired (especially among 
heavy list users) but which doesn't solve other problems related to
reply.

>    * When someone joins a mailing list and then sends a message to it,
>      he _usually_ doesn't want a copy of the followups. 

Not clear, especially in the long term.  Subaddresses and other means of
automatically filing messages into folders are getting more popular all the
time.  In one list of nontechnical people that I particpate in, about half of
the participants want personal copies of replies to list traffic.  A couple
of years ago that figure was around 10%.

>    * When someone sends a message to a mailing list without joining it,
>      he _usually_ wants a copy of the followups. 

These days for many mailing lists, this isn't even feasible - the list 
will filter traffic from non-subscribers.  The list might or might not
get so much spam that manual approval of the non-subscriber traffic
is feasible.  And whether the sender wants a copy of replies depends
heavily on the nature of the list.
 
>    * When someone wants an extra copy of the followups to his message,
>      he usually also wants an extra copy of the second-level followups,
>      third-level followups, etc.

strongly disagree here.  my experience is just the opposite.
 
>    * When someone sends a message to several mailing lists, he _usually_
>      wants the followups to go to all of the lists (and him if he isn't
>      on any of them).

not at all clear.

It's one thing if a user says to his MUA "when I send mail to lists X, Y, and
Z, please arrange things so that when someone replies to the list, I don't
get copied on that reply."  It's quite another thing to try to arrange things
so that lists work this way by default.

Keith

Date: 4 Sep 2004 16:28:38 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> MFT turns this into a function defined by the sender of the message -

That's a content-free statement. Are you next going to argue that Date
displays don't work because Date is ``defined by the sender''?

What I'm saying is that, when both MUAs fully support Mail-Followup-To,
the behavior that's by far _most commonly desired_ in each situation is
also the _default_:

   * When someone joins a mailing list and then sends a message to it,
     he _usually_ doesn't want a copy of the followups. In the
     Mail-Followup-To world, _by default_, he doesn't get a copy.

   * When someone sends a message to a mailing list without joining it,
     he _usually_ wants a copy of the followups. In the Mail-Followup-To
     world, _by default_, he gets a copy.

   * When someone wants an extra copy of the followups to his message,
     he usually also wants an extra copy of the second-level followups,
     third-level followups, etc. In the Mail-Followup-To world, _by
     default_, this is what happens.

   * When someone sends a message to several mailing lists, he _usually_
     wants the followups to go to all of the lists (and him if he isn't
     on any of them). In the Mail-Followup-To world, _by default_, the
     followups go to all of the lists.

Everything can be overridden by the recipient. Everything can be
overridden by the sender. But this manual work is drastically reduced
when we get the defaults right.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Sat, 4 Sep 2004 10:06:05 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> I only know a few mailing lists where personal copies are actively
> encouraged as part of the culture, and in one of those they're still
> supposed to be selective (including only the people who have action items
> in the mail being sent). 

I'd like to dig down a bit here:

- to me, whether you want personal copies on a reply to a list seems
  like a sender preference rather than a list preference.  it depends
  on how much mail you get, how you process mail, etc.  for me, it's
  obvious that I do want separate copies, because I have all of my
  list mail sent to sub-folders, and I like to arrange things so that
  my inbox has a history of all of my correspondence and the replies
  to my correspondence, while my list folders are complete archives
  of the list.  but I can certainly imagine how someone with a single
  mail folder would not want to see duplicates.

- a separate issue is whether an address continues to get copied
  on subsequent replies.  (A sends a message to the list, B
  replies with a message To A and CC the list, C replies to B's
  message, CC'ing A and the list.  A gets CC'ed on subsequent
  messages in that thread).  *that* might well be a list preference.

- different communities do have different ideas on the best way
  to handle these issues.   often this is  a reflection of
  the technical sophistication of each community and the kinds of
  tools they tend to use.   at other times it's a reflection of
  the kinds of conversations those communities want to have. 

  I don't necessarily think it's useful or appropriate for technical
  standards to accommodate everybody's different ways of dealing with a
  problem. I think the technical standards need to define a small number of
  ways to deal with the  problem (ideally one way) and try to make sure that
  that way will work for the diverse sets of users out there.

FWIW: A nearly sure-fire way to get an argument started about how replies
should work is to send a provocative message to a large and diverse
list of recipients.  Somebody is certain to reply, and it's likely
someone will reply to that.  Sooner or later someone else will get
annoyed at being cc'ed on the replies, and complain about it - often
suggesting that someone else _should_ have set reply-to, trimmed the
cc list, bcc'ed other recipients, or simply not replied at all.

> There are more pieces missing than just a header like MFT, I think.  At
> the least, I think we need some way of representing the following:
> 
>  * Is the user a member of the mailing list to which they sent the mail?
>    MFT lets the user express this indirectly by answering the related but
>    not identical question "do you want copies of responses on the list,"

I see the questions as orthogonal.  But I imagine it could help a
recipient decide whether to trim a particular address from a
Cc list.

>  * Should replies to list postings *generally* go only to the list or to
>    the list and the user, as a matter of list culture? 

or for that matter, just to the user.

and even assuming that list culture has a genuine interest here, how
to deal with the conflict between individual user preference and 
list preference?

Keith

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Erroneous content-type: Text/plain; charset=us-ascii
Date: Sat, 04 Sep 2004 10:56:46 +0200
Lines: 32
Cancel-Lock: sha1:I2lXEngYejhpriYcA3vWBN9JNvo=
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> I have always had the opinion that a good standard should
> never contain the word "undefined". The word "undefined"
> indicates that something is incomplete in the standard. And
> when something is incomplete, different implementors will
> do different things, and then interoperability will suffer.

I tend to agree in general, but I'm not sure this situation can be
counted as an "undefined" situation.  The situation with bogus charset
is clearly in violation with the specification.  What is undefined is
the error handling of this protocol violation.  However, I believe
error handling of protocol violations is not within the scope of a
protocol to define.  If a protocol isn't followed, it doesn't make
sense that the protocol has any say on what should or should not be
done.  I believe it is best for a specification to describe how
conforming implementation should behave, and leave it at that.

However, perhaps your ideas could be formulated as a Best Current
Practice or similar, instead of adding them to the specification.

Btw, the error handling approach that Cyrus IMAPD implement for bogus
charset's, and which I like, is to simply (within charset=us-ascii
messages) replace all non-ASCII characters with 'X'.  This is better
than bouncing the mail (which Cyrus IMAPD used to do), but still make
it clear to the user that some application is misbehaving.  Modifying
the charset into charset=iso-8859-1 would be correct for 95 % of my
non-spam mail, but it would also hide the problem.

Thanks,
Simon

Date: Sat, 4 Sep 2004 08:52:09 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: RE: Erroneous content-type: Text/plain; charset=us-ascii
Sender: [email-masked]

At 20.05 +0100 04-09-03, Nick Ing-Simmons wrote:
>Based on what I see that wouldn't help. My charset for sending mail
>is iso-8859-15 (or these days UTF-8). But mis-labeled mail
>used to be mostly chinese, with a recent trend for russian.
>(Most, but not quite all, mis-labeled mail is SPAM.)
>What my mail tool does at present wasn't deliberate but a
>feature of way perl's Encode module works - given something
>claiming to be ASCII but having high-bit chars I get them as
>replacement characters - this flags that there is a problem
>clearly enough!

That sounds like a reasonable solution, too. But a good
mailer should perhaps, in that case, allow the recipient to
modify the charset of the received body parts, in order to
make them readable.

This is maybe not a standards issue, although I think IETF
could help the implementors by giving some advice also on
this case.

I have always had the opinion that a good standard should
never contain the word "undefined". The word "undefined"
indicates that something is incomplete in the standard. And
when something is incomplete, different implementors will
do different things, and then interoperability will suffer.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 03 Sep 2004 22:59:49 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> Exactly.  The frequently requested behavior from practically everyone
>> on the USEFOR list is for people to send mail only to the list when
>> responding in public, and yet Bruce insists on sending a private copy
>> and then tells people to set Reply-To or filter out duplicate mail.

> I'm not sure that the USEFOR list counts as "broad support from the
> technical community".

Heh.  Touche'.

> but the point that different groups have different expectations is
> certainly one that we should keep in mind.

Right, that was my real point, rather than chastizing Bruce (although
interpreting djb's bounce as something related to MFT was a rather
unsupportable leap).  This is a huge issue with mailing lists, to the
degree that every list I've ever been on has, at one point or another, had
the Reply-To fight, and there is no configuration that makes everyone
happy, or even not unhappy.

We all know the problems with setting Reply-To, particularly trampling the
user's own Reply-To, but also making it quite hard to reply to the
individual in many mail clients and resulting in other mail clients
routinely ignoring Reply-To (*ahem* Pine *ahem*) on personal replies.
(The last is so bad that when answering role address mail these days, I
don't even bother with Reply-To any more; I just change my From header to
be the role address.  This isn't as "honest," but without this, I
constantly get personal replies to mail that should go back to the role
address.)  The flipside is that in some lists I routinely get responses
that belong on the list in personal e-mail because people just assume that
Reply-To is set on all mailing lists.  Both of these are broken, and this
isn't going to get fixed by changing people.

I only know a few mailing lists where personal copies are actively
encouraged as part of the culture, and in one of those they're still
supposed to be selective (including only the people who have action items
in the mail being sent).  There are a lot of lists where people tolerate
it, and a majority of lists (again in my personal experience) where
personal copies are disliked, either mildly or strongly.  Right now, there
is no way of representing that information usefully either in the list
configuration or by individual subscribers other than the huge Reply-To
hammer.

There are more pieces missing than just a header like MFT, I think.  At
the least, I think we need some way of representing the following:

 * Is the user a member of the mailing list to which they sent the mail?
   MFT lets the user express this indirectly by answering the related but
   not identical question "do you want copies of responses on the list,"
   but that actual question is useful in other situations (it comes up for
   me *all the time* in internal work mailing lists where most people are
   not using MFT-aware clients and I can't remember which people are on
   which team list, and it's caused miscommunication problems at least
   once in the recent past).

   The mailing list manager can answer this question itself in some
   circumstances (skipping the problem of people subscribed under
   different addresses than they send mail, which is uncommon in the
   situations where I see this the most, but which is a tricky problem
   when it happens).  However, it doesn't really have anywhere to *put*
   that information for the use of MUAs.

 * Should replies to list postings *generally* go only to the list or to
   the list and the user, as a matter of list culture?  One of the
   problems with MFT is that each individual has to use it, and many
   individuals just don't or can't easily because they don't have the
   right MUA.  Another problem is that this really does vary by list
   culture and it makes a lot of sense in some situations to set a
   default.  It would be nice to have a List-* header that could express
   this default and use that in the absence of a user-specific preference.

 * Does the individual user want copies of list postings?  This is what
   MFT expresses clearly when used fully, and it deals with such issues as
   "crossposts" between multiple mailing lists.  This should probably
   override the list default in nearly all cases, if expressed.

I'd love to see something that solves this problem, since it causes a lot
of overhead, misunderstandings, and ruffled feathers right now.  I don't
think the To-No-Reply proposal really does anything to help with it,
although it may well solve a *different* problem.  MFT goes part of the
way, but I'm personally dubious that MFT will ever get much more traction
than it has right now because of the amount of client-side configuration
it requires, and it doesn't quite get the first two things above.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 4 Sep 2004 01:21:42 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> > It's incredibly obnoxious for a small number of individuals, without
> > broad support from the technical community, to insist that everyone else
> > change their habits to suit the whims of those individuals.
> 
> Exactly.  The frequently requested behavior from practically everyone on
> the USEFOR list is for people to send mail only to the list when
> responding in public, and yet Bruce insists on sending a private copy and
> then tells people to set Reply-To or filter out duplicate mail.

I'm not sure that the USEFOR list counts as "broad support from the
technical community".

> If other mailing lists have other community policies, that's great.  I
> realize there is no consistency in this area, but I think it's a matter of
> basic respect to try to follow the wishes of the communities in which one
> is interacting.

well, it might depend on how connected to reality that community is.

but the point that different groups have different expectations is 
certainly one that we should keep in mind.  

Keith

To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 03 Sep 2004 21:46:30 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> It's incredibly obnoxious for a small number of individuals, without
> broad support from the technical community, to insist that everyone else
> change their habits to suit the whims of those individuals.

Exactly.  The frequently requested behavior from practically everyone on
the USEFOR list is for people to send mail only to the list when
responding in public, and yet Bruce insists on sending a private copy and
then tells people to set Reply-To or filter out duplicate mail.

If other mailing lists have other community policies, that's great.  I
realize there is no consistency in this area, but I think it's a matter of
basic respect to try to follow the wishes of the communities in which one
is interacting.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 4 Sep 2004 00:26:32 -0400
From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> Some MUAs have a ``reply to list'' function that sends a message to the
> List-Post address, or to an address configured for this mailbox. But
> this is not exactly the desired function. (Example 1: sender not on the
> list. Example 2: crossposts.)
> 
> Every popular MUA has a ``reply to all''/``follow up''/etc. function.
> Mail-Followup-To turns this into exactly the desired function, removing
> the demand for ``reply to list.''

No, MFT turns this into a function defined by the sender of the message -
which may or may not be the "exactly the desired function" for the recipient.

> I see no evidence of independent user interest in ``reply to list.''

I've seen a little bit of interest.  After all, some lists are less likely
to have cross posts than others.  I think of it as useful but only marginally so.

Keith

Date: Sat, 4 Sep 2004 00:23:29 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> > I haven't seen any
> > arguments that MFT is harmful
> 
> It is harmful because it results in an increase in spam; e.g.:
> 
> "Hi. This is the qmail-send program at cr.yp.to.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
> 
> <djb-internal/[email-masked]>:
> See http://cr.yp.to/docs/copies.html.

If an MFT spec were adopted, I can't imagine that it would recommend such
behavior.  It might even discourage such behavior.

I think MFT is sub-optimal because it is difficult for ordinary users to
use, because it can be confusing for recipients, and because it has to
be widely deployed in recipients' MUAs before it becomes generally 
useful.  

That, and fundamentally, letting the sender of a message specify  "reply
to author means x, reply all means y" for a recipient just seems wrong to me.
Reply to author means send a reply to the person who wrote the message.
Reply to all means send a reply to everyone who received that message.
If those buttons don't do something fairly close to what they say they do, 
and if the UA doesn't make it clear when it's doing something slightly
different than what the recipient asked it to do, the UA is terribly broken.

Keith

Date: 4 Sep 2004 04:22:30 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Keith Moore writes:
> That's not in itself an argument against MFT - just an argument against
> the notion that MFT provides a reliable "reply to list" feature.

Some MUAs have a ``reply to list'' function that sends a message to the
List-Post address, or to an address configured for this mailbox. But
this is not exactly the desired function. (Example 1: sender not on the
list. Example 2: crossposts.)

Every popular MUA has a ``reply to all''/``follow up''/etc. function.
Mail-Followup-To turns this into exactly the desired function, removing
the demand for ``reply to list.''

Of course, without Mail-Followup-To, the ``reply to all''/etc. function
isn't exactly the desired function. (Example: sender on the list.)
That's why some MUAs introduced the ``reply to list'' function---it
failed less frequently than ``reply to all'' before Mail-Followup-To.

I see no evidence of independent user interest in ``reply to list.''
Users think of it the same way as ``reply to all''---except that it has
a different set of failure modes. Increased use of Mail-Followup-To has
reduced the number of ``reply to all'' failures, and universal use would
eliminate all of the failures; in contrast, there are no proposals to
reduce the number of ``reply to list'' failures.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Sat, 4 Sep 2004 00:13:34 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> > "Hi. This is the qmail-send program at cr.yp.to.
> > I'm afraid I wasn't able to deliver your message to the following
> > addresses. This is a permanent error; I've given up. Sorry it didn't work
> > out.
> 
> > <djb-internal/[email-masked]>:
> > See http://cr.yp.to/docs/copies.html.
> 
> That has nothing to do with MFT and everything to do with Dan Bernstein
> not being interested in you sending him copies of mailing list mail.
> 
> That is, incidentally, something that you do on all the mailing lists that
> you're on, and it's incredibly obnoxious.  I haven't gotten to the point
> of bouncing your mail back to you yet, but I wish you'd quit it too.

It's incredibly obnoxious for a small number of individuals, without
broad support from the technical community, to insist that everyone else
change their habits to suit the whims of those individuals.

Keith

Date: Fri, 3 Sep 2004 23:49:51 -0400
From: Keith Moore <[email-masked]>
To: Philip Hazel <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

> > > I'm sure that in many users' minds a newsgroup is just another kind
> > > of mailing list.
> > > 
> > > The conclusion seems fairly obvious...
> > 
> > perhaps to you.  I can find two fairly obvious, but contradictory,
> > conclusions:
> > 
> > 1. people are confused by the apparent similarity, so we'd serve people
> > better by trying to make the differences more apparent
> > 
> > 2. people want to treat the two as identical, so we should try to make
> > them work as similarly as possible
> 
> My conclusion is number 2. 
> 
> > actually I don't believe that "users don't perceive much (any?) difference
> > between mail and news."  
> 
> Well, I did say "many users" rather than "users". In the absence of any
> hard data, I can't contradict you with facts, but I'm afraid I still
> think many non-technical users will be of that mind.

I think email and usenet are going to work differently no matter what, 
and in fact we find those differences useful.  After all, email (and
email lists) already existed when usenet was created.  Usenet was created,
and became popular, because it worked better for some purposes than
email. 

> > people figure out very quickly that there are differences in privacy,
> > style, and other social norms between the two media.  
> 
> There are great difference in social norms between different mailing
> lists and different newsgroups. I don't think the medium makes much
> difference.

I think the medium has an effect, because some kinds of discussions
work better in one than the other.  People choose to participate
in one or the other based on how well it works for them.

> > they may get annoyed when either system doesn't support the
> > functionality that they need - but this isn't an argument for making
> > the two systems the same.
> 
> What is the main argument for keeping them different? At the UA level,
> of course. I don't mean under the hood.

They're going to work differently.  Do users want an effective interface
to each, or do they want a less effective interface for the sake of
consistency?  (or does it depend on the user?)

> After all, we use the same
> controls to drive a vehicle, whether it has a petrol (gasoline), diesel,
> or hybrid electric engine.

a better analogy would be that controls are somewhat different on an
automobile, a bus, a large truck, and a forklift - because each of these
serves different purposes and needs somewhat different controls.

(the engine analogy applies if you're comparing, say, email-over-SMTP
vs. email over UUCP)

> Personally, I would love to have a keystroke in my MUA that did 
> reply-to-all for non-mailing list messages, and reply to some specified 
> list, if present, for mailing list messages. I would then train my 
> fingers to use it instead of the "reply-to-all and then think whether
> you need to trim the recipients" that I currently use - often forgetting
> the trimming bit.

and then you'd fragment cross-posted discussions, probably without
realizing it.   maybe there's no substitute for thinking?

Keith

To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 03 Sep 2004 16:15:33 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> It is harmful because it results in an increase in spam; e.g.:

> "Hi. This is the qmail-send program at cr.yp.to.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.

> <djb-internal/[email-masked]>:
> See http://cr.yp.to/docs/copies.html.

That has nothing to do with MFT and everything to do with Dan Bernstein
not being interested in you sending him copies of mailing list mail.

That is, incidentally, something that you do on all the mailing lists that
you're on, and it's incredibly obnoxious.  I haven't gotten to the point
of bouncing your mail back to you yet, but I wish you'd quit it too.

(How relevant for this thread!)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 03 Sep 2004 18:52:12 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

Simon Josefsson wrote:

> I haven't seen any
> arguments that MFT is harmful

It is harmful because it results in an increase in spam; e.g.:

"Hi. This is the qmail-send program at cr.yp.to.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<djb-internal/[email-masked]>:
See http://cr.yp.to/docs/copies.html.

--- Below this line is a copy of the message."

Date: Fri, 03 Sep 2004 16:01:18 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: Mail agents and definitions (Was Re: The Bcc Issue)
Sender: [email-masked]

Hi Bruce,

--On Friday, September 3, 2004 7:57 AM -0400 Bruce Lilly <[email-masked]> 
wrote:

> Question: Is there an RFC where these terms as used here are defined?
> I couldn't find one (in particular, the only reference to "MDA" that
> I was able to find was in RFC 3528, which has nothing to do with this
> topic).

<http://www.ietf.org/internet-drafts/draft-crocker-email-arch-01.txt>

That is a work in progress - obviously.

-- 
Cyrus Daboo

Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: RE: Erroneous content-type: Text/plain; charset=us-ascii
To: [email-masked]
Date: Fri, 03 Sep 2004 20:05:49 +0100
From: Nick Ing-Simmons <[email-masked]>
Reply-To: Nick Ing-Simmons <[email-masked]>
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:
>At 08.16 -0500 04-09-02, Vaudreuil, Greg M (Greg) wrote:
>>I assume you get predominately 8859-1 mislabled as US-ASCII based on the fact you predominantely communicate with folks in a Western European language.  I bet someone using say Cyrilc would have a predominant error condidition of a different 8859 varient mis-labled as US-ASCII.
>>
>>Why would we assume the broken mailers would any more ensure that characters are in 8859-1 than they would ensure that what is labled is correct?   What if the standard, or IETF in a BCP, says "treat this error as X" and a mailer used in a different region made a different error?
>
>My idea was to either have a setting for which charset
>to assume in this case, or derive a setting from other
>settings, such as the language or charset the person
>has as default when sending mail.

Based on what I see that wouldn't help. My charset for sending mail
is iso-8859-15 (or these days UTF-8). But mis-labeled mail 
used to be mostly chinese, with a recent trend for russian.
(Most, but not quite all, mis-labeled mail is SPAM.)
What my mail tool does at present wasn't deliberate but a 
feature of way perl's Encode module works - given something 
claiming to be ASCII but having high-bit chars I get them as 
replacement characters - this flags that there is a problem 
clearly enough!

Date: Fri, 03 Sep 2004 07:57:57 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Philip Hazel <[email-masked]>
CC: [email-masked]
Subject: Mail agents and definitions (Was Re: The Bcc Issue)
Sender: [email-masked]

Philip Hazel wrote:
> 
> Summary of the Bcc discussion: posted to exim-users, exim-dev, & ietf-822
> 
> There were a few responses on the exim-users mailing list. There was a
> longer discussion on the ietf-822 mailing list,
[...]
> 2. Other discussion
> 
> Some interesting points of clarification came up in the discussion. The
> functions of mail handling are now seen as split into four distinct
> parts, as follows:
> 
>   MUA -> MSA -> MTA -> MDA -> MUA
> 
> (user agent, submission agent, transfer agent, delivery agent).

Question: Is there an RFC where these terms as used here are defined?
I couldn't find one (in particular, the only reference to "MDA" that
I was able to find was in RFC 3528, which has nothing to do with this
topic).

Aside: I am aware of diagrams in RFCs 2821 and 3464, but they only
show part of the chain; 2821 deals only with SMTP client/server with
no distinction among MSA/MTA/MDA, and 3464 deals only with "MTA"s. I
am also aware of Patrik Faltstrom's "mailflows" diagram, but again
that simply refers to everything as "MTA".

Additions: Typically there is a message store of some sort into which
the MDA places messages.  There may also be a message access server
(MAS) between that message store and the recipient MUA. The MAS is
typically a POP variant or IMAP server.  And of course gateways to/
from non-SMTP/POP/IMAP mail exist.

To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 03 Sep 2004 10:36:04 -0700
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:
> Keith Moore <[email-masked]> writes:

>> That's not in itself an argument against MFT - just an argument against
>> the notion that MFT provides a reliable "reply to list" feature.

> Right.  Thinking of MFT as a "reply to list" feature is misleading.

Valid point.  I apologize for the introduced confusion.

MFT is the "reply to list" feature that I actually *want* -- I can't
imagine a circumstance in which I'd want the version of "reply to list"
that excludes users who explicitly want copies of the thread.  For that
exceptionally rare situation, I'd delete those addresses manually.  But
you're correct that it's not quite a "reply to list" as Charles was
describing it.

> If MFT help some people, and (of course) do not harm others, it is
> useful.  I haven't seen any arguments that MFT is harmful, only that it
> might not be useful enough or that it has bad legacy behavior.  Which
> are much weaker arguments.

Yeah, exactly.

> Populating MFT automatically based on what is gleaned from List-Post is
> just a bad idea though.

Please note that having a smart MUA figure this out for you doesn't mean
it needs to be on full automatic.  Gnus already has some support for doing
this sort of thing at the prompting of the user.

Ideally, MUAs should know how to subscribe to mailing lists for you so
that they can track your subscription, keep track of changes to the
submission address (as long as List-Id doesn't change), keep track of how
to unsubscribe (from List-* headers) so that you can do so at the click of
a button, and in the process keep MFT working for you if you want.  I've
not seen one that does this yet, but I can easily imagine a way of doing
it that would still be entirely under my control.

But then, I use Gnus, and am not the average mail user.  Most people seem
to limp along with something like Outlook without any filtering, folders,
or any of the features without which my mail would be unreadable.  So this
may just baffle them completely.

On the gripping hand, users who don't know how to use e-mail usually
aren't on the sheer quantity of mailing lists that make these sorts of
things useful, don't deal with the edge cases that annoy the rest of us,
and are usually fairly happy with Reply-To set to the list (in my
experience running mailing lists for the last ten years).

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 3 Sep 2004 11:32:47 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: RE: Erroneous content-type: Text/plain; charset=us-ascii
Sender: [email-masked]

At 08.16 -0500 04-09-02, Vaudreuil, Greg M (Greg) wrote:
>I assume you get predominately 8859-1 mislabled as US-ASCII based on the fact you predominantely communicate with folks in a Western European language.  I bet someone using say Cyrilc would have a predominant error condidition of a different 8859 varient mis-labled as US-ASCII.
>
>Why would we assume the broken mailers would any more ensure that characters are in 8859-1 than they would ensure that what is labled is correct?   What if the standard, or IETF in a BCP, says "treat this error as X" and a mailer used in a different region made a different error?

My idea was to either have a setting for which charset
to assume in this case, or derive a setting from other
settings, such as the language or charset the person
has as default when sending mail.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Fri, 3 Sep 2004 09:39:46 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

On Thu, 2 Sep 2004, Keith Moore wrote:

> > I'm sure that in many users' minds a newsgroup is just another kind
> > of mailing list.
> > 
> > The conclusion seems fairly obvious...
> 
> perhaps to you.  I can find two fairly obvious, but contradictory,
> conclusions:
> 
> 1. people are confused by the apparent similarity, so we'd serve people
> better by trying to make the differences more apparent
> 
> 2. people want to treat the two as identical, so we should try to make
> them work as similarly as possible

My conclusion is number 2. 

> actually I don't believe that "users don't perceive much (any?) difference
> between mail and news."  

Well, I did say "many users" rather than "users". In the absence of any
hard data, I can't contradict you with facts, but I'm afraid I still
think many non-technical users will be of that mind.

Consider the totally non-computerate person (and there are still plenty 
of those about). Somebody shows them how to turn on a pc and how to fire 
up a browser and how to use it for email. I personally know several 
people who do just that, and only that. (Well, maybe a bit of surfing as 
well.) They may learn how to subscribe to mailing lists and that if they 
do, the messages arrive in their inbox. Then somebody shows them how to 
subscribe to a newsgroup - it's just like a mailing list except that the
messages don't fill up your inbox; they are kept in a kind of public
inbox. But you process them using the same UA in the same kind of way. I
think this is where the pressure is coming for MFT in mail to be "the
same as in news".

> people figure out very quickly that there are differences in privacy,
> style, and other social norms between the two media.  

There are great difference in social norms between different mailing
lists and different newsgroups. I don't think the medium makes much
difference.

> they may get annoyed when either system doesn't support the
> functionality that they need - but this isn't an argument for making
> the two systems the same.

What is the main argument for keeping them different? At the UA level,
of course. I don't mean under the hood. After all, we use the same
controls to drive a vehicle, whether it has a petrol (gasoline), diesel,
or hybrid electric engine. (Actually, I do seem to recall that in my
youth, you had to do something different to start and stop a diesel
engine, but that has long changed.)

Personally, I would love to have a keystroke in my MUA that did 
reply-to-all for non-mailing list messages, and reply to some specified 
list, if present, for mailing list messages. I would then train my 
fingers to use it instead of the "reply-to-all and then think whether
you need to trim the recipients" that I currently use - often forgetting
the trimming bit.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Fri, 03 Sep 2004 10:12:09 +0200
Lines: 81
Cancel-Lock: sha1:GPBjqrpJy8vzfk+1wHit+ALJPow=
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> > Yes, that is a Good Question. Ideally, the Reply-To-List command should
>> > reply to every list to which the message was sent. The problem is how
>> > does it know this?
>>
>> To beat Dan's drum for him, in a world that fully implements it,
>> Mail-Followup-To solves this problem.
>
> Only if authors use MFT only for a very narrow purpose - to distinguish
> lists from ordinary addresses.   However, it's not the case that everyone
> wants to redirect "reply to all" to go to only lists.  Nor is it the 
> case that everyone would want to limit their use of MFT to this purpose.
> Treating "reply to MFT" as equivalent to "reply to lists" would overload
> MFT almost as badly as Reply-to is currently overloaded.

Right.  MFT isn't meant to contain only mailing lists address.  It is
intended to contain the followup address that users supply.  Often
this is mailing list addresses, but viewing MFT as a header for
mailing list address is incorrect.

Generally, it seems MFT is useful in those situations where the
recipient trust the sender reasonably well to let the sender specify
the default value of where the recipient should post his followups.

In other words, if a sender has gone through to trouble of specifying
a Mail-Followup-To -- which MUST NOT be added without the user
requesting it -- then the recipient pay back with the courtesy of
following the Mail-Followup-To (by default).

In communities with co-operative people this scheme appear to work.
It takes malice (or buggy software) to add an incorrect MFT.  I don't
recall seeing flame wars about people having "bad" MFTs.

> That's not in itself an argument against MFT - just an argument against
> the notion that MFT provides a reliable "reply to list" feature.

Right.  Thinking of MFT as a "reply to list" feature is misleading.

>> But when you have it set
>> up, it works well as advertised among people who all use supporting mail
>> clients (even if the other person hasn't taught their own mail client
>> about their mailing lists, it works for the first person).
>
> It's easy to define something that works well among a small group of
> like-minded people. The challenge is to make something that will work well for
> an extremely large and diverse user community.  It's unwise to assume
> that everyone will want to use a feature in the same way.

Well, mail doesn't work well in extremely large and diverse user
communities.  Spam and virii are killing mail for that use.  I don't
buy that because something isn't right for everyone, it should not be
done at all, if that was implied.  If MFT help some people, and (of
course) do not harm others, it is useful.  I haven't seen any
arguments that MFT is harmful, only that it might not be useful enough
or that it has bad legacy behavior.  Which are much weaker arguments.

>> I can imagine a smart MUA that would handle this for you by using the
>> List-* headers.
>
> I can imagine that also.  And the first thing I imagine is that it would
> have the same problem that Apple's MUA for MacOS X has.  It gets its
> idea of people's names from random message headers.  So if someone 
> sends me mail with a Cc to "Big Idiot <[email-masked]>"
> then any time after that when I try to type in "[email-masked]"
> the MUA will automatically fill in "Big Idiot" for me.  And so far I
> haven't found a way to stop it.
>
> No thank you.  I don't want MUAs trying to infer information about 
> addresses from random messages.  (and I don't see how else an MUA
> can automatically discover which addresses are associated with lists)

How about looking at List-Post: and using those addresses as mailing
list addresses?  The MUA should allow the user to override things, of
course.

Populating MFT automatically based on what is gleaned from List-Post
is just a bad idea though.

Thanks,
Simon

Date: Thu, 02 Sep 2004 20:53:32 -0700 (PDT)
From: [email-masked]
Subject: RE: Erroneous content-type: Text/plain; charset=us-ascii
To: Vaudreuil Greg M Greg <[email-masked]>
Cc: Jacob Palme <[email-masked]>, [email-masked], DSV KOM Development Group <[email-masked]>
Sender: [email-masked]

> I don't have a stomach for standardized error processing... and I doubt you
> could do this right anyway.  The right thing to do is to fix the offending
> mailers.  Doing the best they can in the face of brokeness is a good
> competitive differentiator for clients.

Exactly right.

> I assume you get predominately 8859-1 mislabled as US-ASCII based on the fact
> you predominantely communicate with folks in a Western European language.  I
> bet someone using say Cyrilc would have a predominant error condidition of a
> different 8859 varient mis-labled as US-ASCII.

You'd win the bet. We see this sort of thing all the time with many
different languages: Arabic in various entirely different charsets
labelled as US-ASCII, Japanese in various different charsets
labelled as US-ASCII, ISO-8859-1, or the wrong Japanese set, Chinese
labelled incorrectly.

In many cases knowing the likely language involved is a good enough clue that
software can guess the real charset with a fair degree of accuracy. But it
isn't perfect. And all bets are off if you don't know the likely language -
results of using language-guessing software have been mixed.

> Why would we assume the broken mailers would any more ensure that characters
> are in 8859-1 than they would ensure that what is labled is correct?   What if
> the standard, or IETF in a BCP, says "treat this error as X" and a mailer used
> in a different region made a different error?

Absolutely. We really don't want to go here.

				Ned

Date: Fri, 3 Sep 2004 01:08:49 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> > Yes, that is a Good Question. Ideally, the Reply-To-List command should
> > reply to every list to which the message was sent. The problem is how
> > does it know this?
> 
> To beat Dan's drum for him, in a world that fully implements it,
> Mail-Followup-To solves this problem. 

Only if authors use MFT only for a very narrow purpose - to distinguish
lists from ordinary addresses.   However, it's not the case that everyone
wants to redirect "reply to all" to go to only lists.  Nor is it the 
case that everyone would want to limit their use of MFT to this purpose.
Treating "reply to MFT" as equivalent to "reply to lists" would overload
MFT almost as badly as Reply-to is currently overloaded.

(there are other problems with using MFT in this way also - one being
that it requires you to configure _all_ of your mail clients to know
about mailing lists.  If you're like me you have one at home, one at 
work, one on your laptop, one on your PDF, and webmail to use in a pinch.)

That's not in itself an argument against MFT - just an argument against
the notion that MFT provides a reliable "reply to list" feature.

> But when you have it set
> up, it works well as advertised among people who all use supporting mail
> clients (even if the other person hasn't taught their own mail client
> about their mailing lists, it works for the first person).

It's easy to define something that works well among a small group of
like-minded people. The challenge is to make something that will work well for
an extremely large and diverse user community.  It's unwise to assume
that everyone will want to use a feature in the same way.

> I can imagine a smart MUA that would handle this for you by using the
> List-* headers.

I can imagine that also.  And the first thing I imagine is that it would
have the same problem that Apple's MUA for MacOS X has.  It gets its
idea of people's names from random message headers.  So if someone 
sends me mail with a Cc to "Big Idiot <[email-masked]>"
then any time after that when I try to type in "[email-masked]"
the MUA will automatically fill in "Big Idiot" for me.  And so far I
haven't found a way to stop it.

No thank you.  I don't want MUAs trying to infer information about 
addresses from random messages.  (and I don't see how else an MUA
can automatically discover which addresses are associated with lists)

Keith

To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 02 Sep 2004 20:37:24 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> Yes, that is a Good Question. Ideally, the Reply-To-List command should
> reply to every list to which the message was sent. The problem is how
> does it know this?

To beat Dan's drum for him, in a world that fully implements it,
Mail-Followup-To solves this problem.  It's pretty widely used on the
Debian mailing lists where most people use an MUA that supports it.

MFT is a bit annoying to set up, since you have to teach your mail client
about all of the mailing lists that you're subscribed to and keep that up
to date (which is several hundred in my case).  But when you have it set
up, it works well as advertised among people who all use supporting mail
clients (even if the other person hasn't taught their own mail client
about their mailing lists, it works for the first person).

I can imagine a smart MUA that would handle this for you by using the
List-* headers.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Xref: clerew local.mime:3489
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Thu, 2 Sep 2004 15:15:33 GMT
Lines: 26
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> I think the first thing you need is a third way of replying -
>> "Reply-To-List" which, as Bruce had told us, some MUAs already provide.

>not that I entirely dismiss this idea, but I do have to wonder - 
>if a message is sent to multiple lists (or in general multiple recipients),
>why should a reply-to-list go to only one of those lists/recipients?

Yes, that is a Good Question. Ideally, the Reply-To-List command should
reply to every list to which the message was sent. The problem is how does
it know this? No obvious solution, but much benefit in solving it, so any
bright ideas anyone? Replying to everything in the To: header might come
close in many cases, especially if one of those addresses could be
identified as being the same as some List-Post header.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Thu, 2 Sep 2004 21:50:12 -0400
From: Keith Moore <[email-masked]>
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Erroneous content-type: Text/plain; charset=us-ascii
Sender: [email-masked]

On Thu, 2 Sep 2004 08:16:38 -0500 
"Vaudreuil, Greg M (Greg)" <[email-masked]> wrote:

> I don't have a stomach for standardized error processing... and I doubt you
> could do this right anyway. 

I was thinking much the same thing.  The problem with trying to retroactively
come up with a standard interpretation of protocol violations is that (a) it's
certain to break some existing behavior that someone finds useful or
desirable, and (b) the kinds of violations that get generated change from time
to time, and you probably want to change how they're handled.

In hindsight, it would have been nice if email had been designed so that 
errors get reported "close to" where they are generated.  To me this makes
a lot more sense than trying to fix things up on the recipient end.  Along
those lines, we could always encourage MSAs to detect and report errors in
mail messages - such as characters outside the ASCII repertoire in a body part
labeled as  US-ASCII.  So far there hasn't been a lot of interest in doing
that.  Once users realize that this improves their mail service in the long
run, maybe they'll go for it.

Keith

Date: Fri, 03 Sep 2004 00:28:22 +0900
To: [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: New Internet Draft: draft-duerst-archived-at-00.txt
Sender: [email-masked]

At 07:56 04/09/02 -0400, you wrote:
>Martin Duerst wrote:
> >
> > Dear email specialists,
> >
> > I have recently submitted a proposal for a new email header,
> > the Archived-At header. You can find it at
> > http://www.ietf.org/internet-drafts/draft-duerst-archived-at-00.txt
> >
> > It defines a new email header, Archived-At:, to provide a direct
> > link to the archived form of an individual mail message. We use
> > this extremely successfully (currently in the form X-Archived-At)
> > at W3C.
> >
> > I would highly appreciate any feedback and comments on this proposal.
> > Please make sure you copy me, as I'm not subscribed to this list.
> >
> >
> > Regards,    Martin.
>
>That draft expired last month.  Is the proposal still being pursued?

Yes, please see
http://www.ietf.org/internet-drafts/draft-duerst-archived-at-00.txt
(trying with a higher number isn't that difficult, or is it?)

That draft doesn't address all the discussion I was aware of,
because just when I updated it before the deadline, the folder
where I had put all these mails from this discussion was lost,
but I have recovered it in the meantime, and should be able to
get back to it in a few weeks.

Another thing I'm waiting for is the start of the header registry
at IANA.

Regards,   Martin.

Date: Thu, 2 Sep 2004 09:34:58 -0700
To: [email-masked], Tony Hansen <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: The job of an MSA
Cc: [email-masked], Bruce Lilly <[email-masked]>
Sender: [email-masked]

At 5:33 PM -0400 8/16/04, Bruce Lilly wrote:

>  Tony Hansen wrote:
>
>>  Given my druthers, I'd much rather see it be an extension only to the
>>  MSA SUBMIT protocol and not one that is expected to be implemented in MTAs.
>
>  For the issue of efficient transfer where there is a bottleneck
>  (e.g. a dialup connection to an ISP), it might not be practical
>  to restrict it to the SUBMIT protocol; not all ISPs operate
>  servers on port 587.

It's permitted to run an MSA on port 25; the issue isn't so much 
which port but which intended functionality: MTA or MSA.  A server 
intended to accept connections from authorized users and receive 
initial submissions of mail is clearly an MSA.  Putting it on port 
587 just helps make this more clear, and allows for a clear 
separation of security policies between relay and submission.  And 
has been noted, if you're upgrading anyway, it makes sense to listen 
on 587.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
When news of Alexander Graham Bell's invention reached the
United Kingdom, the chief engineer of the British Post Office
failed to be impressed.  "The Americans," he said loftily,
have need of the telephone -- but we do not.  We have plenty
of messenger boys..."

Date: Thu, 2 Sep 2004 09:31:48 -0700
To: Tony Hansen <[email-masked]>, Dave Crocker <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: The job of an MSA
Cc: [email-masked]
Sender: [email-masked]

At 4:47 PM -0400 8/16/04, Tony Hansen wrote:

>  The current SUBMIT protocol clearly identifies which headers it is 
> allowed to mess around with. The To/Cc/Bcc headers are not in that 
> list.

RFC 2476 does permit some alteration of address headers:

>  8.7.  Resolve Aliases
>
>     The MSA MAY resolve aliases (CNAME records) for domain names, in the
>     envelope and optionally in address fields of the header, subject to
>     local policy.
>
>     NOTE:  Unconditionally resolving aliases could be harmful.  For
>     example, if www.example.net and ftp.example.net are both aliases for
>     mail.example.net, rewriting them could lose useful information.
>
>  8.8.  Header Rewriting
>
>     The MSA MAY rewrite local parts and/or domains, in the envelope and
>     optionally in address fields of the header, according to local
>     policy.  For example, a site may prefer to rewrite 'JRU' as '
>     J.Random.User' in order to hide logon names, and/or to rewrite '
>     squeeky.sales.example.net' as 'zyx.example.net' to hide machine names
>     and make it easier to move users.
>
>     However, only addresses, local-parts, or domains which match specific
>     local MSA configuration settings should be altered.  It would be very
>     dangerous for the MSA to apply data-independent rewriting rules, such
>     as always deleting the first element of a domain name.  So, for
>     example, a rule which strips the left-most element of the domain if
>     the complete domain matches '*.foo.example.net' would be acceptable.

draft-gellens-submit-bis-00.txt has the same text, also in 8.7 and 8.8.

Date: Thu, 02 Sep 2004 07:56:17 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Martin Duerst <[email-masked]>
CC: [email-masked]
Subject: Re: New Internet Draft: draft-duerst-archived-at-00.txt
Sender: [email-masked]

Martin Duerst wrote:
> 
> Dear email specialists,
> 
> I have recently submitted a proposal for a new email header,
> the Archived-At header. You can find it at
> http://www.ietf.org/internet-drafts/draft-duerst-archived-at-00.txt
>     
> It defines a new email header, Archived-At:, to provide a direct
> link to the archived form of an individual mail message. We use
> this extremely successfully (currently in the form X-Archived-At)
> at W3C.
> 
> I would highly appreciate any feedback and comments on this proposal.
> Please make sure you copy me, as I'm not subscribed to this list.
> 
> 
> Regards,    Martin.

That draft expired last month.  Is the proposal still being pursued?

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Jacob Palme <[email-masked]>, [email-masked]
Cc: DSV KOM Development Group <[email-masked]>
Subject: RE: Erroneous content-type: Text/plain; charset=us-ascii
Date: Thu, 2 Sep 2004 08:16:38 -0500 
Sender: [email-masked]

I don't have a stomach for standardized error processing... and I doubt you could do this right anyway.  The right thing to do is to fix the offending mailers.  Doing the best they can in the face of brokeness is a good competitive differentiator for clients.

I assume you get predominately 8859-1 mislabled as US-ASCII based on the fact you predominantely communicate with folks in a Western European language.  I bet someone using say Cyrilc would have a predominant error condidition of a different 8859 varient mis-labled as US-ASCII.

Why would we assume the broken mailers would any more ensure that characters are in 8859-1 than they would ensure that what is labled is correct?   What if the standard, or IETF in a BCP, says "treat this error as X" and a mailer used in a different region made a different error? 

Greg V.

-----Original Message-----
From: Jacob Palme [mailto:[email-masked]]
Sent: Thursday, September 02, 2004 6:18 AM
To: [email-masked]
Cc: DSV KOM Development Group
Subject: Erroneous content-type: Text/plain; charset=us-ascii

I often get incorrect incoming e-mails, which have in their
headers either

Content-type: Text/plain; charset=us-ascii
or only
Content-type: Text/plain

even though the text is in effect ISO-8859-1.

I think IETF should maybe consider specifying what a mailer 
should do if it gets characters > 127 in e-mail bodies 
labelled "us-ascii" or with no charset label.

At present, the standards only say that mailers should 
handle such messages as "us-ascii". But since us-ascii does 
not say what you should do with characters > 127, present 
standards actually do not say what a mailer should do with 
such messages.

I think a mailer should in fact treat such messages as 
either "iso-8859-1" or as a local character set specified 
by the user in preferences.

In fact, many mailers already do this. So my suggestions is 
mainly that we should standardize what most mailers already 
do. There is a need to standardize this anyway, since there 
are mailers, for example the one I am using, Eudora 6.1 for 
Macintosh, which do not treat such messages as 8859-1. 
Eudora 6.1 handles such messages as if their charset had 
been Mac Roman, which is not very useful since almost no 
actual incoming messages are in Mac Roman without being 
labelled with this character set.

There is one argument for doing what Eudora 6.1 does.
This is the implicit rule "do not munge", which says that
if you get illegal content, you should not try to correct
it, but just pass it along unchanged.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 2 Sep 2004 07:40:30 -0400
From: Keith Moore <[email-masked]>
To: Philip Hazel <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

> > > Senders often want to _encourage_ followups and _discourage_ replies.
> > > That doesn't mean senders want to _break_ the reply mechanism.
> > 
> > Mail doesn't have "followups", it has replies.
> 
> People keep falling back on that (correct) formal statement. However, in 
> practice, users don't perceive much (any?) difference between mail and
> news. They use the same agents to process all kinds of messages, which
> sometimes have come by mail, and sometimes have come by news. I'm sure
> that in many users' minds a newsgroup is just another kind of mailing
> list.
> 
> The conclusion seems fairly obvious...

perhaps to you.  I can find two fairly obvious, but contradictory,
conclusions:

1. people are confused by the apparent similarity, so we'd serve people
better by trying to make the differences more apparent

2. people want to treat the two as identical, so we should try to make
them work as similarly as possible

actually I don't believe that "users don't perceive much (any?) difference
between mail and news."  people are very good at managing differences in
social contexts, even if they don't take the time to analyze them or to
express those differences in words.  people figure out very quickly that
there are differences in privacy, style, and other social norms between
the two media.  they may get annoyed when either system doesn't support
the functionality that they need - but this isn't an argument for making
the two systems the same.

Date: Thu, 2 Sep 2004 12:17:46 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Erroneous content-type: Text/plain; charset=us-ascii
Cc: DSV KOM Development Group <[email-masked]>
Sender: [email-masked]

I often get incorrect incoming e-mails, which have in their
headers either

Content-type: Text/plain; charset=us-ascii
or only
Content-type: Text/plain

even though the text is in effect ISO-8859-1.

I think IETF should maybe consider specifying what a mailer 
should do if it gets characters > 127 in e-mail bodies 
labelled "us-ascii" or with no charset label.

At present, the standards only say that mailers should 
handle such messages as "us-ascii". But since us-ascii does 
not say what you should do with characters > 127, present 
standards actually do not say what a mailer should do with 
such messages.

I think a mailer should in fact treat such messages as 
either "iso-8859-1" or as a local character set specified 
by the user in preferences.

In fact, many mailers already do this. So my suggestions is 
mainly that we should standardize what most mailers already 
do. There is a need to standardize this anyway, since there 
are mailers, for example the one I am using, Eudora 6.1 for 
Macintosh, which do not treat such messages as 8859-1. 
Eudora 6.1 handles such messages as if their charset had 
been Mac Roman, which is not very useful since almost no 
actual incoming messages are in Mac Roman without being 
labelled with this character set.

There is one argument for doing what Eudora 6.1 does.
This is the implicit rule "do not munge", which says that
if you get illegal content, you should not try to correct
it, but just pass it along unchanged.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 2 Sep 2004 09:46:50 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

On Wed, 1 Sep 2004, Bruce Lilly wrote:

> > Senders often want to _encourage_ followups and _discourage_ replies.
> > That doesn't mean senders want to _break_ the reply mechanism.
> 
> Mail doesn't have "followups", it has replies.

People keep falling back on that (correct) formal statement. However, in 
practice, users don't perceive much (any?) difference between mail and
news. They use the same agents to process all kinds of messages, which
sometimes have come by mail, and sometimes have come by news. I'm sure
that in many users' minds a newsgroup is just another kind of mailing
list.

The conclusion seems fairly obvious...

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Thu, 2 Sep 2004 01:11:20 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> >there is no solution to these problems that doesn't involve some 
> >changes in MUA behavior.  the question is:  which changes give the most 
> >benefit for the least transition pain?
> 
> I think the first thing you need is a third way of replying -
> "Reply-To-List" which, as Bruce had told us, some MUAs already provide.

not that I entirely dismiss this idea, but I do have to wonder - 
if a message is sent to multiple lists (or in general multiple recipients),
why should a reply-to-list go to only one of those lists/recipients?
 
Keith

Date: Thu, 2 Sep 2004 01:08:34 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: the most obvious failure in To-NoReply
Sender: [email-masked]

> >Having lists mung mail-followup-to is every bit as bad as having lists 
> >mung reply-to.  actually it's worse, since one of the arguments in 
> >favor of mail-followup-to is that it hasn't been corrupted like 
> >reply-to has.
> 
> Actually, munging Reply-To works quite well in closed lists, or in lists
> such as this one where there are extended threads on some topics and which
> are not really suited to contributors who are not subscribed to the list
> (who will usually see no more than than a few messages at the start of a
> thread, if that).

even in closed lists there is an inherent conflict between what the author
wants and what a list might want to impose. even if the list only sets
reply-to when the author has omitted it, the recipient can't tell who set it.

(you're also wrong about this list not being suitable for outside contributors.)

> >> MUAs then need some form of command for "Reply-To-List", and the 
> >> obvious
> >> name for that command is "Followup" (or the single letter 'F').
> 
> >No, it's not obvious.  Even though you can gateway mail into news and 
> >vice versa, in practice the differences between the two environments 
> >affect how people interact with those environments.  A followup is not 
> >the same thing as reply-to-list (using list-post) or even reply-to-all.
> 
> It is pretty close to the same thing in some lists (see above).

yes, there are exceptions.  there are also cases where lists should remove
all headers from the original message.  I'm talking about "normal",
general-purpose lists, rather than lists that need to hide information
about their contributors.

>  
> >  If email had a way to distinguish list addresses from personal 
> >addresses, something analogous to followup might be "reply to just the 
> >lists".  but even then it would still be different.
> 
> I think the ability for a MUA to know whether it is replying to a list is
> highly desirable (whether by detecting the presence of List-* headers or
> otherwise).
> 
> 
> >in email it is much less reasonable to assume that everyone in a 
> >conversation can access any mailing list that is copied on the 
> >conversation - not all mailing lists are public, and people are less 
> >likely to be willing to subscribe to an email list than to a usenet 
> >newsgroup.
> 
> Indeed. There is a great variety of mailing lists, and one solution might
> not fit all. But that is no reason not to provide solutions for those
> cases where they seem to be needed.
> 
> 	
> >> Personally, I find it extremely annoying to receive personal replies to
> >> messages I post to a mailing list to which I am already subscribed.
> 
> >Personally, I find it extremely valuable to receive personal replies to 
> >messages I post to a mailing list to which I am already subscribed.
> 
> And that is exactly the problem (and the same problem exists on Usenet,
> where some posters like personal replies as well as followups, and others
> abhor them). So the first thing that is clear is that users need some
> means to indicate which class they belong to 

no, it's not clear, because there are other variables than a user's
normal preference that should be considered.  but mail-copies-to
is worth considering as one way to solve the problem.

Keith

To: [email-masked]
Xref: clerew local.mime:3476
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: the most obvious failure in To-NoReply
Date: Wed, 1 Sep 2004 19:35:38 GMT
Lines: 66
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>Having lists mung mail-followup-to is every bit as bad as having lists 
>mung reply-to.  actually it's worse, since one of the arguments in 
>favor of mail-followup-to is that it hasn't been corrupted like 
>reply-to has.

Actually, munging Reply-To works quite well in closed lists, or in lists
such as this one where there are extended threads on some topics and which
are not really suited to contributors who are not subscribed to the list
(who will usually see no more than than a few messages at the start of a
thread, if that).

>> MUAs then need some form of command for "Reply-To-List", and the 
>> obvious
>> name for that command is "Followup" (or the single letter 'F').

>No, it's not obvious.  Even though you can gateway mail into news and 
>vice versa, in practice the differences between the two environments 
>affect how people interact with those environments.  A followup is not 
>the same thing as reply-to-list (using list-post) or even reply-to-all.

It is pretty close to the same thing in some lists (see above).
 
>  If email had a way to distinguish list addresses from personal 
>addresses, something analogous to followup might be "reply to just the 
>lists".  but even then it would still be different.

I think the ability for a MUA to know whether it is replying to a list is
highly desirable (whether by detecting the presence of List-* headers or
otherwise).

>in email it is much less reasonable to assume that everyone in a 
>conversation can access any mailing list that is copied on the 
>conversation - not all mailing lists are public, and people are less 
>likely to be willing to subscribe to an email list than to a usenet 
>newsgroup.

Indeed. There is a great variety of mailing lists, and one solution might
not fit all. But that is no reason not to provide solutions for those
cases where they seem to be needed.

>> Personally, I find it extremely annoying to receive personal replies to
>> messages I post to a mailing list to which I am already subscribed.

>Personally, I find it extremely valuable to receive personal replies to 
>messages I post to a mailing list to which I am already subscribed.

And that is exactly the problem (and the same problem exists on Usenet,
where some posters like personal replies as well as followups, and others
abhor them). So the first thing that is clear is that users need some
means to indicate which class they belong to (and Mail-Copies-To:
nobody/poster, though not elegant, does provide precisely that).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:3477
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: Wed, 1 Sep 2004 19:40:39 GMT
Lines: 22
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>there is no solution to these problems that doesn't involve some 
>changes in MUA behavior.  the question is:  which changes give the most 
>benefit for the least transition pain?

I think the first thing you need is a third way of replying -
"Reply-To-List" which, as Bruce had told us, some MUAs already provide.

And then you need some facility for an original user to say whether he
likes or abhors personal replies in addition to replies to the list.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Wed, 01 Sep 2004 21:08:41 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

Simon Josefsson wrote:

> Setting Reply-To might work for one kind of replies, but does the
> wrong thing for the other kind of replies.  To see this, just go
> through, for each kind of reply, what happen if Reply-To is set to the
> mailing list address or to nobody:;.

That will also depend on what is in To and Cc fields of the original.

For a partial analysis see http://www.landfield.com/usefor/2004/Jul/0274.html

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: reply problem list
Date: Thu, 02 Sep 2004 02:35:33 +0200
Lines: 31
Cancel-Lock: sha1:KwUcAPcIx0+SZ3AYCRE8FV5D5cg=
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> D. J. Bernstein wrote:
>> Bruce Lilly writes:
>> 
>>>If the original message author wishes responses to go
>>>to the list, he should set Reply-To to the list address.
>> 
>> 
>> Senders often want to _encourage_ followups and _discourage_ replies.
>> That doesn't mean senders want to _break_ the reply mechanism.
>
> Mail doesn't have "followups", it has replies.  The Reply-To field
> provides a sender with a mechanism to specify the reply address(es)
> which he wishes to encourage.  It is of course still possible for a
> recipient to direct replies elsewhere.

Real world mail has more than one kind of reply, call the distinction
public/private, narrow/broad, reply-author/reply-all or what you will.

Setting Reply-To might work for one kind of replies, but does the
wrong thing for the other kind of replies.  To see this, just go
through, for each kind of reply, what happen if Reply-To is set to the
mailing list address or to nobody:;.  This is why we need a better
reply mechanism for mail.

The hope should be that a better solution than forcing users to do
manual work can be worked out.

Regards,
Simon

Date: Wed, 01 Sep 2004 19:45:42 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "D. J. Bernstein" <[email-masked]>
CC: [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

D. J. Bernstein wrote:
> Bruce Lilly writes:
> 
>>If the original message author wishes responses to go
>>to the list, he should set Reply-To to the list address.
> 
> 
> Senders often want to _encourage_ followups and _discourage_ replies.
> That doesn't mean senders want to _break_ the reply mechanism.

Mail doesn't have "followups", it has replies.  The Reply-To field
provides a sender with a mechanism to specify the reply address(es)
which he wishes to encourage.  It is of course still possible for a
recipient to direct replies elsewhere.

Date: Wed, 01 Sep 2004 16:14:35 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], [email-masked], ietf-822 mailing list <[email-masked]>
Subject: 3rd party ietf-compliance testers
Sender: [email-masked]

Do anyone know of any companies out there that will do IETF compliance 
checks of SMTP and/or POP servers? We have a situation where we could 
use such a service.

Thanks!

	Tony Hansen
	[email-masked]

Date: Wed, 1 Sep 2004 16:07:58 -0400
From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

> 
> Bruce Lilly writes:
> > If the original message author wishes responses to go
> > to the list, he should set Reply-To to the list address.
> 
> Senders often want to _encourage_ followups and _discourage_ replies.
> That doesn't mean senders want to _break_ the reply mechanism.

The reply mechanism is already broken.  The way Reply-to is implemented,
it doesn't do the right thing for either "reply to all" or "reply to
author".

There are lots of ways to fix this, but they all involve changing 
how user agents work to some degree.  To people who are adapted
to the current broken behavior, those changes will be seen as new
broken behavior - at least until they get used to it.  The real
question is which approach produces the smoothest transition and
the most favorable end-state.

Keith

Date: Wed, 1 Sep 2004 15:57:58 -0400
From: Keith Moore <[email-masked]>
To: [email-masked] (Claus =?ISO-8859-1?Q?F=E4rber?=)
Cc: [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Sender: [email-masked]

> 
> Simon Josefsson <[email-masked]> schrieb/wrote:
> > This might be, but at least my experience with deployed MUAs suggest
> > this isn't what is implemented today.  MUAs prefer the Reply-To over
> > From on "reply author".
> 
> Well, the "reply author" function is IMO just mislabelled. It actually
> means: "reply to a small number of persons".

Or to put it another way: MUAs really need a "reply author" button,
but they don't have one.  The typical "reply" button doesn't
quite work like it should because the "narrow reply" really doesn't
map to what the recipient is likely to want to do.

(The only time I ever use (narrow) "reply" is when I really want 
"reply to author".  And then I have to check the From field of the
resulting message to see if the author had specified reply-to .
If he did I often have to edit the field and restore the correct
address.)

> Keith Moore's proposal caters for the same problem (replies don't go  
> where they are supposed to go) and it's more compatible with existing  
> MUAs that don't understand the header. But it's more complex to under- 
> stand for the average user and it's not compatible with the mental model  
> users have made based on the common user agent UIs. 

Actually I think it's the other way around.  Setting mail-reply-to
and mail-followup-to headers is more complex for the average user,
since it requires the user to specify exactly which recipients should
get replies in each of two cases.  It's much easier for the user to
say "please don't copy these recipients on replies".

Ideally of course, the author's user agent would provide the user
with a good interface that lets the author enable or disable
reply-ability on a per-address basis.  Then it would map those
requests to whatever header fields were appropriate.

> And it still does  
> not provide a distinction between different types of replies, which is  
> what user agent desingers want to provide.

User agents should definitely provide different kinds of replies.  But
I don't think it's useful to allow the author of a message to fundamentally
change the behavior of those kinds of replies.

Keith

Date: 1 Sep 2004 19:10:33 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: reply problem list
Sender: [email-masked]

Bruce Lilly writes:
> If the original message author wishes responses to go
> to the list, he should set Reply-To to the list address.

Senders often want to _encourage_ followups and _discourage_ replies.
That doesn't mean senders want to _break_ the reply mechanism.

A new header field could formally declare the same information:

   Are-You-Sure-You-Want-To-Reply: I'd like to see this topic discussed
     publicly.

An MUA that sees this header field could warn the replying user at the
beginning of composing a reply:

   Are you sure you want to reply privately? The message author says:
   "I'd like to see this topic discussed publicly." Click here for
   private, here for public, here to cancel.

This approach doesn't screw up the Reply-To information, so the user can
still send a reply rather than a followup if he wants to.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

To: [email-masked]
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
Subject: Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]
Date: 01 Sep 2004 14:58:00 +0200
Lines: 31
Sender: [email-masked]

Simon Josefsson <[email-masked]> schrieb/wrote:
> This might be, but at least my experience with deployed MUAs suggest
> this isn't what is implemented today.  MUAs prefer the Reply-To over
> From on "reply author".

Well, the "reply author" function is IMO just mislabelled. It actually
means: "reply to a small number of persons".

Most MUAs (the M here is for "message", including Netnews) have two
pre-defined reply functions: a narrow reply going to a small number of
persons and a broad reply going to a large number of persons, often via
newsgroups or mailing lits.

These can be called narrow/broad, reply/followup, reply-to-author/reply-
to-group, private/public, etc. but they are basically the same concept.

Strictly, mail does not know that concept but MUAs try to provide it to  
the users. Mail-Followup-To provides that; this is why it's popular with

Keith Moore's proposal caters for the same problem (replies don't go  
where they are supposed to go) and it's more compatible with existing  
MUAs that don't understand the header. But it's more complex to under- 
stand for the average user and it's not compatible with the mental model  
users have made based on the common user agent UIs. And it still does  
not provide a distinction between different types of replies, which is  
what user agent desingers want to provide.

Claus
-- 
http://www.faerber.muc.de