Subject: Re: Email Subaddressing
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Date: 1 Aug 1997 00:29:53 -0000

> Is there any way to make the answer be "yes"

MTAs and LDAs that don't support what the users want are thrown away.

Mailing list owners want per-recipient VERPs, for example. sendmail
doesn't support per-recipient VERPs. So they switch to qmail.

This is called competition. It's how the real world makes progress.

> other than standardizing the format subaddresses?

It's none of your business how a host interprets its local addresses.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 31 Jul 1997 16:51:45 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Jul 31, 11:20pm)
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Jul 31, 11:20pm, D. J. Bernstein wrote:
> Subject: Re: Email Subaddressing
> > All this does is push the question off a level.  Is it desirable to be
> > able to mix and match MTA, delivery agent, and submission agent?
> 
> qmail was designed to support multiple delivery agents and submission
> agents.  [...]
> 
> sendmail can also invoke a variety of delivery agents [...]
> 
> When a delivery agent supports subaddresses---as, e.g., procmail does---
> both qmail and (recent versions of) sendmail can straightforwardly pass
> the necessary information to it.

That's nice, but that's not the question.  The question is whether I can
take qmail or sendmail or any other MTA, use arbitary delivery agent X and
arbitrary submission agent Y, and expect that both X and Y understand the
same format of subaddresses.

The present-day answer is obviously "no."  Is there any way to make the
answer be "yes" other than standardizing the format subaddresses?

Date: 31 Jul 1997 23:20:21 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> All this does is push the question off a level.  Is it desirable to be able
> to mix and match MTA, delivery agent, and submission agent?

qmail was designed to support multiple delivery agents and submission
agents. qmail-local can invoke a variety of delivery agents. Submission
agents can run as /usr/lib/sendmail and pass messages to qmail-queue.

sendmail can also invoke a variety of delivery agents, and it'd be easy
to write a qmail-queue clone for sendmail if there were any interest.

When a delivery agent supports subaddresses---as, e.g., procmail does---
both qmail and (recent versions of) sendmail can straightforwardly pass
the necessary information to it.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 31 Jul 1997 15:09:39 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Jul 31,  9:36pm)
Reply-To: [email-masked]
To: "D. J. Bernstein" <[email-masked]>, [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Jul 31,  9:36pm, D. J. Bernstein wrote:
> Subject: Re: Email Subaddressing
> > but you included as a local configuration problem
> > the case where the MUA needs to supply a return address.
> 
> MUAs typically pass a partially formed message to a submission agent
> supplied with the MTA.
> 
> The submission agent figures out From, Return-Path, etc., from a
> combination of sysadmin configuration and user configuration.

All this does is push the question off a level.  Is it desirable to be able
to mix and match MTA, delivery agent, and submission agent?

Date: Thu, 31 Jul 1997 14:49:29 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Email Subaddressing
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Thu, 31 Jul 1997, D. J. Bernstein wrote:
> It would be possible to do something different. Many delivery agents
> record the envelope recipient in a usable format. The MUA could read the
> subaddress and use it for sorting. Chris, would it violate your ``MUST
> NOT automatically create new folders'' requirement if the MUA showed the
> user a list of the subaddresses that had been shown up, and allowed the
> user to browse each subaddress as a folder?

Not as long as the MUA also allows browsing them in a single interface.

The requirement stems from the security issue of not wanting to
unintentially cede control of one's folder namespace to others.  It
probably should be a "SHOULD NOT" with clearer explaination.

		- Chris

Date: 31 Jul 1997 21:36:43 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> but you included as a local configuration problem
> the case where the MUA needs to supply a return address.

MUAs typically pass a partially formed message to a submission agent
supplied with the MTA.

The submission agent figures out From, Return-Path, etc., from a
combination of sysadmin configuration and user configuration. See, e.g.,
http://www.qmail.org/qmail-manual-html/man8/qmail-inject.html.

> What's the mechanism for ensuring that they agree on what such a return
> address should look like?

They don't have to.

I use VERPs for my outgoing messages---e.g.,

   Return-Path: <[email-masked]>

---so that a program can reliably associate bounce messages with
original messages. The VERPs are created by qmail-inject, not the MUA.
The delivery of djb-dsn-* is handled by qmail-local, not the MUA.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 31 Jul 1997 13:49:34 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Jul 31,  7:45pm)
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Jul 31,  7:45pm, D. J. Bernstein wrote:
> Subject: Re: Email Subaddressing
> > If the ability to mix and match MUAs and delivery agents is important,
> 
> In practice the interface is the mailbox. The delivery agent writes the
> message to the mailbox in some standard format, and the MUA reads it.

That's true upon receipt, but you included as a local configuration problem
the case where the MUA needs to supply a return address.  In this case the
delivery agent is presumably going to interpret that address when the reply
comes back, so the interface is the address itself.

What's the mechanism for ensuring that they agree on what such a return
address should look like?

Date: 31 Jul 1997 19:45:14 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> If the ability to mix and match MUAs and delivery agents is important,

In practice the interface is the mailbox. The delivery agent writes the
message to the mailbox in some standard format, and the MUA reads it.

MUAs don't generally seem to care about the envelope, except possibly
for displaying the return-path.

It would be possible to do something different. Many delivery agents
record the envelope recipient in a usable format. The MUA could read the
subaddress and use it for sorting. Chris, would it violate your ``MUST
NOT automatically create new folders'' requirement if the MUA showed the
user a list of the subaddresses that had been shown up, and allowed the
user to browse each subaddress as a folder? Does your answer depend on
how the messages are physically stored on disk?

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Thu, 31 Jul 1997 13:07:43 -0400 (EDT)
From: [email-masked]
To: John Robert LoVerso <[email-masked]>
Subject: Re: Email Subaddressing
Cc: [email-masked]
Sender: [email-masked]

Gee, is mail forwarding part of the MTA or the ``mail delivery agent''? 
I'm sorry that I'm not up on the distinction; perhaps it comes from
being X.500-free for so long.  Think of the consideration about copying
+subaddr stuff as part of the mail forwarding process, whether that's
part of the mail delivery agent or the MTA; the consideration still
applies. 

In fact, it applies to the general notion of ``mail forwarding,''
whether that is done at MTA, delivery-agent, or MUA time. 

		Thanks, 
		Craig 

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 31 Jul 1997 10:04:29 -0700
Comments: In reply to Chris Newman <[email-masked]> "Re: Email Subaddressing" (Jul 31, 12:16am)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

Dan B. dismisses MUA and final delivery agent processing of subaddresses
as local configuration problems and asserts that list server behavior is
up to the list maintainer.

I agree that there's no need to mandate list server behavior; documenting
the possible usages of subaddresses is more than enough in that case.

However, I'd like to know the solution to the local configuration problem.  
If the ability to mix and match MUAs and delivery agents is important, then
it would seem that they need some common set of rules for interpreting the
local-part of the addresses.  What's the alternative?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

To: [email-masked]
Cc: [email-masked]
Subject: Re: Email Subaddressing 
Date: Thu, 31 Jul 1997 12:06:18 -0400
From: John Robert LoVerso <[email-masked]>
Sender: [email-masked]

> Point three: Raise the issue of copying the +subaddr annotation. 
> Suppose mail to local user user1 is forwarded to local user user2.  If
> mail arrives for user1+foo, should it be forwarded to user2 or to
> user2+foo?  Perhaps the MTA's notion of mail forwarding needs to be able

Isn't this a function of the mail delivery agent rather than the MTA?
Certainly many MTAs attempt to be both (sendmail), but truly the MTA
doesn't need to know about aliasing or forwarding.

John

Date: Thu, 31 Jul 1997 11:36:43 -0400 (EDT)
From: [email-masked]
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

Independently of all the concerns about who is mandating what, there are
a few informational points that are interesting even for sites that
implement subaddressing locally--i.e. that can serve as advice for some
kinds of new implementations.  For purposes of this presentation I'm
going to assume that the locally-interpreted subaddressing scheme is
based on a ``addr+subaddr'' form of local-part. 

Point one: Copy the incoming address to a Received: header, perhaps in a
``for'' clause.  Generally, I want to be able to put my
addr+subaddr@domain address in a distribution list and retain the fact
that it was sent to addr+subaddr.  If the +subaddr text is to be
interpreted by some post-delivery process, it has to be recorded
somewhere at delivery time, and a Received: header is a reasonable
candidate. 

Point two: Use the entire addr+subaddr for any duplicate elimination. 
If an MTA attempts to eliminate the delivery of duplicate messages, it
will often do so by refusing to send the SAME MESSAGE to the SAME
ADDRESS.  Thus, it can make some record of having sent a given message
to a given address, and future delivery attempts can check for such a
record.  While I could offer some advice about what constitutes an
adequate record of the SAME MESSAGE, at this point I'd just remark that
the entire addr+subaddr information is important to be considered for
purposes of duplicate elimination; thus, sending message A to addresses
foo+bar and foo+baz is not an instance of duplicate delivery. 

Point three: Raise the issue of copying the +subaddr annotation. 
Suppose mail to local user user1 is forwarded to local user user2.  If
mail arrives for user1+foo, should it be forwarded to user2 or to
user2+foo?  Perhaps the MTA's notion of mail forwarding needs to be able
to allow the user or administrator who sets the mail forwarding to make
the choice. 

Needless to say, these fine points arose from real-life use of
addr+subaddr notation over a few years. 

		Craig 

Date: 31 Jul 1997 08:30:54 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

(Please don't send me duplicates, Chris.)

> There are two cases where MUAs need to cooperate with subaddresses:
> 1) MUAs which don't allow from to be edited otherwise.

This is a purely local configuration problem.

> 2) MUAs which validate local addresses against a white pages or authdb
> service.

A service that claims to check mail addresses obviously has to
understand subaddresses. This is a purely local configuration problem.

> 1) List server restricts posting to subscribers.

You have no right to demand that list owners accept your mail.

> There are several cases where a final delivery agent needs to cooperate
> with subaddresses:

All of those cases are purely local configuration problems.

I suppose next we're going to see a document explaining how sendmail
interacts with procmail, and requiring that all MTAs and LDAs work the
same way.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: 31 Jul 1997 08:15:18 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> there's a show-stopper for using "-". 

No, there isn't. But thanks for reminding me of this issue---it turns
out to be a show-stopper for your proposal.

> Many sites use the firstname.lastname@host naming convention
> and many people have "-" in their last names.

So what?

The software handles this just fine. It supports a more advanced address
hierarchy than your naive ``jean-marc MUST be delivered to jean'' idea.

What do you suggest someone do with existing usernames that contain +?
How will your wonderful new software handle this situation? Does it
start throwing away mail for those users?

With qmail, if + is the separator, those users will still receive mail.
Of course, this is incompatible with your delusion that local addresses
can be parsed by other hosts.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Thu, 31 Jul 1997 00:16:05 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Email Subaddressing
To: Bart Schaefer <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Wed, 30 Jul 1997, Bart Schaefer wrote:
> Put another way, is there ever a case where a sending agent needs to start
> from a primary address, compute a subaddress by some means other than user
> input, and direct the message to the concatenation of the two?

A lot of sites have a requirement that the from address not be editable in
their MUAs.  Such sites do this because they don't want realistic-looking
spoofing to be easy.  I can't think of anything the IETF could do to
change this.  We can jump up and down and say "you must be able to edit
the from address" all we want and it simply won't happen.

So I'm looking for the ability to enter just the subaddress for the From
header and envelope from without any requirement that the rest of the from
address be editable.  I bet MUA authors would go along with that (or a
special list-subscription command which added a subaddress) and it
wouldn't violate site policy for most sites which don't want the from
address editable.

> At this point I don't find the arguments for standardizing to be strong
> enough, though an informational document might be nice.  I'm willing to be
> convinced otherwise, though, because I do get mail via several domains and
> do feel the inconvenience of inconsistent or absent subaddressing schemes.

There are two cases where MUAs need to cooperate with subaddresses:

1) MUAs which don't allow from to be edited otherwise.

2) MUAs which validate local addresses against a white pages or authdb
service.

There is one case where a list server needs to cooperate with
subaddresses:

1) List server restricts posting to subscribers.

There are several cases where a final delivery agent needs to cooperate
with subaddresses:

1) alias or forwarding address (especially for centralized mail hubs which
route delivery to other nodes)

2) validation of local addresses against locally deliverable address list

3) Any final delivery filtering/filing rules.

I believe this demonstrates the need for standards-level interoperability
between the three components.

Date: Wed, 30 Jul 1997 23:56:12 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Email Subaddressing
To: Rick Troth <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Wed, 30 Jul 1997, Rick Troth wrote:
> 	IFF subaddressing were to come to pass, then ... 
>  
> 	I would second the use of dash because  I use it,  and have 
> seen others use it regularly,  as a delimiter between application name 
> or ID and the version or release.   That is,  there is precedent for 
> dash to be used as a marker between specific and non-specific: 

Besides the fact that I only know of one product which uses "-" as a
subaddress separator and several which use "+", there's a show-stopper for
using "-".  Many sites use the firstname.lastname@host naming convention
and many people have "-" in their last names.

		- Chris

Date: Wed, 30 Jul 1997 23:49:06 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Email Subaddressing
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Wed, 30 Jul 1997, John C Klensin wrote:
> I think you are right, and that it is probably worth giving 
> up the availability "+" for anything else to get where we 
> need to be. But, logically speaking, most of your argument 
> evaporates if either of two courses is taken:

I'm much less convinced.  I use subaddresses for non-mailing list things.
I believe they're generally useful regardless of alternative solutions to
the list subscription/restriction problems.

> If this logic is correct, can you make the case that it is 
> worth a possibly-significant risk to the infrastructure 
> (yes, there really are addresses -- especially in mappings 
> to and from strange gateways to LAN mail systems -- in 
> which "+" is a delimiter character, but not for 
> subaddressing, and several of them may appear in a 
> local-part) for what may be a short-term gain?

More than one deployed product already manages subaddresses as the spec
mentions and I've heard of no infrastructure problems other than the
occasional product which rejects all addresses containing "+".  Of
course such products are clearly in violation of RFC822 already.

I also don't view this as a short term gain.

From: "Bart Schaefer" <[email-masked]>
Date: Wed, 30 Jul 1997 22:37:54 -0700
Comments: In reply to Chris Newman <[email-masked]> "Email Subaddressing" (Jul 30, 11:24am)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

All the discussion so far about this draft hinges on one question:

Is it necessary for anyone other than the "Final MTA" and "Final Delivery
Agent" to understand the semantics of subaddresses?

Put another way, is there ever a case where a sending agent needs to start
from a primary address, compute a subaddress by some means other than user
input, and direct the message to the concatenation of the two?

If so, then there's a good reason to standardize the format of the primary
and sub-addresses, and to standardize the way they're concatenated.

If there is not, then failure to standardize is only an inconvenience.  It
means that a sub-addressing scheme that worked when the user received mail
at domain X may stop working when he moves to domain Y, even if both claim
to support sub-addressing.

Some inconveniences are severe enough to warrant a standard to mitigate
them; I suspect there'll be dissention over whether this is such a case.

At this point I don't find the arguments for standardizing to be strong
enough, though an informational document might be nice.  I'm willing to be
convinced otherwise, though, because I do get mail via several domains and
do feel the inconvenience of inconsistent or absent subaddressing schemes.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: Wed, 30 Jul 1997 21:31:55 -0500 (CDT)
From: Rick Troth <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> 1. ``+'' is not the de facto standard; qmail's ``-'' is in wider use by
> several measures. (The separator is configurable by the sysadmin, but
> most people stick to dash, which I recommend for a variety of reasons.)
 
	IFF subaddressing were to come to pass, then ... 
 
	I would second the use of dash because  I use it,  and have 
seen others use it regularly,  as a delimiter between application name 
or ID and the version or release.   That is,  there is precedent for 
dash to be used as a marker between specific and non-specific: 
 
		bash 
		bash-1.14 
		bash-2.0 
 
	looks visibly like 
 
		troth 
		troth-dnrc 
 
	But should I accept these? 
 
		troth-vmesa-l 
		troth-ietf-822 
 
	I would NOT like to see a slash used here, but there's 
near precedent for that too.   (HP's OpenMail; others?)    Period 
(dot) and underscore seem right out and comma would be difficult. 
 
	Maybe it should be  list!user  ...   ;-) 
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Wed, 30 Jul 1997 21:43:57 -0400 (EDT)
From: John C Klensin <[email-masked]>
Subject: Re: Email Subaddressing
To: Chris Newman <[email-masked]>
Cc: [email-masked]
Reply-to: John C Klensin <[email-masked]>
Sender: [email-masked]

On Wed, 30 Jul 1997 17:04:52 -0700 (PDT) Chris Newman 
<[email-masked]> wrote:

> I want to be able to subscribe to list foo as
> <[email-masked]> and have it delivered to me.  In order for
> this to work, I need user agents which let me type the "+foo" in the from
>...

Chris,

I think you are right, and that it is probably worth giving 
up the availability "+" for anything else to get where we 
need to be. But, logically speaking, most of your argument 
evaporates if either of two courses is taken:

(1) We went through a long and difficult period in which we 
eventually convinced most of those who develop list 
management software that it was rational to permit people 
to set a "list target" address that was different from the 
"from:" header field address.   One could adopt a model in 
which, logically, there were three addresses

   From:
   List distro    (defaults to from, but can be changed)
   List posting   (defaults to from --not list distro-- but 
                    can be changed)

(2) We go where, because of spam and spoofing issues, I 
think we are headed anyway, which is not accepting material 
for posting to a list unless a digital signature can be 
verified.  Then the "subscribe" operation somehow has to 
register a public key (or pointer to one).  But then "right 
to post" is a key identifier/ signature verification issue, 
not a matter of matching return address strings; the latter 
becomes largely superfluous.

If this logic is correct, can you make the case that it is 
worth a possibly-significant risk to the infrastructure 
(yes, there really are addresses -- especially in mappings 
to and from strange gateways to LAN mail systems -- in 
which "+" is a delimiter character, but not for 
subaddressing, and several of them may appear in a 
local-part) for what may be a short-term gain?

     john

Date: 31 Jul 1997 00:59:02 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> In order for
> this to work, I need user agents which let me type the "+foo" in the from
> and envelope sender address,

Chris, there's a huge difference between ``this is good'' and ``this is
the IETF's bailiwick.''

One piece of _advice_ that I give to MUA authors is to allow complete
configurability of every outgoing message, including Return-Path. But
I'm disgusted at the thought of the IETF _requiring_ this.

> I need a final delivery agent which won't reject "+foo" addresses. 

Surely every MTA supports aliases. If you don't like the user interface,
talk to the vendor, or switch to an MTA with a better user interface.

> I think most current uses of "-" are simply naming hierarchy and not
> subaddressing.

You didn't answer my question. Is it project-owner, or project+owner?

Are you going to prohibit mailing list names that match account names?
A uniform hierarchy doesn't have this problem.

  [ requiring mailing lists to incorrectly accept messages from joe+37 ]
> I don't consider this a big deal.

You are requiring a failure mode in a security mechanism.

You are also prohibiting a superior security mechanism.

This is unacceptable.

It is up to the mailing list owner to decide which messages he will
distribute and which ones he won't. If you don't like the security
mechanisms in current MLM software, you should complain to the MLM
authors, not the IETF.

> Because a good standard needs complete formal grammar for what it's
> discussing.

``Standard''? ``Good''?

If you weren't confusing content and encoding, you could simply say ``a
structured address consists of user-part, sep-char, and sub-part, where
user-part does not contain sep-char.''

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Wed, 30 Jul 1997 17:04:52 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Email Subaddressing
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Wed, 30 Jul 1997, D. J. Bernstein wrote:
> > We have to pick a single character,
> 
> Why?
> 
> What interoperability problems are you trying to solve?

Interoperability between MUAs, final delivery agents and mailing list
servers from different vendors.

I want to be able to subscribe to list foo as
<[email-masked]> and have it delivered to me.  In order for
this to work, I need user agents which let me type the "+foo" in the from
and envelope sender address, I need mailing list software which doesn't
reject postings from <[email-masked]> if I'm subscribed as
<[email-masked]>, and I need a final delivery agent which
won't reject "+foo" addresses. 

If this isn't a need for multi-vendor interoperability, what is?

>    Mailing list managers must disregard foo in deciding whether
>    joe+foo@host can send messages to the mailing list.
> 
> But that's a bad requirement. It prohibits cryptographic uses of the
> subaddress string. It also ignores the fact that joe+37@host might be a
> different user, with no right to use the mailing list; you have no way
> to tell whether the subscriber's delivery agent supports subaddresses.

I don't consider this a big deal.  People don't use "+" in addresses most
of the time, unless they're using it as a subaddress separator.  The
failure mode is to allow someone to post who otherwise might not be able
to -- not a big deal given how rarely + is used in addresses for other
reasons.

> > I also think "-" is a poor choice since it is already used for "-list",
> > "-owner", and "-request" primary addresses
> 
> This is one of the reasons that dash is a _good_ choice: it continues
> the tradition of a dash-separated address hierarchy. Using a different
> character for the top level is a pointless inconsistency.
> 
> For example, the main mailing list for a project commonly coincides with
> the project's account name. Is the owner's address project-owner or
> project+owner?

I'd argue that current uses of "-" do not have subaddress semantics.  The
"foo-list-request" address is not under management control of the entity
with the address "foo-list".  The common use of "+" is to separate address
management hierarchy.  Addresses before "+" are managed by the sysadmin,
addresses after the "+" are managed by the entity before the plus.  I
think most current uses of "-" are simply naming hierarchy and not
subaddressing.

> Again you're confusing content with encoding. The address

No I'm not.  I understand the distinction well.  But the distinction is
not clear to implementors of 821/822 and most Internet mail users so I see
little point in making the proposal more complex in order to make the
distinction clear.  The "raw" format for a mail address doesn't really
exist anywhere, except possibly as an internal aid to certain 
implementation strategies.

> The more basic question here is why you're bothering to talk about
> quoting in a document about subaddresses.

Because a good standard needs complete formal grammar for what it's
discussing.

> > I don't understand what you're saying.
> 
> Envelope sender addresses are easily forged. One solution is to have
> each sender use
> 
>    Return-Path: <[email-masked]>
> 
> where ``cookie'' is some sort of secret string---for example, a
> subscriber-specific secret supplied by the MLM. This obviously doesn't
> work if the MLM is required to ignore the cookie.

This is another case where MUA, final delivery agent and list exploder
need to interoperate.  There's also no reason this has to use the same
delimiter.  But in order to be practical for wide deployment, this would
have to be standards track.

		- Chrsi

Date: 30 Jul 1997 23:13:51 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> We have to pick a single character,

Why?

What interoperability problems are you trying to solve?

One of the reasons for qmail's growing popularity is its simple user
interface for subaddresses. But what does this have to do with the IETF?
Why should the IETF be trying to control user interface competition?

Throw away all the user interface stuff, and your document appears to
collapse down to a single requirement:

   Mailing list managers must disregard foo in deciding whether
   joe+foo@host can send messages to the mailing list.

But that's a bad requirement. It prohibits cryptographic uses of the
subaddress string. It also ignores the fact that joe+37@host might be a
different user, with no right to use the mailing list; you have no way
to tell whether the subscriber's delivery agent supports subaddresses.

> I've seen "=" used before.

MMDF.

> I also think "-" is a poor choice since it is already used for "-list",
> "-owner", and "-request" primary addresses

This is one of the reasons that dash is a _good_ choice: it continues
the tradition of a dash-separated address hierarchy. Using a different
character for the top level is a pointless inconsistency.

For example, the main mailing list for a project commonly coincides with
the project's account name. Is the owner's address project-owner or
project+owner?

> The idea is if my MUA and final delivery MTA are "subaddressing compliant",

If you simply want to define ``subaddressing compliant,'' go take it to
some group that publishes standards for user interfaces. (Maybe Apple.)

> The choice is either to require "canonically quoted" form which is what
> users see currently

Again you're confusing content with encoding. The address

   a,b,[email-masked]

is perfectly valid. It is _encoded_ as RCPT TO:<"a,b,c"@heaven.af.mil>
in SMTP. It may be _encoded_ in some way for user display. (Some people
use addresses with commas for spam control.)

The more basic question here is why you're bothering to talk about
quoting in a document about subaddresses.

> I don't understand what you're saying.

Envelope sender addresses are easily forged. One solution is to have
each sender use

   Return-Path: <[email-masked]>

where ``cookie'' is some sort of secret string---for example, a
subscriber-specific secret supplied by the MLM. This obviously doesn't
work if the MLM is required to ignore the cookie.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Wed, 30 Jul 1997 14:50:03 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Email Subaddressing
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Wed, 30 Jul 1997, D. J. Bernstein wrote:
> 1. ``+'' is not the de facto standard; qmail's ``-'' is in wider use by
> several measures. (The separator is configurable by the sysadmin, but
> most people stick to dash, which I recommend for a variety of reasons.)

This is the first I've heard of using "-".  I've seen "=" used before.  We
have to pick a single character, and I picked "+" because it is already
supported or partially supported by several vendors including:

sendmail, CMU Cyrus IMAP server, AMS, PMDF, and Pine.

I'll replace the words "de-facto standard" with "one common practice for"
in the intro since that's more accurate.

I also think "-" is a poor choice since it is already used for "-list",
"-owner", and "-request" primary addresses (the latter of which is a
proposed standard).  Overloading symbols is bad.

> 3. The requirement that foo-bar be delivered to foo ``by default'' is
> violated by any delivery agent that doesn't support subaddressing. What
> is the point of a requirement that nobody can rely on?

The idea is if my MUA and final delivery MTA are "subaddressing
compliant", then everything works as expected without sysadmin
intervention. The idea is to create a new level of conformance (subaddress
conformance) which users will find valuable.

> 5. The ``canonically quoted'' section confuses content with encoding.
> Any delivery agent that uses your syntax is almost certainly violating
> RFC 822, section 3.4.4. The correct rule is very simple: any nonempty
> string of ASCII characters is a valid local part. RFC 821 and RFC 822
> specify encodings of those strings for SMTP and mail headers.

The choice is either to require "canonically quoted" form which is what
users see currently in their user interfaces (unfortunately), or to
require "raw form" and define the mapping algorithm to RFC 821 and RFC 822
addressing.  As users never see "raw form" and it can't be left-to-right
parsed, I'm not comfortable using it at this point.

I'd certainly welcome suggested text which makes it clear that the quoting
is part of the encoding rather than the content.

> 6. Your restrictions on MUA quoting outlaw some valid addresses.

It does prevent the use of subaddresses with local parts that use
or contain control characters or NUL.  Is this a problem?

It also doesn't "outlaw" -- it only forbids generation of such addresses
and subaddress processing of such addresses in subaddress compliant
software.

> 8. ``MUST ignore subaddresses for the purposes of such validation'' is
> bizarre. If an MUA understands subaddresses, why shouldn't it validate
> them?

Good point.  How about "MUST ignore subaddresses for the purpose of
user validation"?

> 9. The requirement that list servers ignore subaddresses effectively
> prohibits the use of cryptographic cookies in return-path addresses for
> sender authentication.

I don't understand what you're saying.  Is there an RFC or Internet Draft
I can read on this topic?  Is there some reason cookies can't be computed
only on the primary address?

> 10. ``Delivered to that primary address'' is unclear.
> 
> 11. ``Owner of that primary address'' is unclear.
> 
> 12. ``Rewriting'' is unclear.
> 
> 13. ``Folder'' is unclear.
> 
> 14. ``Command line interpretor'' is unclear.

Ok, I'll work on clarifying those in the next draft.

If this is all you disagree with, then I gather this isn't a bad start on
the problem?

		- Chris

Date: 30 Jul 1997 20:16:40 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> I've written a spec for the subaddressing format which many people use.

Objections:

1. ``+'' is not the de facto standard; qmail's ``-'' is in wider use by
several measures. (The separator is configurable by the sysadmin, but
most people stick to dash, which I recommend for a variety of reasons.)

2. The requirement that foo-bar be delivered to foo ``by default'' is
violated by qmail. Of course, I make it easy to set that up; but I think
that bouncing is the right default.

3. The requirement that foo-bar be delivered to foo ``by default'' is
violated by any delivery agent that doesn't support subaddressing. What
is the point of a requirement that nobody can rely on?

4. The requirement that foo-bar be delivered to foo ``by default'' is a
violation of the as-if principle. Again, what is the point of a
requirement that nobody can rely on?

5. The ``canonically quoted'' section confuses content with encoding.
Any delivery agent that uses your syntax is almost certainly violating
RFC 822, section 3.4.4. The correct rule is very simple: any nonempty
string of ASCII characters is a valid local part. RFC 821 and RFC 822
specify encodings of those strings for SMTP and mail headers.

6. Your restrictions on MUA quoting outlaw some valid addresses.

7. Your restrictions on MUA quoting produce incorrect results for _all_
quoted addresses when the MTA handles quoting correctly. MMDF and qmail
handle quoting correctly.

8. ``MUST ignore subaddresses for the purposes of such validation'' is
bizarre. If an MUA understands subaddresses, why shouldn't it validate
them?

9. The requirement that list servers ignore subaddresses effectively
prohibits the use of cryptographic cookies in return-path addresses for
sender authentication.

10. ``Delivered to that primary address'' is unclear.

11. ``Owner of that primary address'' is unclear.

12. ``Rewriting'' is unclear.

13. ``Folder'' is unclear.

14. ``Command line interpretor'' is unclear.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Wed, 30 Jul 1997 11:24:52 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Email Subaddressing
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

I've written a spec for the subaddressing format which many people use.
I'd very much appreciate discussion/feedback for the draft.  I re-sent the
announcement to this list.

		- Chris

Date: Wed, 30 Jul 1997 11:21:43 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Originator-Info header
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

I've had the spec for Originator-Info around for just over 6 months.  I
just forwarded the announcement for the slightly revised version to this
list.  I'm inclined to ask for a four-week last call on the proposal.
Anyone on this list have any comments?

		- Chris

Date: Wed, 30 Jul 1997 09:36:17 -0400
From: [email-masked]
Subject: I-D ACTION:draft-newman-email-subaddr-00.txt
To: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.                                                              

       Title     : Internet Email Subaddressing                            
       Author(s) : C. Newman
       Filename  : draft-newman-email-subaddr-00.txt
       Pages     : 7
       Date      : 07/29/1997

It is often useful for a single user to have multiple email addresses which
can be used to assist categorizing incoming email.  One way of doing this 
is to divide the local-part of an email address into a primary address and 
a subaddress.  The primary address is used to route the message within the 
specified domain and the subaddress is used to route the message according 
to a particular user's wishes.                       

This specification formalizes the de-facto standard for subaddressing 
in use today and includes advice and requirements for final delivery 
agents, MUAs and mail list servers which wish to support subaddressing.                          

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-newman-email-subaddr-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-email-subaddr-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-newman-email-subaddr-00.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-newman-email-subaddr-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-newman-email-subaddr-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 30 Jul 1997 09:36:22 -0400
From: [email-masked]
Subject: I-D ACTION:draft-newman-msgheader-originfo-01.txt
To: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories.                                                              

       Title     : Originator-Info Message Header                          
       Author(s) : C. Newman
       Filename  : draft-newman-msgheader-originfo-01.txt
       Pages     : 6
       Date      : 07/29/1997

This proposal is an attempt to provide a standard header to indicate 
information about the message originator without implying that there is a 
deliverable mailbox or mandating that internal network information be 
revealed.  The "Originator-Info" header is intended to make the "X-Sender" 
and "X-X-Sender" headers obsolete.                                         

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-newman-msgheader-originfo-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-msgheader-originfo-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-newman-msgheader-originfo-01.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-newman-msgheader-originfo-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-newman-msgheader-originfo-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: 19 Jul 1997 00:16:28 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

Sorry if my sarcasm wasn't obvious. I don't agree with Metzger; I think
Metzger is an idiot.

> b) Malicious user gets his copy, and sends you *directly* something altered,
> but with the same message-id.

A different attack, less commonly exploitable but much more reliable, is
in the following situation:

   From: [email-masked]
   To: [email-masked], [email-masked]

If both isp.net and host.edu are running sendmail, the attacker can run
a program that sends a prepared message to mailing-list, copying your
Message-ID, and then pauses for a few seconds.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked]
Subject: Re: best name for followups? 
From: [email-masked]
Date: Fri, 18 Jul 1997 11:35:19 -0400
Sender: [email-masked]

--==_Exmh_1921422892P
Content-Type: text/plain; charset=us-ascii

On 18 Jul 1997 00:28:50 -0000, you said:
> > A simple comparison of message-ids does not suffice; it creates
> > an interesting security hole.
> People here may not realize that noted security expert Perry Metzger
> disagrees. Excerpted from his DRUMS commentary in March 1996: ``It is
> not a security hole, Mr. Bernstein. ... Don't teach granpaw to suck
> eggs. I make my bread and butter as a security consultant.''

Actually, there *is* a boundary condition that is problematic (and which I've
seen the scenario happen *quite* often).  Assume the following:

1) A large mailing list (1000+ or so people, perhaps)
2) A malicious user towards the front of the list
3) Your entry is towards the bottom of the list.

The following can happen:

a) Poster Fred sends something to the mailing list
b) Malicious user gets his copy, and sends you *directly* something altered,
but with the same message-id.  Your copy is still in the queue at the mailing
list site.
c) Your *real* copy arrives, and is tossed because the same Message-ID: has
been seen before.

How do I know this scenario can happen? Because I quite regularly receive
replies to my postings on some lists before I see my posting come back from
the list.  Obviously, the person replying has gotten his copy long before
I get mine back.

Of the last 9,704 e-mail messages I've received, procmail discarded 399 as
having duplicate message-id: headers.  And as I wrote this, I found a bug
in my procmailrc which greatly reduced the effectiveness of the duplicate
checking (explaining why I was still often seeing what looked like things
I've seen before).

Putting it all together is left as an excersize for the reader....
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_1921422892P
Content-Type: application/pgp-signature

--==_Exmh_1921422892P--

Date: 18 Jul 1997 00:28:50 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> A simple comparison of message-ids does not suffice; it creates
> an interesting security hole.

People here may not realize that noted security expert Perry Metzger
disagrees. Excerpted from his DRUMS commentary in March 1996: ``It is
not a security hole, Mr. Bernstein. ... Don't teach granpaw to suck
eggs. I make my bread and butter as a security consultant.''

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: Keith Moore <[email-masked]>
To: [email-masked] (Keld J|rn Simonsen)
cc: "Bart Schaefer" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Subject: Re: best name for followups? 
Date: Thu, 17 Jul 1997 02:49:19 -0400
Sender: [email-masked]

> Further ideas to avoid looking at more than one copy of the same
> mail sent to multiple email exploders:
> 
> 1. the MTA should look at all headers in the to: and cc: fields
> and if there is duplicates, then only send it once.

This has some interesting consequences.  Let's say I want to send
a note to this list but to keep you from getting a copy.  I compose
a message with both [email-masked] and [email-masked] in the
To field, but with only one recipient in the envelope: [email-masked].
The list gets the message, looks at the To: line, decides that you
are getting a copy of the message by another path, and so doesn't
send you a copy.  Since I didn't send you a copy either, you don't
get one.

> 2. The MUA could look at messages and remove those occurring
> more than once.

This more-or-less works, but implementation is tricky.   

A simple comparison of message-ids does not suffice; it creates
an interesting security hole.  Again assume I want to send a message
to the list, but I don't want you to receive it.  So I create two 
different messages with the same message-id.  One of them I send to
you.  The other one I send to the list.  When your MUA gets the 
second message, it discards it, because it's already seen a message
with that message-id.

So you want something that compares not just message-ids, but
messages.  (message-ids can be used as a key to find potential 
duplicates) The top few received headers will of course be different,
so remove them from the comparison.  Also remove headers commonly
added by lists like Precedence and Errors-To.  If none of the message 
paths munged the content, the UA can easily detect duplicates.  But if
one path munged the reply-to field, or rewrote 
<[email-masked]> to "moore" <[email-masked]> or
changed 8bit mime to 7bit, or changed boundary markers, or changed
content-transfer-encodings, or translated character sets, or converted
plain text to html (yeech), it becomes more difficult to recognize
two messages as the same. 

For my personal message store, a simple comparison (not counting a
few well-chosen top-level headers) seems to work quite well.
But this would vary considerably from one user to another.  It would 
not work for lists that do extensive header munging.  ( other 
approaches at duplicate suppression also fail in the presence of
some kinds of list munging.)

Keith

Date: 16 Jul 1997 10:24:54 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> Assuming even 90% of the MUAs are updated to support a followup field,
> how robust will it be if somebody in the 10% uses the bcc chainsaw
> instead?

If you leave out the new field, you get the same response from new MUAs
as you do from old MUAs.

> (a) has anybody considered reply/forward and the difference between
> them for followups?

It's always annoying when you want to retroactively change the recipient
list in a message. You can send a new message, but that's annoying for
the recipients, and some klutz will respond to the old message anyway.

The same problem arises now if you make a typo in your recipient list.
One solution is to add a level of indirection---hide all the recipients
behind a mailing list---but this is often inconvenient.

> more than one posting (possibly with divergent followups).

Some MUAs let you reply or follow up to several messages at once. They
simply merge the recipient lists.

> (c) we also need to think about if we *do* create a new Followup:
> header, what its interactions with bcc: and disclosing the recipient
> list really are

The first question is what the visible RFC 822 header should contain.
A _blind_ carbon copy has no effect here.

The second question is who the user wants to send blind copies to. He
can decide that for himself.

What's the problem?

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

To: [email-masked]
Subject: Re: best name for followups? 
From: [email-masked]
Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="<[email-masked]>"
Date: Wed, 16 Jul 1997 04:51:31 -0400
Sender: [email-masked]

(Warning: 4:30Am rambling ahead ;)

On 15 Jul 1997 21:39:58 -0000, you said:
> > What is the desired behavior if person A posts to a mailing list, and person
> > B follows up, etc etc - and then person G replies to F, trims out persons
> > A through E, and does a *BCC:* to the mailing list?
> 
> People do this as a crude way to control followups. Given widespread
> support for a followup field, why would someone do such a Bcc?

That's not the question I meant to ask.  What I *meant* to ask was:

Assuming even 90% of the MUAs are updated to support a followup field,
how robust will it be if somebody in the 10% uses the bcc chainsaw
instead?

I see any algorithm that basically merges the from/to/cc's (with
poissibly additional local knowledge) as being very crippled if a bcc
attack occurs.  On the other hand, a Followup: header will be a bit
more robust - if the user's MUA doesn't support followup:, the header
will likely not even be displayed by default, so naive users can nuke
and bcc: to heart's content (at least in regards to "forward"ing a
piece of mail.

How robust does it *need* to be?  Is "95% effective duplicate suppression" 
good enough? Or do we want to be hard-line, and design it so people can
get the followup correct even after significant user mangling of headers?

A few more random thoughts: 

(a) has anybody considered reply/forward and the difference between
them for followups?  Is the usual "Just add soem Resent- tags" scheme
the Right Way to do this, or does forwarding require fixing up the Followup:?

(b) what are the semantics of followups for an email that ends up
encapsulated as a message/rfc822 in a digest or similar?  Note that the
digest itself may have no followups, but you can then proceed to cite
more than one posting (possibly with divergent followups). What about a
message/partial if the parts have disagreeing Followup:s?

(c) we also need to think about if we *do* create a new Followup:
header, what its interactions with bcc: and disclosing the recipient
list really are (yes, I know different MTAs handle concealing bcc:
differenty - this just has the potential of making it even worse).

(Why would someobdy want to do that? I can easily see somebody sending
out something "official", and bcc:ing his boss, and adding the boss to
the Followup: so that the boss can lurk in the subsequent discussion.
Bad move if the boss wanted to *really* lurk. Yes, better handled in
other ways. Yes, users will do it anyhow ;)

/Valdis (who is just awake enough to think of boundary conditions
that he can't solve ;)

Date: 15 Jul 1997 21:39:58 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> What is the desired behavior if person A posts to a mailing list, and person
> B follows up, etc etc - and then person G replies to F, trims out persons
> A through E, and does a *BCC:* to the mailing list?

People do this as a crude way to control followups. Given widespread
support for a followup field, why would someone do such a Bcc?

The normal use of a blind copy is to add someone to the envelope
recipient list, without affecting what the (non-blind) recipients see.
So, in general, a Bcc isn't relevant to the rest of the header.

> a bcc: to the author because his list membership is unknown

That's arrogant behavior. Your followup is important enough to get to
him, but subsequent followups aren't?

Given widespread support for a followup field, you won't have to do this
sort of guesswork.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

To: [email-masked] (Keld J|rn Simonsen)
Cc: [email-masked]
Subject: Re: best name for followups? 
From: [email-masked]
Date: Tue, 15 Jul 1997 11:47:36 -0400
Sender: [email-masked]

--==_Exmh_-1011704128P
Content-Type: text/plain; charset=us-ascii

On Tue, 15 Jul 1997 11:03:05 +0200, Keld J|rn Simonsen said:
> Of cause you cannot do it in that case, but if you see 
> for example my address on the explicit From: or To: list, and later 
> see the same address in the list data, you can avoid sending the latter.

Hmm.. I see Keld, I see Bart, I see Keith, I see some guy named ietf-822.
I certainly don't see 'keld' *inside* the ietf-822 list, since I don't expand
it.

On Tue, 15 Jul 1997 10:42:56 +0200, Keld J|rn Simonsen said:
>> What if the author isn't a subscriber? Now you've eliminated him from
>> the recipient list. What if he wanted to receive a copy?
>Then you use the reply-all

This doesn't work if you don't have a *clue* who is on the list.  Citing
the mail for ietf-822 in the last few days (or rather, some that's in that
folder), I know I'm on the list, I can be pretty sure that Keld Simonsen,
D.J. Bernstein, and Keith Moore are on the list.  However, I posted a note
last week about "some vendors just don't get it", and I have *no* idea if
Doug Strauss and Larry Osterman (both of Microsoft(*))  are on the list, or
were merely forwarded a copy of my mail.

In any case, there's something that everybody has overlooked (perhaps
intentionally as a "we don't need to bother", or intentionally because
it's a can of worms, or just oversight ;)

What is the desired behavior if person A posts to a mailing list, and person
B follows up, etc etc - and then person G replies to F, trims out persons
A through E, and does a *BCC:* to the mailing list? (or vice versa - sending
to the list, and a bcc: to the author because his list membership is unknown)

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

(*) Incidentally, the people at Microsoft were quite helpful in tracking
down when/how the bug I commented on originated, and I assume that it
is being chased down by their software teams.

--==_Exmh_-1011704128P
Content-Type: application/pgp-signature

--==_Exmh_-1011704128P--

Date: 15 Jul 1997 09:56:48 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> But I am saying that with two simple MUA commands
> you may obtain much of the same results

My MUA already makes it very easy to manually edit the recipient list.
But this completely misses the point. I _do not want_ to manually edit
the recipient list. I want my MUA to provide the right list by default.

The reason my MUA doesn't do this is much more basic than a mere matter
of user interface design. There is a fundamental problem: _the necessary
information is not available_. How does the MUA figure out the list?

Saying ``make the choice manually''---putting the burden on me instead
of my MUA---begs the question. How do _I_ figure out the list?

Your proposal makes no progress towards an answer.

> you know what the recipients are on each list.

For large lists this is an unreasonable assumption.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

From: [email-masked] (Keld J|rn Simonsen)
Date: Tue, 15 Jul 1997 11:03:05 +0200
Mnemonic-Intro: 29
To: [email-masked]
Subject: Re: best name for followups?
Cc: "Bart Schaefer" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

[email-masked] writes:

> On Tue, 15 Jul 1997 00:59:45 +0200, Keld J|rn Simonsen said:
> > 1. the MTA should look at all headers in the to: and cc: fields
> > and if there is duplicates, then only send it once.
> 
> Keld:  How does the MTA distinguish duplicates for this message,
> which is going to dkuug.dk, brasslantern.com, utk.edy, imc.org,
> and a local copy to myself?  To *my* MTA they all look distinct.
> And by the time it reaches any other MTA, it's too late.

Of cause you cannot do it in that case, but if you see 
for example my address on the explicit From: or To: list, and later 
see the same address in the list data, you can avoid sending the latter.

> > 2. The MUA could look at messages and remove those occurring
> > more than once.
> 
> Of course, we'd rather avoid having the MUA having to suppress
> 57 copies, after having *received* 57 copies over a possibly slow link,
> etc etc. ;)

My time is much more expensive than the line costs.

My proposals are not something that removes all problems, 
but they can make life easier, actually much easier, if employed.

Keld

To: [email-masked] (Keld J|rn Simonsen)
cc: "Bart Schaefer" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: best name for followups? 
From: [email-masked]
Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="<[email-masked]>"
Date: Tue, 15 Jul 1997 04:44:37 -0400
Sender: [email-masked]

On Tue, 15 Jul 1997 00:59:45 +0200, Keld J|rn Simonsen said:
> 1. the MTA should look at all headers in the to: and cc: fields
> and if there is duplicates, then only send it once.

Keld:  How does the MTA distinguish duplicates for this message,
which is going to dkuug.dk, brasslantern.com, utk.edy, imc.org,
and a local copy to myself?  To *my* MTA they all look distinct.
And by the time it reaches any other MTA, it's too late.

> 2. The MUA could look at messages and remove those occurring
> more than once.

Of course, we'd rather avoid having the MUA having to suppress
57 copies, after having *received* 57 copies over a possibly slow link,
etc etc. ;)

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

From: [email-masked] (Keld J|rn Simonsen)
Date: Tue, 15 Jul 1997 10:42:56 +0200
Mnemonic-Intro: 29
To: "D. J. Bernstein" <[email-masked]>, [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

"D. J. Bernstein" writes:

> > Well, if you know the author, and want to relieve him/her from
> > getting extra mail, then you use the new command.
> 
> What if the author isn't a subscriber? Now you've eliminated him from
> the recipient list. What if he wanted to receive a copy?

Then you use the reply-all

> The discussion is about how the author can express his wishes in a form
> that your MUA can use automatically.

I understand. But I am saying that with two simple MUA commands
you may obtain much of the same results - given that you know
as a user what you are doing and you know what the recipients are
on each list. This is just based on my own experiences and irritations:

1. a MUA command responding to the To: and Cc: fields: "reply-receivers"
"reply-recievers" is useful whan you know that the the sender is
on the recievers-list too.

2. a MUA command responding to the To: field: "reply-to"
The "reply-to" command is useful when you think that the cc-list is
only for initial awareness, and further discussion is only for the
people on the To: list

Keld

Date: 15 Jul 1997 01:23:56 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> Well, if you know the author, and want to relieve him/her from
> getting extra mail, then you use the new command.

What if the author isn't a subscriber? Now you've eliminated him from
the recipient list. What if he wanted to receive a copy?

The discussion is about how the author can express his wishes in a form
that your MUA can use automatically.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: 15 Jul 1997 01:14:18 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> With the Followup-To, it's almost
> certainly going to have to be hand-edited by the sender:

http://pobox.com/~djb/replyto.html says how an MUA can automatically
create this field.

The only prerequisite is that your MUA know what mailing lists you're
subscribed to. (The fundamental problem is obviously insoluble without
this information.)

> It seems to me that Dont-Reply-To would be a bit easier to automate.

It would require substantially more code for the common case. I haven't
seen any examples where the extra flexibility would be useful. KISS.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: Mon, 14 Jul 1997 19:09:27 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: best name for followups?
Sender: [email-masked]

On 7/10/97 at 1:32 AM -0500, Keith Moore wrote:

>I thought about proposing a header of the form
>
>Dont-Reply-To: <[email-masked]> if-replying-to <[email-masked]>
>
>which essentially says: if you're sending a reply which would
>otherwise be addressed to both [email-masked] and address [email-masked], leave
>[email-masked] out of the recipient list of that reply.

I actually like this idea a bit better than a Followup-To field. It seems
to me that Dont-Reply-To would be a bit easier to automate. We're talking
about putting a feature into our mailer which keeps track of mailing lists
to which the user is subscribed. With a Dont-Reply-To field, we could
generate one of those if any of the recipients of the message were in the
list of subscribed mailing lists. With the Followup-To, it's almost
certainly going to have to be hand-edited by the sender: If the user
replies to a message that *doesn't* have this header and there are some
recipients who don't belong to the mailing list, it's not clear to me how
to figure out whether or not it is a good thing to copy them into the
Followup-To field or not. With Dont-Reply-To, you're giving explicit
instruction to the remote mailer about what to do with a reply-to-all
command. It just seems a little cleaner.

It clearly doesn't have the fine-grained control to be able to redirect the
thread to somewhere else, but I get the feeling that the more likely reason
to use any of these headers is to say "don't send an extra copy to me".

>- It does require the sender's UA to be smart about when to add the
>  Dont-reply-to header on outgoing mail.

It could always be added by hand, but it makes it somewhat easier to add in
an automated fashion.

>- It opens the possibility of loops: what does a UA do if it sees
>
>  Dont-reply-to: <x> if-replying-to <y>
>  Dont-reply-to: <y> if-replying-to <z>
>  Dont-reply-to: <z> if-replying-to <x>
>
>  In this case, it's safe to ignore all of the headers.

(*Shrug*) People can generate crappy headers all the time that screw up
remote UAs. I know what a reasonable one of these is supposed to do.

>- There's nothing to stop lists from munging this header.  Some
>  lists might want to be "smart" and add Dont-Reply-To headers for
>  any message sent from a list member.  Some people would like this,
>  since they'd get the benefits of Dont-Reply-To without having
>  to change their UA.  Some people (like me) wouldn't want the list
>  to add such a header.

I think this is less of a concern. Unlike current Reply-To munging, where
the purpose is to be "helpful" to get discussion on the list, this header
is "helpful" in the opposite direction. I'm not convinced list-admins are
going to be as motivated to do this.

>- It doesn't solve the two-list problem

Neither does any other solution as far as I can tell.

>Personally, I don't think it's worth it: there's not enough to be
>gained for the trouble, and duplicate suppression is more effective
>(solves the problem in more cases) and easier to deploy (only requires
>support for the recipient who wants to suppress multiple messages, and
>that recipient reaps the reward for his own effort).  If more UAs had
>duplicate suppression there would be very minimal additional gain to
>be had from Dont-Reply-To or similar proposals.

I don't think it's a bad idea, actually. Duplicate suppression is fine, but
you still have to spend the time and resources receiving the duplicate
messages. This way, the duplicate never even gets sent.

I think it's worth thinking about.

pr

--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980

From: [email-masked] (Keld J|rn Simonsen)
Date: Tue, 15 Jul 1997 02:00:14 +0200
Mnemonic-Intro: 29
To: "D. J. Bernstein" <[email-masked]>, [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

"D. J. Bernstein" writes:

> > My 2 cents: make a new command in UAs that replies to the
> > to: field and the cc: field, (but not the from field)
> > thus avoiding two messages sent to the author of the From: message.
> 
> What if the author isn't included in To/Cc?
> 
> For example, what if To is a mailing list, and From is a non-subscriber?
> 
> How is a user supposed to decide whether to use the old reply-to-all
> command or your new reply-to-recipients command?

Well, if you know the author, and want to relieve him/her from
getting extra mail, then you use the new command.

Keld

From: [email-masked] (Keld J|rn Simonsen)
Date: Tue, 15 Jul 1997 00:59:45 +0200
Mnemonic-Intro: 29
To: "Bart Schaefer" <[email-masked]>, Keith Moore <[email-masked]>
Subject: Re: best name for followups?
Cc: [email-masked]
Sender: [email-masked]

Further ideas to avoid looking at more than one copy of the same
mail sent to multiple email exploders:

1. the MTA should look at all headers in the to: and cc: fields
and if there is duplicates, then only send it once.

2. The MUA could look at messages and remove those occurring
more than once.

Keld

Date: 14 Jul 1997 23:05:33 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> My 2 cents: make a new command in UAs that replies to the
> to: field and the cc: field, (but not the from field)
> thus avoiding two messages sent to the author of the From: message.

What if the author isn't included in To/Cc?

For example, what if To is a mailing list, and From is a non-subscriber?

How is a user supposed to decide whether to use the old reply-to-all
command or your new reply-to-recipients command?

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

From: [email-masked] (Keld J|rn Simonsen)
Date: Tue, 15 Jul 1997 00:30:52 +0200
Mnemonic-Intro: 29
To: "Bart Schaefer" <[email-masked]>, [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

"Bart Schaefer" writes:

> On Jul 8, 11:54pm, D. J. Bernstein wrote:
> } Subject: Re: best name for followups?

My 2 cents: make a new command in UAs that replies to the
to: field and the cc: field, (but not the from field)
thus avoiding two messages sent to the author of the From: message.

Keld

Date: 11 Jul 1997 05:17:03 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Bart's reading comprehension
Sender: [email-masked]

Correcting typo:

: As I said, this requires that reply-to-author ignore the From address.

That should say ``Reply-To address.''

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

From: Keith Moore <[email-masked]>
To: "Bart Schaefer" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: best name for followups? 
Date: Thu, 10 Jul 1997 16:19:02 -0400
Sender: [email-masked]

> } Actually I believe that UAs should encourage people to *select* the
> } recipient list of *every* reply which would otherwise be addressed to
> } more than one recipient.  Of course, they should make the recipient
> } (the one issuing the reply) aware of the sender's preference, as
> } expressed through the reply-to field from the subject message.
> 
> That's all nice in the abstract, but I was just discussing this today
> with several of my co-workers, and they all agreed that they hate it
> when their UA asks them questions or requires that sort of extra action.

Yeah, I hate it too.  But I'm not sure that it can't be done in a
way which is both convenient and effective.

I'm imagining a reply interface where my UA pops up an editing window
and shows me every recipient to which the reply might be addressed,
with the "selected" recipients in normal text and the "unselected"
recipients in dim/gray text.  There might also be some sort of
indication (color?) as to where the recipient address came from (From,
To, Cc, Reply-To).  The "reply" button would then pop up an editing
window with the default set of recipients selected, but there would be
buttons to select other behaviors (like reply-to-sender only), and I
could click on any recipient to toggle the selected bit.

Guess I'll have to code it up and try it...

> } It's an open question as to whether UAs that encourage such behavior
> } can be successful in the market...users would probably rather be lazy
> } than aware, even if they occasionally get bitten for being lazy.
> 
> You have the right of it there.  The best thing is for UAs to get better at
> providing a complete, yet minimal, set of "default" addresses.

I'm not sure what this would mean.  "Complete", for example, is highly
dependent on the context in which a message is sent -- something the
UA isn't likely to know about.

> } At any rate, I suspect we're going to end up with some sort of
> } List-Address or List-Reply-To header, along with List-Subscribe,
> } List-Unsubscribe etc.  It's easy to do, and there was a lot of support
> } for it at the listhdr BOF at the Memphis IETF.
> 
> I see how this might solve the multiple-copies problem for those who are
> on the list.  How does it solve the lack-of-any-copy problem for those
> who are NOT on the list?

It won't.  But we'll probably end up with a List-Address header for
other reasons.  Once it's there, UAs will probably acquire "reply to
list" commands.  We should probably specify in the List-Address field
defintiion that UAs MUST NOT use the List-Address field for the
default reply.

> } I thought about proposing a header of the form
> } 
> } Dont-Reply-To: <[email-masked]> if-replying-to <[email-masked]>
> 
> I think this is nasty from the user interface point of view, because of
> the very effect that you give as its first advantage:
> 
> } + It doesn't change the user interface for the guy issuing the
> }   reply.  He just says 'reply' or "reply to author" or reply to
> }   author+to+cc or whatever he says now, and the user agent does
> }   this, but leaving out the redundant addresses.
> 
> Just because users generally don't notice where replies are going doesn't
> mean that they never notice.  Some user is going to see two messages that
> appear to be identical -- they have the same To/From/Cc -- but then when
> he replies to one of them, the To address is NOT included, yet when he
> replies to the other, that same address in the same field IS included.
> 
> How does the UA explain that inconsistency?  By showing the user that
> horrible-looking header?  Please no.  The inconsistency and having that
> header visible would both be nightmares; I can't decide which is worse.

The only way to know is to test it.  But the confusion doesn't seem
(to me) to be any worse than that which would result from Followup-To
or Reply-Cc.

I agree that reply generation should be based on simple rules that a
user can understand.  Ideally they should be the same for most UAs.

> } - There's nothing to stop lists from munging this header.
> 
> There's also nothing to stop MTAs from munging other headers, so that
> it becomes necessary to equate <[email-masked]> with <[email-masked]> and
> other such lunacy.  I think anything involving address comparisons is
> doomed to failure.

Good point.  The rewriting situation is better than it used to be,
(not so many sendmails rewrite addresses anymore), but it's common
for firewalls to rewrite addresses to hide internal domains.

> } If more UAs had
> } duplicate suppression there would be very minimal additional gain to
> } be had from Dont-Reply-To or similar proposals.
> 
> But duplicate suppression doesn't solve the lack-of-any-copy problem.
> There still needs to be a way to say "please DO send me a copy," and to
> do so without having the list server stomp on it.

By that logic, we can't solve the problem by adding a new header.
There is almost no header that some list server or gateway won't stop
on.  Each of the following behaviors is, I believe, quite common:

+ adding or changing the sender header
+ adding a reply-to header
+ changing a sender-supplied reply-to header
+ removing certain headers (e.g. received)
+ removing all headers except those in a stop-list
+ adding headers (comments, x-list-*, precedence, errors-to)
+ rewriting header addresses (in to, from, cc headers)
+ munging the subject header
+ don't send me a copy of the list mail if I'm already in
  the to/cc header.

On the other hand, if we can discourage certain of these behaviors,
then it becomes reasonable to say something like "lists SHOULD NOT
mung a sender-supplied Reply-To header", which in turn provides a way
for a sender to say "please DO send me a copy of the reply" which is
compatible with existing UAs.

Keith

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 10 Jul 1997 12:34:35 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Bart's proposal" (Jul 10,  5:52pm)
To: [email-masked]
Subject: Re: Bart's proposal
Sender: [email-masked]

On Jul 10,  5:52pm, D. J. Bernstein wrote:
} Subject: Re: Bart's proposal
}
} > My proposal can be implemented (for example) as a `copy me on replies'
} > toggle in the user interface.
} 
} That would work with all of the proposals here. You claim that it is an
} advantage of your proposal; you are wrong.

It's not that specific item that I'm claiming as an advantage of my
proposal; I explicitly said that your proposal could support this as well:

>>after [Reply-Destinations] is properly initialized with the addresses of
>>all the mailing lists [the author can] be added or removed upon request.

} > Your proposal requires the UA to identify addresses that are mailing lists
} > and include them in the Reply-Destinations (or whatever you call it) field.
} 
} Wrong. The correct algorithm is as follows. If the MUA knows that the
} user has subscribed to a mailing list shown in To+Cc, it automatically
} excludes him from subsequent followups. Otherwise it leaves him in.

And the rest of the algorithm is that every address in To and Cc is also
duplicated in Reply-Destinations?  Ok.

Then the advantage of my proposal is that it doesn't duplicate all that
information.  That could also be a disadvantage if you assume that the
Reply-Destinations field is less likely to be munged in transit than are
the To and Cc fields.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

To: [email-masked]
Subject: Some vendors Just Dont Get It.
From: [email-masked]
Date: Thu, 10 Jul 1997 14:25:11 -0400
Sender: [email-masked]

--==_Exmh_2010360596P
Content-Type: text/plain; charset=us-ascii

Spotted this nice little bunch of headers today:

X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1157
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

(A) What's wrong with this picture? ;)
(B) Anybody know who to flame at microsoft?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_2010360596P
Content-Type: application/pgp-signature

--==_Exmh_2010360596P--

Date: 10 Jul 1997 17:52:55 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Bart's proposal
Sender: [email-masked]

> My proposal can be implemented (for example) as a `copy me on replies'
> toggle in the user interface.

That would work with all of the proposals here. You claim that it is an
advantage of your proposal; you are wrong.

> Your proposal requires the UA to identify addresses that are mailing lists
> and include them in the Reply-Destinations (or whatever you call it) field.

Wrong. The correct algorithm is as follows. If the MUA knows that the
user has subscribed to a mailing list shown in To+Cc, it automatically
excludes him from subsequent followups. Otherwise it leaves him in.

This, too, would work with all of the proposals here.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 10 Jul 1997 10:07:50 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Bart's proposal" (Jul 10,  4:48pm)
To: [email-masked]
Subject: Re: Bart's proposal
Sender: [email-masked]

On Jul 10,  4:48pm, D. J. Bernstein wrote:
} Subject: Re: Bart's proposal
}
} > My proposal extends both reply and reply-to-all, labels the change, and
} > requires no new knowledge in sending MUAs.
} 
} Nonsense. Your proposed field requires the same knowledge to set up as
} mine does.

My proposal can be implemented (for example) as a `copy me on replies'
toggle in the user interface.  Switch it on, a Reply-Cc field is put in;
switch it off, no Reply-Cc field is put in.

Your proposal requires the UA to identify addresses that are mailing lists
and include them in the Reply-Destinations (or whatever you call it) field.
Only after that field is properly initialized with the addresses of all the
mailing lists can the author be added or removed upon request.

} The difference is that I preserve reply-to-author, while you destroy it.

Destroy it how?  If Reply-Cc contains the author's address but Reply-To does
not (because the mailing list munged it), it seems to me that I'm preserving
reply-to-author in a case where it presently is not preserved.

} Hey, Bart, did you know that your MUA has _two_ response functions?
} Perhaps you should learn how to use them.

I could start sending you two copies of all these messages, but I thought
you'd rather I didn't.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 10 Jul 1997 09:44:48 -0700
Comments: In reply to Jamie Zawinski <[email-masked]> "Re: best name for followups?" (Jul 10,  3:24am)
To: Jamie Zawinski <[email-masked]>, [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

On Jul 10,  3:24am, Jamie Zawinski wrote:
} Subject: Re: best name for followups?
}
} Bart Schaefer wrote:
} > 
} > The fundamental problem is NOT the behavior of reply-to-all.  The
} > *really* fundamental problem is that reply-to-all is the wrong
} > function to be using in the first place.
} 
} My MUA has two commands, "Reply to author" and "Reply to all".
} The former sends to (Reply-To -or- From) and the latter sends to
} ((Reply-To -or- From) -and- To -and- CC).
} 
} I think this is the universally implemented status quo.  I gather
} that Bart thinks this is wrong behavior, but this is that this is 
} what -every- MUA I've ever seen does.

No, I don't think this is wrong behavior.  I think this is right.

What I think is wrong, is that reply-to-all is (a) the "most convenient"
reply action in many UAs, and (b) necessary in too many circumstances,
because of those headed for that special circle in hell you mentioned.

} And I really wish, given the vast installed base, the standard
} spelled this out.

I agree with that, too.

} > } I'm talking about convenient _default_ recipient lists. The user is
} > } of course free to send mail wherever he wants.
} > 
} > I'm talking about convenient default recipient lists, too.  The basic
} > reply command ought to be where one gets those convenient defaults. 
} > Reply-to-all ought to be the way the user sends mail wherever he wants
} > (e.g., find all the possible addresses for me, and let me edit some of
} > them out).
} 
} Uh, I think now you're talking about a disjoint set of commands:
} "Reply to convenient default recipients" and "Reply to all listed
} addresses".  I gather that you think the former list of addresses
} would be determined by some as-yet-unstandardized-or-otherwise-
} agreed-upon mechanism, and the latter would be something like
} (From + Reply-To + To + CC.)

In a world without mailing lists munging Reply-To, the former would be
controlled by the originator with a header like

	From: <real-author>
	Reply-To: <default-recipients>
	To: <destinations>

And you'd get it when you invoke "reply-to-author".  The latter would be
reply-to-all as it is now, regardless of what the headers look like.

I believe this is the correct behavior, and that the right solution is
to bypass Reply-To munging in the simplest possible manner.  I think the
simplest manner is to add a new header that augments Reply-To, rather
than adding a header that restricts reply-to-all.

} [...] this would result in a confusing change to every
} existing MUA: there would still be two reply commands, but they'd be
} totally different ones than before; or worse, there'd be four distinct
} reply commands.  Ugh!

No, I don't want the "new" commands to be totally different.  I want them
to be as nearly identical as possible to the current status quo.  In the
absence of the field that augments Reply-To, I want them to BE the status
quo.

} > Replies to address-list Y to follow up (case 2):
} > 
} >         From: <real-author>
} >         Reply-To: Y
} >         To: <destinations>
} 
} In that second case, this message has destroyed my ability to reply to
} just the author -- because every MUA in existence today has a command
} that replies to (Reply-To or From), and a command that replies to 
} ((Reply-To -or- From) -and- To -and- CC), but no command that even gives
} me the *opportunity* to reply to From (if Reply-To is present.)

Actually, both Mush and Z-Mail will let you ignore the Reply-To header if
you feel like it.  They'll let you reply to the Dogs-Go-To-Heaven header
if you tell them to.

} Perhaps this is what the author of that hypothetical message intended. 
} But if so, the author is a doofus.  

You can call him names if you want, but that's the way RFC822 defines the
mechanism for authors to control where replies go.  To bad mailing lists
made it insufficient.

} > The second thing required is that user agents interpret Reply-To in
} > such a way that *neither* `reply' nor `reply-using-destination-fields'
} > takes any addresses from the To field in the event that Reply-To is
} > present.
} 
} That is already the status quo.  Right?  (For all four of the possible
} reply commands that have been mentioned, or at least, the two (possibly
} three) of them that have ever been implemented in the real world.)

No, it's not the status quo.  It's the status quo for `reply'.  It is not
the status quo for `reply-to-all'.  The above describes the status quo
for `reply', but (Reply-To -or- (From -and- To -and- CC)) for reply-all. 
(It describes that because I'm explaining Keith's proposal, which you got
right a bit later.)

}   A:    (Reply-To -or- (From -and- To -and- CC)) 
}   B:    ((Reply-to -or- From) -and- To -and- CC).
} 
} My reading of RFC 822 (and, I gather, Bart's reading?) is that it does
} not favor one over the other, as it talks only about the "reply to
} author" command, and not the "reply to all recipients" command, which it
} relegates to the status of "extension."

Yup, that's my reading.

} Even if 822 *did* say that B was preferred to A, well, that's just too
} darned bad, because A got implemented and B did not [...]
} 
} Any attempt to address either "duplicate suppression" or "default
} addresses for wide and narrow replies" (which are two totally different
} problems that people have been (badly) attempting to address using the
} Reply-To header) has to take this status quo into account if it hopes to
} get anywhere at all.

I completely agree.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 10 Jul 1997 16:48:27 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Bart's proposal
Sender: [email-masked]

> Keith's proposal (as we're calling it, since he hasn't actually pronounced
> either of us correct in our interpretations) would change the way MUAs
> implement reply-to-all, but doesn't introduce new syntax.

It would also change how MUAs implement reply-to-author, destroying the
existing semantics of From and Reply-To.

> Dan's proposal changes reply-to-all and labels the change with new syntax,
> but requires knowledge of mailing-list membership on the part of sending
> MUAs in order to operate conveniently.
> My proposal extends both reply and reply-to-all, labels the change, and
> requires no new knowledge in sending MUAs.

Nonsense. Your proposed field requires the same knowledge to set up as
mine does. The difference is that I preserve reply-to-author, while you
destroy it.

> Dan's proposal encourages users to continue using reply-to-all, because a
> simple reply still won't do the job.  I think this is unfortunate.

Hey, Bart, did you know that your MUA has _two_ response functions?
Perhaps you should learn how to use them.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: 10 Jul 1997 16:30:43 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> Dan claims that after enough replies from different people, the
> recipeint lists get so long that mail sofware breaks.

I pointed out that this, among other problems, happens _by default_.

> While this is
> true in principle, I've never seen it happen in practice.

And you'd understand the reason if you had read my next paragraph: ``Of
course, people don't let the header grow so much. They trim it down to
just the list address. But this introduces some of the same problems as
reply-to munging; for example, it destroys cross-posted discussions.''

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: 10 Jul 1997 16:22:09 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Bart's reading comprehension
Sender: [email-masked]

> I'm not the one not paying attention.

Keith said ``allow a sender to separately specify'' the reply-to-author
address and the reply-to-all address.

``A sender.'' One sender. One message.

``Separately specify.'' That means specifying both. Keith explained that
the author can use From for one and Reply-To for the other.

So your examples are completely wrong. Here's what Keith described:

   From: X (the reply-to-author address)
   Reply-To: Y (the reply-to-all address)

As I said, this requires that reply-to-author ignore the From address.

> } > other than your willful misrepresentations.
> } Idiot.
> Yet another willful misrepresentation.

Idiot.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: Thu, 10 Jul 1997 03:24:38 -0700
From: Jamie Zawinski <[email-masked]>
Organization: Netscape Communications Corporation, Mozilla Division
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

Bart Schaefer wrote:
> 
> The fundamental problem is NOT the behavior of reply-to-all.  The
> *really* fundamental problem is that reply-to-all is the wrong
> function to be using in the first place.  The only reason that
> reply-to-all gets used, aside from the Berkeley Mail historical
> baggage of the meanings of `r' and `R' as commands, is because the
> simple reply function is unable to produce the correct result.

Huh?

My MUA has two commands, "Reply to author" and "Reply to all".
The former sends to (Reply-To -or- From) and the latter sends to
((Reply-To -or- From) -and- To -and- CC).

I think this is the universally implemented status quo.  I gather
that Bart thinks this is wrong behavior, but this is that this is 
what -every- MUA I've ever seen does.

And I really wish, given the vast installed base, the standard
spelled this out.

> } I'm talking about convenient _default_ recipient lists. The user is
> } of course free to send mail wherever he wants.
> 
> I'm talking about convenient default recipient lists, too.  The basic
> reply command ought to be where one gets those convenient defaults. 
> Reply-to-all ought to be the way the user sends mail wherever he wants
> (e.g., find all the possible addresses for me, and let me edit some of
> them out).

Uh, I think now you're talking about a disjoint set of commands:
"Reply to convenient default recipients" and "Reply to all listed
addresses".  I gather that you think the former list of addresses
would be determined by some as-yet-unstandardized-or-otherwise-
agreed-upon mechanism, and the latter would be something like
(From + Reply-To + To + CC.)

I think that's a monumentally bad idea.

Aside from not being even close to the behavior I'd want to see in an
MUA I was using (thanks, but reply-to-author and reply-to-recipients is
exactly what I like) this would result in a confusing change to every
existing MUA: there would still be two reply commands, but they'd be
totally different ones than before; or worse, there'd be four distinct
reply commands.  Ugh!

> For this to work as described, two things are required:  First, the
> author has to change From and leave out the Reply-To when he means
> "reply to address-list X if you want to just reply to me" and he must
> put in Reply-To exactly when he means "reply to address-list Y if you
> want to followup."  The fields look like this:
> 
> Replies to address-list X to reply to me (case 1):
> 
>         From: X
>         Sender: <real-author>
>         To: <destinations>
> 
> Replies to address-list Y to follow up (case 2):
> 
>         From: <real-author>
>         Reply-To: Y
>         To: <destinations>

In that second case, this message has destroyed my ability to reply to
just the author -- because every MUA in existence today has a command
that replies to (Reply-To or From), and a command that replies to 
((Reply-To -or- From) -and- To -and- CC), but no command that even gives
me the *opportunity* to reply to From (if Reply-To is present.): that
address would never appear in the defaultly-offered set of headers: one
would have to put it there with cut and paste.

Perhaps this is what the author of that hypothetical message intended. 
But if so, the author is a doofus.  

> The second thing required is that user agents interpret Reply-To in
> such a way that *neither* `reply' nor `reply-using-destination-fields'
> takes any addresses from the To field in the event that Reply-To is
> present.

That is already the status quo.  Right?  (For all four of the possible
reply commands that have been mentioned, or at least, the two (possibly
three) of them that have ever been implemented in the real world.)

Someone, I guess Keith, wrote:
>
> I realize that many UAs don't handle "reply-to-all" this way,
> in particular a lot of UAs use Reply-to only as a replacement for
> From.  But the DRUMS document already clarifies that reply-to is the
> author's preference as to where replies should be sent.

I haven't read the referred-to document, but for the sake of argument,
I'll take your word for it that it says that a MUA's "reply to all
recipients" command should reply to 

  A:    (Reply-To -or- (From -and- To -and- CC)) 

rather than the de-facto standard of 

  B:    ((Reply-to -or- From) -and- To -and- CC).

But if it says that, then its authors are operating in a delusional
fantasy world, because that's *not* going to happen.

My reading of RFC 822 (and, I gather, Bart's reading?) is that it does
not favor one over the other, as it talks only about the "reply to
author" command, and not the "reply to all recipients" command, which it
relegates to the status of "extension."

Even if 822 *did* say that B was preferred to A, well, that's just too
darned bad, because A got implemented and B did not, and if the standard
is to mean anything, it should be made to say A.  Unimplemented
standards are useful as objets d'art, but little else.

Any attempt to address either "duplicate suppression" or "default
addresses for wide and narrow replies" (which are two totally different
problems that people have been (badly) attempting to address using the
Reply-To header) has to take this status quo into account if it hopes to
get anywhere at all.

Me, I'd much rather live with duplicates than have mailing lists fuck up
my ability to reply to the author of a message without my "reply to
author" command suddenly (and surprisingly) behaving like my "reply to
all" command.  I just don't see the duplicates problem as being much of
a problem, nor do I see much of a need for a third reply-to-some-
default-set-of-recipients command.  But that's just me; if you want to
standardize and implement them, more power to you -- just don't break or
invalidate the installed base along the way!

(I'm sure that there's a special circle in hell for mailing list
managers who set the Reply-To field to point at the list.)

-- 
Jamie Zawinski    [email-masked]   http://www.netscape.com/people/jwz/
What the world needs now is killfiles that actually kill. -Craig Dickson

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 10 Jul 1997 00:15:45 -0700
Comments: In reply to Keith Moore <[email-masked]> "Re: best name for followups?" (Jul 10,  2:32am)
To: Keith Moore <[email-masked]>
Subject: Re: best name for followups?
Cc: [email-masked]
Sender: [email-masked]

On Jul 10,  2:32am, Keith Moore wrote:
} Subject: Re: best name for followups?
}
} Actually I believe that UAs should encourage people to *select* the
} recipient list of *every* reply which would otherwise be addressed to
} more than one recipient.  Of course, they should make the recipient
} (the one issuing the reply) aware of the sender's preference, as
} expressed through the reply-to field from the subject message.

That's all nice in the abstract, but I was just discussing this today
with several of my co-workers, and they all agreed that they hate it
when their UA asks them questions or requires that sort of extra action.
They don't care that some of the recipients are getting multiple copies;
they care that they can process their own mail very quickly with the
absolute minimum number of clicks and keystrokes.

} It's an open question as to whether UAs that encourage such behavior
} can be successful in the market...users would probably rather be lazy
} than aware, even if they occasionally get bitten for being lazy.

You have the right of it there.  The best thing is for UAs to get better at
providing a complete, yet minimal, set of "default" addresses.

} At any rate, I suspect we're going to end up with some sort of
} List-Address or List-Reply-To header, along with List-Subscribe,
} List-Unsubscribe etc.  It's easy to do, and there was a lot of support
} for it at the listhdr BOF at the Memphis IETF.

I see how this might solve the multiple-copies problem for those who are
on the list.  How does it solve the lack-of-any-copy problem for those
who are NOT on the list?

} I thought about proposing a header of the form
} 
} Dont-Reply-To: <[email-masked]> if-replying-to <[email-masked]>

I think this is nasty from the user interface point of view, because of
the very effect that you give as its first advantage:

} + It doesn't change the user interface for the guy issuing the
}   reply.  He just says 'reply' or "reply to author" or reply to
}   author+to+cc or whatever he says now, and the user agent does
}   this, but leaving out the redundant addresses.

Just because users generally don't notice where replies are going doesn't
mean that they never notice.  Some user is going to see two messages that
appear to be identical -- they have the same To/From/Cc -- but then when
he replies to one of them, the To address is NOT included, yet when he
replies to the other, that same address in the same field IS included.

How does the UA explain that inconsistency?  By showing the user that
horrible-looking header?  Please no.  The inconsistency and having that
header visible would both be nightmares; I can't decide which is worse.

} - There's nothing to stop lists from munging this header.

There's also nothing to stop MTAs from munging other headers, so that
it becomes necessary to equate <[email-masked]> with <[email-masked]> and
other such lunacy.  I think anything involving address comparisons is
doomed to failure.

} If more UAs had
} duplicate suppression there would be very minimal additional gain to
} be had from Dont-Reply-To or similar proposals.

But duplicate suppression doesn't solve the lack-of-any-copy problem.
There still needs to be a way to say "please DO send me a copy," and to
do so without having the list server stomp on it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

From: "Bart Schaefer" <[email-masked]>
Date: Wed, 9 Jul 1997 23:48:02 -0700
To: [email-masked]
Subject: Re: Bart's proposal
Sender: [email-masked]

[ Again I'm cutting and pasting from the imc archive. ]

On 9 Jul 1997, D. J. Bernstein ([email-masked]) wrote:
} Your proposal does not solve the fundamental problem: the reply-to-all
} addresses always include the reply-to-author addresses.
} 
} Think about the usual case of a subscriber sending a message to a
} mailing list. He typically wants reply-to-all to go to the mailing list
} alone, while reply-to-author goes to him alone. This is impossible if
} the reply-to-author address is included in reply-to-all.

I disagree on what the fundamental problem is.

The fundamental problem is NOT the behavior of reply-to-all.  The *really*
fundamental problem is that reply-to-all is the wrong function to be using
in the first place.  The only reason that reply-to-all gets used, aside
from the Berkeley Mail historical baggage of the meanings of `r' and `R'
as commands, is because the simple reply function is unable to produce the
correct result.

Rather than attempting to get all MUAs to redefine reply-to-all to do a
less-inclusive thing, which I find unlikely, let's get them to redefine
simple reply to do a more inclusive thing, wherein the author of the message
being replied to gets to define what is included.  Yes, this COULD be done
today with Reply-To IF mailing-list servers didn't munge it.  But given the
reality of mailing-list servers, Reply-To is not a reasonable choice.  That
is the entirety of my proposal.

} I'm talking about convenient _default_ recipient lists. The user is
} of course free to send mail wherever he wants.

I'm talking about convenient default recipient lists, too.  The basic reply
command ought to be where one gets those convenient defaults.  Reply-to-all
ought to be the way the user sends mail wherever he wants (e.g., find all
the possible addresses for me, and let me edit some of them out).

There is no proposal that solves the reply-to-all problem without requiring
a change to MUAs.

Keith's proposal (as we're calling it, since he hasn't actually pronounced
either of us correct in our interpretations) would change the way MUAs
implement reply-to-all, but doesn't introduce new syntax.  That is good in
some senses, but bad in that it changes the interpretation of old messages.

Dan's proposal changes reply-to-all and labels the change with new syntax,
but requires knowledge of mailing-list membership on the part of sending
MUAs in order to operate conveniently.

My proposal extends both reply and reply-to-all, labels the change, and
requires no new knowledge in sending MUAs.

Both Dan's and Keith's proposals change reply-to-all by limiting it to a
subset of possible destination addresses.  This is beneficial to recipients
who don't want multiple copies, on the assumption that users continue to
use reply-to-all.

Dan's proposal encourages users to continue using reply-to-all, because a
simple reply still won't do the job.  I think this is unfortunate.

My proposal (I believe) encourages users to switch to simple replies, and
encourages MUA implementors to make simple reply be the convenient default.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

From: Keith Moore <[email-masked]>
To: "Bart Schaefer" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: best name for followups? 
Date: Thu, 10 Jul 1997 02:32:36 -0400
Sender: [email-masked]

> I don't think using Reply-To is a viable solution, because:
>  *  It requires UAs to restrict their reply-using-destination-fields
>     behavior when it is present.  Sounds familiar, but in this case
>     it's worse, because it retroactively changes the interpretation of
>     reply-using-destination-fields for messages sent long ago.

Actually I believe that UAs should encourage people to *select* the
recipient list of *every* reply which would otherwise be addressed to
more than one recipient.  Of course, they should make the recipient
(the one issuing the reply) aware of the sender's preference, as
expressed through the reply-to field from the subject message.

This requires a drastically different user interface than for most
existing UAs, but it's the only way I see to address *the* real
reply-to problem (as I define it): people don't stop to notice where
their email replies are going.  

It's an open question as to whether UAs that encourage such behavior
can be successful in the market...users would probably rather be lazy
than aware, even if they occasionally get bitten for being lazy.

>  *  Mailing lists must stop rewriting Reply-To.  List managers are not
>     going to give up control over list policy (direct replies to the
>     list or away from it) and Reply-To is the only way to influence a
>     large number of existing user agents.

Old mailing lists are unlikely to change their policies, but new ones
can adopt new policies.  And some list software can provide new
defaults for new subscribers, while retaining the same reply-to
munging settings for old ones.  Both of these have happened before.

At any rate, I suspect we're going to end up with some sort of
List-Address or List-Reply-To header, along with List-Subscribe,
List-Unsubscribe etc.  It's easy to do, and there was a lot of support
for it at the listhdr BOF at the Memphis IETF.

> So it does seem that a new differentiator is necessary, but I don't think
> `followup' is the obvious or correct one.
> 
> The claimed benefits of `followup' are:
>  *  Gives control to the original author (but too much so).
>  *  Easy to implement (maybe).
>  *  Existing UAs support the concept (but they don't, really).
>  *  No transition problem from current practice.
> 
> Here's an alternative which I think betters `followup' on every one of
> those points:  Define a `Reply-Cc' field, with the semantics that the
> address(es) in the Reply-Cc field should be copied to the Cc field of
> the reply; the semantics of all existing fields remain unchanged, except
> of course that the presence of Reply-To does not exclude the Reply-Cc.

I don't think this solves the problem Dan was complaining about, which
is that people get multiple copies of a reply if multiple addresses
that reach them appear in the header of the subject message.

[ Apologies if the following proposal is like mail-copies-to.  I
  haven't seen a definition of that header, so I can't evaluate it.
  If the thing is actually deployed, and someone knows how it works, 
  they might consider sending a description to Jacob Palme for 
  inclusion in the eventual successor to RFC 2076. anyway... ]

I thought about proposing a header of the form

Dont-Reply-To: <[email-masked]> if-replying-to <[email-masked]>

which essentially says: if you're sending a reply which would
otherwise be addressed to both [email-masked] and address [email-masked], leave
[email-masked] out of the recipient list of that reply.  So if person
[email-masked] is a member of the list [email-masked], he could include such a
header in his mail to [email-masked].  User agents would then know to omit
[email-masked] (from both header and envelope) in any reply containing
[email-masked], and [email-masked] would only get one copy of the reply -- the
one from the list.

pros/cons/{mis,}features:

+ It doesn't change the user interface for the guy issuing the
  reply.  He just says 'reply' or "reply to author" or reply to
  author+to+cc or whatever he says now, and the user agent does
  this, but leaving out the redundant addresses.

- It does require the sender's UA to be smart about when to add the
  Dont-reply-to header on outgoing mail.

- It opens the possibility of loops: what does a UA do if it sees 

  Dont-reply-to: <x> if-replying-to <y>
  Dont-reply-to: <y> if-replying-to <z>
  Dont-reply-to: <z> if-replying-to <x>

  In this case, it's safe to ignore all of the headers.

- There's nothing to stop lists from munging this header.  Some
  lists might want to be "smart" and add Dont-Reply-To headers for
  any message sent from a list member.  Some people would like this,
  since they'd get the benefits of Dont-Reply-To without having
  to change their UA.  Some people (like me) wouldn't want the list 
  to add such a header.  
  
  Unless the Dont-Reply-To spec clearly stated whether lists could
  mung the header, some would do so and others would not.  (yeech)

- It doesn't solve the two-list problem (if you're a member of
  two lists and a message is addressed to both lists, you'll still
  get two copies).  (Duplicate suppression at the recipient's
  UA does tend to solve this problem, as long as neither list
  mungs the message too much.)

- It doesn't solve the general reply-to problem: people don't notice
  or think about where their replies are going.  

Personally, I don't think it's worth it: there's not enough to be
gained for the trouble, and duplicate suppression is more effective
(solves the problem in more cases) and easier to deploy (only requires
support for the recipient who wants to suppress multiple messages, and
that recipient reaps the reward for his own effort).  If more UAs had
duplicate suppression there would be very minimal additional gain to
be had from Dont-Reply-To or similar proposals.

(Dan claims that after enough replies from different people, the
recipeint lists get so long that mail sofware breaks.  While this is
true in principle, I've never seen it happen in practice.  I've seen
software break due to long recipient lists, but never because of a
recipient list created by too many replies to too many different
people.  Even IETF list threads don't go on for that long.  And its
easier to fix the mailers that break with long recipient lists than it
is to fix mailers to support some new header and/or new functionality.)

Keith

From: "Bart Schaefer" <[email-masked]>
Date: Wed, 9 Jul 1997 23:04:24 -0700
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

[ I apologize for being unable to properly "thread" this reply.  My ISP
  decided to spend today moving mail to another machine, and broke all
  the deliveries for my domain in the process.  I'm replying by looking
  at the ietf-822 archive from www.imc.org. ]

On 9 Jul 1997, D. J. Bernstein ([email-masked]) wrote:
} 
} ... you aren't paying attention. Here's Keith's proposal:
} 
} > > > I don't really think there is a big need to allow a sender to
} > > > separately specify "reply to address-list X if you want to just reply
} > > > to me", and "reply to address-list Y if you want to followup".  Even
} > > > for those times when this is needed, the author can use From for the
} > > > former, and Reply-to for the latter. (With Sender used to indicate the
} > > > author's "real" address)
} 
} For this to work as described, the first function, reply-to-author, has
} to use From and ignore Reply-To.

I'm not the one not paying attention.  For this to work as described, two
things are required:  First, the author has to change From and leave out the
Reply-To when he means "reply to address-list X if you want to just reply to
me" and he must put in Reply-To exactly when he means "reply to address-list
Y if you want to followup."  The fields look like this:

Replies to address-list X to reply to me (case 1):

	From: X
	Sender: <real-author>
	To: <destinations>

Replies to address-list Y to follow up (case 2):

	From: <real-author>
	Reply-To: Y
	To: <destinations>

The second thing required is that user agents interpret Reply-To in such a
way that *neither* `reply' nor `reply-using-destination-fields' takes any
addresses from the To field in the event that Reply-To is present.

The quote from Keith that explains this second requirement is:

>>>I realize that many UAs don't handle "reply-to-all" this way,
>>>in particular a lot of UAs use Reply-to only as a replacement for From.
>>>But the DRUMS document already clarifies that reply-to is the author's
>>>preference as to where replies should be sent.

See <http://www.imc.org/ietf-822/mail-archive/0025.html>.

So in case 1, you get

	reply				-->	To: X
(a)	reply-using-destination-fields	-->	To: X, <destinations>

and in case 2 you get

	reply				-->	To: Y
(b)	reply-using-destination-fields	-->	To: Y

The argument, which I acknowledge that you don't accept, is that (b) is
not a change from RFC822, 4.4.4, because 4.4.4 never sanctioned (a) in
the first place.  Regardless of whether it's a change from 822, in both
your proposal and Keith's it is reply-using-destination-fields that must
change in all user agents.

} > other than your willful misrepresentations.
} 
} Idiot.

Yet another willful misrepresentation.

}   [ RFC 822 4.4.4 ]
} > However, that undermines your own proposal as much as it does Keith's.
} 
} Don't be ridiculous. Nothing in RFC 822 ``undermines'' the use of new
} header fields for extended functions. In fact, extension fields and
} user-defined fields are explicitly permitted.

Ah, but the effect of your proposal is the same as Keith's -- the reply-
using-destination-fields function will no longer use all the possible
destination fields.  You can't use 4.4.4 against one but not the other.

} Keith's proposal is different. He's changing the semantics of Reply-To
} and From, with no label to indicate the change.

He's not changing the semantics; he's merely asking that the existing
semantics be enforced more strictly.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 9 Jul 1997 23:49:02 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> So - does anybody have a good "feel" for what the *USERS* want?

Well, I'd recommend that everybody consult

   http://www.unicom.com/FAQ/reply-to-harmful.html

and

   http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto

I started this discussion after reading the latter page. I had always
perceived followup duplication as an annoyance, but I hadn't realized
that it motivated people to munge reply-to.

I've set up a page describing the proposal for future reference:

   http://pobox.com/~djb/replyto.html

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: Thu, 10 Jul 1997 0:12:23 MET DST
From: Johnny Eriksson <[email-masked]>
To: [email-masked]
Subject: Re: Keith's proposal 
Sender: [email-masked]

In reply to (?) message from "D. J. Bernstein" <[email-masked]>:

> > other than your willful misrepresentations.
> 
> Idiot.

Dan, your manners are worse than mine.  That means a *very* *low* level,
and that this discussion can no longer be regarded as technical.

> ---Dan

--Johnny

To: [email-masked]
Subject: Re: Bart's proposal 
From: [email-masked]
Date: Wed, 09 Jul 1997 16:12:54 -0400
Sender: [email-masked]

--==_Exmh_-2007331864P
Content-Type: text/plain; charset=us-ascii

On 09 Jul 1997 19:43:18 -0000, you said:
> Think about the usual case of a subscriber sending a message to a
> mailing list. He typically wants reply-to-all to go to the mailing list
> alone, while reply-to-author goes to him alone. This is impossible if
> the reply-to-author address is included in reply-to-all.

Man. I've heard of "blond moments", but I must be having a truly blond week
here.  I've been sitting here wondering what this proposal was about, and
following a long and headed discussion on the NAIPR list, and wondering why
every time around, I was trimming more and more damned addresses off the cc:
list.   Finally sank in that they were One And The Same. ;)

I take back what I said a few messages ago regarding whether users are asking
for it.  They are. ;)

Now to go back and re-read all the postings, with the benefit of enlightenment 
;)

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-2007331864P
Content-Type: application/pgp-signature

--==_Exmh_-2007331864P--

Date: 9 Jul 1997 19:43:18 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Bart's proposal
Sender: [email-masked]

> The problem is that the responding UA can't obey both the originator's
> recommendation and the responding user's instructions.

Huh? I'm talking about convenient _default_ recipient lists. The user is
of course free to send mail wherever he wants.

> I expect MUAs to expand the `reply' function to mean `send to (Reply-To
> OR From) + Reply-Cc'.
  [ ... ]
> I further expect MUAs to expand `reply-using-destination-fields' to mean
> `send to (Reply-To OR From) + Reply-Cc + To + Cc'.

Okay, now I understand what you mean.

Your proposal does not solve the fundamental problem: the reply-to-all
addresses always include the reply-to-author addresses.

Think about the usual case of a subscriber sending a message to a
mailing list. He typically wants reply-to-all to go to the mailing list
alone, while reply-to-author goes to him alone. This is impossible if
the reply-to-author address is included in reply-to-all.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked]
Subject: Re: best name for followups? 
From: [email-masked]
Date: Wed, 09 Jul 1997 15:04:02 -0400
Sender: [email-masked]

--==_Exmh_1610773032P
Content-Type: text/plain; charset=us-ascii

On 09 Jul 1997 16:53:22 -0000, you said:
> Hmmm. I get the feeling that you think I'm talking about writing a spec.
> I'm not. I'm talking about changing the behavior of real MUAs. The only
> relevant people are MUA implementors.

I'm (somewhat) an MUA implementor (I guess.. I hack at exmh source a lot ;)
So yes, changing the behavior of the MUA is relevant to me.

On the other hand, if my wife has me upgrade her copy of Eudora Lite, and
it acts differently, that's certainly relevant to *HER*.

So - does anybody have a good "feel" for what the *USERS* want?  I admit
skimming the beginning of the discussion - is this something that is being
pondered by us implementors, or are there users saying "gee it would be nice if"
as well?
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_1610773032P
Content-Type: application/pgp-signature

--==_Exmh_1610773032P--

Date: 9 Jul 1997 18:58:23 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Keith's proposal
Sender: [email-masked]

> } Keith proposes using From whether or not Reply-To exists.
> I've seen no evidence that this is what Keith proposes,

Then you aren't paying attention. Here's Keith's proposal:

> > > I don't really think there is a big need to allow a sender to
> > > separately specify "reply to address-list X if you want to just reply
> > > to me", and "reply to address-list Y if you want to followup".  Even
> > > for those times when this is needed, the author can use From for the
> > > former, and Reply-to for the latter. (With Sender used to indicate the
> > > author's "real" address)

For this to work as described, the first function, reply-to-author, has
to use From and ignore Reply-To.

> other than your willful misrepresentations.

Idiot.

> Based on what Keith has written, I interpret his proposal

Hint for the clueless: You have to read it before you can interpret it.

  [ RFC 822 4.4.4 ]
> However, that undermines your own proposal as much as it does Keith's.

Don't be ridiculous. Nothing in RFC 822 ``undermines'' the use of new
header fields for extended functions. In fact, extension fields and
user-defined fields are explicitly permitted.

Keith's proposal is different. He's changing the semantics of Reply-To
and From, with no label to indicate the change.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

From: "Bart Schaefer" <[email-masked]>
Date: Wed, 9 Jul 1997 11:12:31 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: best name for followups?" (Jul  9,  4:53pm)
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

On Jul 9,  4:53pm, D. J. Bernstein wrote:
} Subject: Re: best name for followups?
}
} >  *  It requires UAs to restrict their reply-using-destination-fields
} >     behavior when it is present,
} 
} Yes, it's a change in the followup behavior. That's the whole point.
} 
} >	rather than permitting them to extend
} >     their basic reply behavior when it is present.
} 
} I don't understand. Do you have some specific change in mind?

See below.

} How does it conflict with a change in followup behavior?

It doesn't conflict; I just don't believe that a change in reply-using-
destination-fields is a good or likely thing.  Even if it does change,
the change is more likely to be that it becomes `reply using From + To
+ Cc + The-New-Field', which is exactly the opposite of what you want.

Hence if you're going to add a new field,  you might as well add a field
that has fits that behavior to begin with.

} Hmmm. I get the feeling that you think I'm talking about writing a spec.
} I'm not. I'm talking about changing the behavior of real MUAs. The only
} relevant people are MUA implementors.

That's a lovely idea, but if you don't write a spec the chances approach
zero of more than two different implementors agreeing on how it works.
Look at all the odd edge conditions in reply-using-destination-fields.

} >  *  It requires originators to supply too much information; they must
} >     not only suggest how recipients should deal with their own address,
} >     but must also suggest how to deal with all destination addresses.
} 
} Why is this a problem? Could you give a specific example where the
} originator would have trouble coming up with the information?

The problem is not that the originator can't come up with the information.
The problem is that the responding UA can't obey both the originator's
recommendation and the responding user's instructions.  The responding
UA must either ignore the destination fields even when instructed (by the
responding user) to include them, which I think is bad; or it must ignore
the originator's recommendation when asked to do a simple reply.

Skipping ahead for a bit:

} Replies are typically sent to Reply-To defaulting to From. You're saying
} that they should be sent to Reply-To+Reply-Cc defaulting to From. Right?

Right so far.

} Aside from Reply-To munging and the difference between To and Cc, your
} proposal adds no new capabilities. A user can simply merge your Reply-Cc
} into Reply-To to obtain the same results.

Essentially correct; the minor difference being that Reply-Cc goes into
the Cc field, not into To.  In fact, it is exactly the intention that
there are no new capabilities *except* the ability to bypass Reply-To
munging.

} Your real proposal is the same as Keith's: you want to put the mailing
} list into Reply-To, and the sender's personal reply address into From.
} You expect MUAs to have a respond-to-From-ignoring-Reply-To function.
} Right?

Completly wrong.  To address the "followup problem," I want to put the
sender's personal reply address into Reply-Cc if and only if he is not
a member of the mailing list; if he is a member of the mailing list, I
think the Reply-Cc should be left out entirely.  What goes in Reply-To 
is whatever goes in Reply-To right now, munged however the list server
munges it right now; I don't care.

I expect MUAs to expand the `reply' function to mean `send to (Reply-To
OR From) + Reply-Cc'.  I expect `Reply-To' to continue to replace `From'
as it does now.

I further expect MUAs to expand `reply-using-destination-fields' to mean
`send to (Reply-To OR From) + Reply-Cc + To + Cc'.  However, I expect
users to realize that `reply-using-destination-fields' is no longer the
right thing to use to "follow up," because `reply' does what they want.

That means I expect UAs that support Reply-Cc to stop making `reply to
all' be the most-easily-accessed reply function.

} Later you make clear that you're proposing a change purely in reply
} behavior, not in followup behavior.

It is correct that I do not propose to reduce reply-using-destination-
fields behavior in any sense.

} The followup field is the same as From+To+Cc by default. The MUA can
} automatically remove the From address if it knows that the user is on a
} mailing list shown in To+Cc. The followup field is copied into
} subsequent followups.

The Reply-Cc field is the same as From by default (simpler).  The MUA
can automatically remove the entire field if it knows the user is on a
mailing list (simpler -- and the operation really is that the MUA can
ADD the field if it does NOT know whether the user is on the mailing
list, which means it works even in UAs that don't maintain that info).
The Reply-Cc address is copied into the Cc of subsequent "followups."

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

From: "Bart Schaefer" <[email-masked]>
Date: Wed, 9 Jul 1997 10:28:41 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: best name for followups?" (Jul  9,  4:01pm)
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

On Jul 9,  4:01pm, D. J. Bernstein wrote:
} Subject: Re: best name for followups?
}
} Until I hear better terminology, I'm going to continue to use ``reply''
} and ``followup'' as generic terms for the two response functions in
} existing MUAs.

I hope you enjoy talking to yourself, then.

} > Actually, none of them are following 4.4.4 when they do `reply to all',
} 
} You misunderstand. Keith is proposing a change in _replies_, not just
} followups.

What's the connection between that and whether UAs are following 4.4.4?

} The relevant part of 4.4.4 is the third bulleted item:

You'll note that I had quoted that specific item.

} when Reply-To exists, it replaces From as the target of replies.

When Reply-To exists, it replaces From when automatically generating
address lists from originator fields, yes.

} Keith proposes using From whether or not Reply-To exists.

I've seen no evidence that this is what Keith proposes, other than your
willful misrepresentations.  Based on what Keith has written, I interpret
his proposal as "never use the contents of destination fields to generate
reply addresses when a Reply-To header is present."  This does not imply
"always use From."

Keith does also propose "don't send a Reply-To field when that isn't what
you mean," but that's a recommendation for originators, not a change for
responders.

} > Even if you grant dispensation for common practice,
} 
} Perhaps you should read RFC 822. It explicitly recognizes that MUAs can
} provide additional response facilities.

You refer to this text:

	This recommendation is intended only for automated use
	of originator-fields and is not intended to suggest
	that replies may not also be sent to other recipients
	of messages.  It is up to the respective mail-handling
	programs to decide what additional facilities will be
	provided.

I agree that this supports the position that UAs should not be restricted
from using destination fields to generate reply addresses.  However, that
undermines your own proposal as much as it does Keith's.

It also supports, by the phrase "additional facilities," my assertion that
`reply using From + To + Cc' is extended functionality and explicitly not
covered (though also explicitly not prohibited) by 4.4.4.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 9 Jul 1997 16:53:22 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

  [ criticism of a followup field ]
>  *  It is introducing a new concept;

It is working with the concept that already exists in dozens of MUAs.

The big problem, as is obvious from this discussion, is coming up with a
good name.

>  *  It requires UAs to restrict their reply-using-destination-fields
>     behavior when it is present,

Yes, it's a change in the followup behavior. That's the whole point.

> rather than permitting them to extend
>     their basic reply behavior when it is present.

I don't understand. Do you have some specific change in mind? How does
it conflict with a change in followup behavior?

Hmmm. I get the feeling that you think I'm talking about writing a spec.
I'm not. I'm talking about changing the behavior of real MUAs. The only
relevant people are MUA implementors.

>  *  It requires originators to supply too much information; they must
>     not only suggest how recipients should deal with their own address,
>     but must also suggest how to deal with all destination addresses.

Why is this a problem? Could you give a specific example where the
originator would have trouble coming up with the information?

The followup field is the same as From+To+Cc by default. The MUA can
automatically remove the From address if it knows that the user is on a
mailing list shown in To+Cc. The followup field is copied into
subsequent followups.

  [ new proposal ]
> Here's an alternative which I think betters `followup' on every one of
> those points:  Define a `Reply-Cc' field, with the semantics that the
> address(es) in the Reply-Cc field should be copied to the Cc field of
> the reply;

Later you make clear that you're proposing a change purely in reply
behavior, not in followup behavior.

Replies are typically sent to Reply-To defaulting to From. You're saying
that they should be sent to Reply-To+Reply-Cc defaulting to From. Right?

Aside from Reply-To munging and the difference between To and Cc, your
proposal adds no new capabilities. A user can simply merge your Reply-Cc
into Reply-To to obtain the same results.

Your real proposal is the same as Keith's: you want to put the mailing
list into Reply-To, and the sender's personal reply address into From.
You expect MUAs to have a respond-to-From-ignoring-Reply-To function.
Right?

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: 9 Jul 1997 16:01:41 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> Keith's proposal is to use Reply-To to control replies, and to ignore
> the concept of followups entirely.

I know that _Keith_ is ignoring the concept of followups. However,
_MUAs_ already have the concept, and they're not going to throw it away.

> I don't think it's useful to apply the netnews concept of `followup' to the
> common email UA function of `reply using From + To + Cc'.

Until I hear better terminology, I'm going to continue to use ``reply''
and ``followup'' as generic terms for the two response functions in
existing MUAs.

> Actually, none of them are following 4.4.4 when they do `reply to all',

You misunderstand. Keith is proposing a change in _replies_, not just
followups.

The relevant part of 4.4.4 is the third bulleted item: when Reply-To
exists, it replaces From as the target of replies.

Keith proposes using From whether or not Reply-To exists.

Whenever From and Reply-To are different---e.g., a secretary sending a
message for the boss---Keith's change in semantics poses an impossible
transition problem. The only way for users to retain control over
replies is to copy Reply-To into From, violating the RFC 822 From
semantics.

> Even if you grant dispensation for common practice,

Perhaps you should read RFC 822. It explicitly recognizes that MUAs can
provide additional response facilities.

> I happen to think it's useful enough extended functionality that it ought
> to be recognized by the standards;

Standards? I'm talking about reality, not the IETF.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: Wed,  9 Jul 1997 09:58:13 -0400 (EDT)
From: [email-masked]
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

Thank you, thank you for applying more light and less heat to this
discussion.  And particularly for an actual proposal that looks like
forward progress!

Excerpts from transarc.system.ietf-822: 9-Jul-97 Re: best name for
followups? "Bart Schaefer"@candle.b (5133*)

> Here's an alternative which I think betters `followup' on every one of
> those points:  Define a `Reply-Cc' field, with the semantics that the
> address(es) in the Reply-Cc field should be copied to the Cc field of
> the reply; the semantics of all existing fields remain unchanged, except
> of course that the presence of Reply-To does not exclude the Reply-Cc.

> Gives control to the original author:  In approach #1, the originator
> places the address of the mailing list in Reply-To and omits Reply-Cc.
> In approach #2, the originator places his own address in Reply-Cc and
> does whatever he likes with Reply-To.  Using both provides approach #3.

Sounds perfect.

		Craig

From: "Bart Schaefer" <[email-masked]>
Date: Wed, 9 Jul 1997 01:46:14 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: best name for followups?" (Jul  8, 11:54pm)
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

On Jul 8, 11:54pm, D. J. Bernstein wrote:
} Subject: Re: best name for followups?
}
}    A subscriber sends a message to a mailing list. Someone follows up.
}    The response is sent to both the subscriber and the mailing list.
} 
}    A non-subscriber sends a message to a mailing list. Someone follows
}    up. The response is sent to the non-subscriber and the mailing list.

Let's restate those two cases as:

     A subscriber sends a message to a mailing list.  Some recipient
     uses the reply-using-destination-fields function of his user
     agent.  The response is sent both to the subscriber and to the
     mailing list.
 
     A non-subscriber sends a message to a mailing list.  Some recipient
     uses the reply-using-destination-fields function of his user agent.
     The response is sent to the non-subscriber and to the mailing list.

Now we can all agree, I think, on this:

} So the original author has to put some extra information into his header
} to differentiate the two situations.

There are three ways to approach this problem:

1.  The originator who is on the mailing list can ask (not require) the
    recipients to omit him from the replies.

2.  The originator who is NOT on the mailing list can ask the recipients
    to include him in the replies.

3.  Both kinds of originators can suggest the full list of destinations
    to which the recipients should direct replies.

} The obvious solution is a followup field.  This would put control
} directly in the hands of the original author, and it would be trivial to
} implement.  My question is what this field should be called.

I agree with Keith that a followup field is not an obvious solution, and
therefore that debating what to call it is premature.  It is not obvious
because:
 *  It is introducing a new concept; reply-using-destination-fields
    is not the same as the traditional netnews concept of `followup'.
 *  It requires UAs to restrict their reply-using-destination-fields
    behavior when it is present, rather than permitting them to extend
    their basic reply behavior when it is present.
 *  It requires originators to supply too much information; they must
    not only suggest how recipients should deal with their own address,
    but must also suggest how to deal with all destination addresses.

I don't think using Reply-To is a viable solution, because:
 *  It requires UAs to restrict their reply-using-destination-fields
    behavior when it is present.  Sounds familiar, but in this case
    it's worse, because it retroactively changes the interpretation of
    reply-using-destination-fields for messages sent long ago.
 *  It requires originators to supply too much information (a generic
    problem with approach #3 above).
 *  Mailing lists must stop rewriting Reply-To.  List managers are not
    going to give up control over list policy (direct replies to the
    list or away from it) and Reply-To is the only way to influence a
    large number of existing user agents.

So it does seem that a new differentiator is necessary, but I don't think
`followup' is the obvious or correct one.

The claimed benefits of `followup' are:
 *  Gives control to the original author (but too much so).
 *  Easy to implement (maybe).
 *  Existing UAs support the concept (but they don't, really).
 *  No transition problem from current practice.

Here's an alternative which I think betters `followup' on every one of
those points:  Define a `Reply-Cc' field, with the semantics that the
address(es) in the Reply-Cc field should be copied to the Cc field of
the reply; the semantics of all existing fields remain unchanged, except
of course that the presence of Reply-To does not exclude the Reply-Cc.

Gives control to the original author:  In approach #1, the originator
places the address of the mailing list in Reply-To and omits Reply-Cc.
In approach #2, the originator places his own address in Reply-Cc and
does whatever he likes with Reply-To.  Using both provides approach #3.

Easy to implement:  Many UAs can begin sending it immediately.  Simple
rule for what to do with the addresses when constructing a reply.

Existing UAs support the concept:  Every UA has replies and Cc fields,
and every user knows what they mean.  Nothing new to learn.

No transition problem:  `Reply-using-destination-fields' behaviors are
completely unchanged.  As support spreads, users can use `reply' instead,
even in mailing-list circumstances to get `followup'-like behavior, and
thereby reduce duplications.  List servers don't have to change.

There's probably even some mailer out there somewhere that already has a
Reply-Cc field that works this way.

A final remark:  This whole debate could have been avoided by dumping the
term `followup'.  Call the silly thing `Reply-Destinations' and stick with
the concept of `reply'.  That doesn't solve any of the other problems with
it, but at least Dan can stop pretending that he and Keith don't understand
each other.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

From: "Bart Schaefer" <[email-masked]>
Date: Tue, 8 Jul 1997 23:52:15 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: best name for followups?" (Jul  9,  3:17am)
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

On Jul 9,  3:17am, D. J. Bernstein wrote:
} Subject: Re: best name for followups?
}
} > In email, using reply-to, I can manually redirect a discussion away from 
} > inappropriate recipients.  What's the difference?
} 
} My proposal---using Reply-To to control replies, and a followup field to
} control followups---is a _labelled_ change from RFC 822 semantics.
} 
} Your proposal---using From to control replies, and Reply-To to control
} followups---is an _unlabelled_ change from RFC 822 semantics.

That's not Keith's proposal, and you ought to know that it isn't.  Keith's
proposal is to use Reply-To to control replies, and to ignore the concept
of followups entirely.  I happen to agree with him on the latter point; I
don't think it's useful to apply the netnews concept of `followup' to the
common email UA function of `reply using From + To + Cc'.  They happen to
have a similar effect if and only if one of those headers contains the
address of a mailing list, but they're still not really the same thing.

} You keep complaining that MUAs don't use From and Reply-To the way you
} suggest. That's because they're following RFC 822, section 4.4.4.

Actually, none of them are following 4.4.4 when they do `reply to all',
because 4.4.4 doesn't apply to the To and Cc fields.  It applies only
to From, Sender, and Reply-To.  Anything that automatically uses To and
Cc in that way is extended functionality, not covered by RFC822.  There
is no mention anywhere in 822 of using To and Cc that way.

Even if you grant dispensation for common practice, it's debatable whether
they're following 4.4.4; the statement there is:
	If the "Reply-To" field exists, then the reply should go to the
	addresses indicated in that field and not to the address(es)
	indicated in the "From" field.

It's been argued that the "and not to ..." clause is extraneous, and that
the interpretation was meant to be "... go to the addresses indicated in
that field, and nowhere else."  Which is exactly what the basic `reply'
function does in all the UAs that you listed; the `reply to all' function
is ignoring the implicit "and nowhere else."

(Section 4.3.1:
	The "Reply-To" field is added by the originator and serves to
	direct replies, ...
Section 4.4.3:
	The "Reply-To" field is added by the originator and is intended
	to direct replies.
But they both muddy the issue by attaching clauses about Return-Path, so
there's no definitive "and nowhere else" anywhere.)

Furthermore, most of those UAs' `reply to all' functions behave as `reply
using (Reply-To OR From) + To + Cc'; some do even more complex things, but
in any case they're usually doing a 4.4.4 `reply' and then, in addition,
using some other set of addresses.  That fits the definition of extended
functionality, I'd say.

I happen to think it's useful enough extended functionality that it ought
to be recognized by the standards; but confusing it with the concept of
`following up' is the wrong approach.

} Of course, this is only a guess at what your proposal means, since you
} consistently refuse to say what you want real MUAs to do with their two
} built-in response functions.

I won't presume to speak for him, but my understanding is that the second
response function should be `reply using Reply-To OR (From + To + Cc)'
(note the change in parenthesization).  Maybe a better characterization
is that `reply' should always mean `using Reply-To OR From', and tacking
on addresses from any other source should be in a different category.

This essentially means that we don't change RFC882, but rather that we
start insisting that UAs obey the strictest possible interpretation of the
Reply-To header.  I dislike that for various reasons, but I find it even
more distasteful to stir `followups' into the mix.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 9 Jul 1997 03:17:24 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> In email, using reply-to, I can manually redirect a discussion away from 
> inappropriate recipients.  What's the difference?

My proposal---using Reply-To to control replies, and a followup field to
control followups---is a _labelled_ change from RFC 822 semantics.

Your proposal---using From to control replies, and Reply-To to control
followups---is an _unlabelled_ change from RFC 822 semantics.

You keep complaining that MUAs don't use From and Reply-To the way you
suggest. That's because they're following RFC 822, section 4.4.4.

Of course, this is only a guess at what your proposal means, since you
consistently refuse to say what you want real MUAs to do with their two
built-in response functions.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: 8 Jul 1997 23:54:12 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

Time for a reality check.

BSD Mail supports two response functions:

   1. ``reply to originator'' = From.
   2. ``send mail to sender and all recipients'' = From + To + Cc.

Elm supports two response functions:

   1. ``reply'' = From.
   2. ``group reply'' = From + To + Cc.

Pine supports one function but asks ``reply to all recipients?'':

   1. ``no'' = From.
   2. ``yes'' = From + To + Cc.

Mutt supports two response functions:

   1. ``reply'' = From.
   2. ``reply to all recipients'' = From + To + Cc.

Does Keith see the pattern yet? Or shall I start listing non-UNIX
mailers too?

There's certainly no standardization at the edges of these functions.
For example, some MUAs copy the original To into the new Cc field; some
copy it into the new To field.

But there's always a reply function, using From in the common case, and
a followup function, using From + To + Cc in the common case.

Now, once again, here's the problem:

   A subscriber sends a message to a mailing list. Someone follows up.
   The response is sent to both the subscriber and the mailing list.

As I've already discussed in detail, the extra address is generally
harmful. I don't think there's any dispute about this.

Unfortunately, the person following up can't tell that situation apart
from the following situation, where the extra address is generally
beneficial:

   A non-subscriber sends a message to a mailing list. Someone follows
   up. The response is sent to the non-subscriber and the mailing list.

So the original author has to put some extra information into his header
to differentiate the two situations.

The obvious solution is a followup field. This would put control
directly in the hands of the original author, and it would be trivial to
implement. My question is what this field should be called.

> But you haven't demonstrated that followups are (a) significantly
> distinct from replies and (b) worth having.

Existing MUAs support followups. Followups have vastly different effects
from replies. I really don't care whether Keith accepts these facts; his
willful ignorance is not typical of MUA implementors.

> And if I equate your word "followup" to my UA's "reply-to-all" command, 
> the author of the subject message does have the ability to override
> the default recipient list of "reply-to-all", using reply-to.
> I realize that many UAs don't handle "reply-to-all" this way,

That's because they're following RFC 822, section 4.4.4.

> And you completely ignore my argument against unnecessary complexity,

I agree with Keith that RFC 822 is unnecessarily complex. But we're
stuck with it. Keith's proposed change in semantics would be a disaster.

> Okay, but whatever that operation is, it doesn't recognize a
> followup-to header, and we're better off without one.  If someone
> modified Berekeley Mail to support a followup-to header, I'd end up
> manually editing headers even more often than I do now.

Let's see some specific examples supporting this claim. In exactly what
situation would a followup field, implemented as I described, produce
worse results than the current defaults?

> Followup-to won't fix this: for the forseeable future UAs won't
> either recognize it or generate it.

Duh.

There's no transition problem here. MUAs can support a followup field
without trouble. As support spreads, duplicate messages will disappear.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: Sat, 5 Jul 1997 18:20:51 +0200
To: IETF mail extensions mailing list <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Advise on the implementation of Supersedes, In-Reply-To and References e-mail headers
Sender: [email-masked]

I have written a draft document with advice on how to implement the
Supersedes, In-Reply-To and References headers in mail and news
user agents.

The document has been submitted to IETF drafts is available at URL:
ftp://ftp.dsv.su.se/users/jpalme/draft-palme-newfields-info-00.txt,
and its text is copied below in this message:

--- --- cut here --- ---

Network Working Group                                       Jacob Palme
Internet Draft                                 Stockholm University/KTH
draft-palme-newfields-info-00.doc
IETF status: To become an informational RFC
Expires: January 1998                                         July 1997

Advise on the implementation of In-Reply-To, References and Supersedes
e-mail and netnews headers

Status of this Document

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

Separate Internets standards documents define the e-mail headers,
In-Reply-To, References, Supersedes and Expires. This document,
which is an informational RFC, gives some advise on the
implementation of these features.

Table of Contents

1. User interface
2. Hard and soft Supersedes
3. Data base
4. References
5. Author's Address

1.    User interface

The fields "In-Reply-To", "References" and "Supersedes" are all used to
convey information about references between different e-mail messages
or netnews articles.

The best way to implement these fields is to tell the recipient that
two messages reference each other, and to make it easy for readers to
traverse threads (series of linked messages) up and down.

In the particular case of "Supersedes", a user who has not yet read
either the old or the new version, may be shown only the new version as
a new message, but with methods to easily find the old version.

A good way to show this information to users is to show the "In-Reply-
To", "Supersedes" and "References" fields and allow the user to click
on the parameters of these fields to get to the referred-to messages.
Additionally, it is useful to add reverse fields to message headers,
i.e. "Replied-By", "Referenced-By" and "Superseded-By". This allows a
user, when reading a message, to see if someone else has already
replied, and it allows users to traverse threads downwards and not only
upwards. Such reverse fields should not be sent in e-mail, they are
just for local handling in user mailbox databases.

2.    Hard and soft Supersedes

By a hard supersedes is meant a Supersedes which causes deletion of the
supersedes message. By a soft supersedes is meant a Supersedes which
still keeps both messages, and allows a user to see and use the
reference between them, similarly to In-Reply-To and References.

Supersedes should be implemented as soft supersedes. Some
implementations, especially in Usenet News, do however implement it as
hard supersedes.

Hard supersedes has the same security problem as the Cancel command of
Usenet News. They can be used to malicuosly deleting other people's
messages. Use of strong authentication of the author can reduce this
risk.

3.    Data base

In order to implement this, a data base is needed which, given a
Message-ID, can find the message which this Message-ID refers to. This
data base has a very simple structure, just a single value mapped to
one or more messages. Note, however, that the same message can be
stored in more than one mailbox, so the data base should not be
restricted to only one location for each Message-ID.

Every time a message is added, moved, copied, deleted or purged, this
data base need to be updated.

The main problem with these kinds of Message-ID data bases is that they
tend to become very large with time, and they easily collect garbage
(Message-ID-s of messages not any more available in the mailbox data
base).

The two most common methods to implement such data bases are:

(a) Implement a large data base, but with some method of garbage
    collection to avoid unlimited growth of the data base.

(b) Implement a smaller data base, where all objects are deleted
    after a certain time, for example a few months.

With implementation method (b), information about the references in the
form of "In-Reply-To", "References", "Supersedes", "Replied-By",
"Referenced-By" and "Superseded-By" should also be stored in the
message headers themselves. The reason method (b) works is that it is
very uncommon that a message has a reference to other than very recent
messages. Thus, the lack of "Replied-By", "Referenced-By" and
"Superseded-By" headers in these very uncommon cases is acceptable.

The advantage with method (b) is that a complex garbage collection
method, as for method (a), is not needed. A much simpler garbage
collection method, just removing records after a certain expiration
time, can be used instead.

4.    References

Ref.            Author, title
---------       --------------------------------------------------------

[AUTOLOOP]      J. Palme: "Loop control for the Auto-Submitted e-mail
                header", draft-palme-autosub-03.txt, July 1997.

[MIME1]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bodies", RFC 2045, December 1996.
                .
[MIME2]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part Two:  Media Types", RFC 2046,
                December 1996.

[MIME3]         K. Moore, "MIME (Multipurpose Internet Mail Extensions)
                Part Three:  Message Header Extensions for Non-ASCII
                Text", RFC 2047, December 1996.

[MIME4]          N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
                Mail Extensions (MIME) Part Four:  Registration
                Procedures", RFC 2048, January 1997.

[MIME5]         "Multipurpose Internet Mail Extensions (MIME) Part Five:
                Conformance Criteria and Examples", RFC 2049, December
                1996.

[NEWFIELDS]     J. Palme: "The Auto-Submitted, Supersedes and Expires
                E-mail Headers", draft-ietf-mailext-new-fields-08.txt,
                July 1997.

[NEWS]          M.R. Horton, R. Adams: "Standard for interchange of
                USENET messages", RFC 1036, December 1987.

[RFC822]        D. Crocker: "Standard for the format of ARPA Internet
                text messages." STD 11, RFC 822, August 1982.

[SMTP]          J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
                821, August 1982.

5.    Author's Address

Jacob Palme                          Phone: +46-8-16 16 67
Stockholm University and KTH         Fax: +46-8-783 08 29
Electrum 230                         E-mail: [email-masked]
S-164 40 Kista, Sweden

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

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: best name for followups? 
Date: Thu, 03 Jul 1997 20:08:02 -0400
Sender: [email-masked]

> However, I prefer a followup field, for the same reason that I like
> having a followup field in news: it's more flexible. For example, I can
> manually redirect a crossposted discussion away from an inappropriate
> mailing list.

In email, using reply-to, I can manually redirect a discussion away from 
inappropriate recipients.  What's the difference?

Keith

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: best name for followups? 
Date: Thu, 03 Jul 1997 20:04:19 -0400
Sender: [email-masked]

> Keith says that users can control replies with Reply-To (in the absence
> of reply-to munging). I agree. However, users currently have no way to
> control followups.

True.  But you haven't demonstrated that followups are (a) significantly
distinct from replies and (b) worth having.

> Keith then suggests that there's no need for users to control replies
> and followups separately. That's absurd.

Not if there's no good reason to have followups (as distinct from
replies) in the first place.

> One of the big munging harms
> discussed in http://www.unicom.com/FAQ/reply-to-harmful.html is the
> user's inability to control replies.

Yes, but the same problems and more would exist for followups if followup-to were defined, because lists would mung those as well.

Oddly enough, the best way I can see to get lists to stop munging reply-to
is to define some sort of list-reply-to header and get UAs to support that.
This would still be confusing to users, but at least there would be a 
clear separation of function - reply-to is specified by the message
author, and list-reply-to is specified by the list that you received
the message from.  And it wouldn't stop reply-to munging entirely, but
it might decrease its 
incedence.

> Next Keith proposes using Sender in place of From, using From to control
> replies, and using Reply-To to control followups. This is a massive
> change from the RFC 822 Reply-To semantics supported by dozens of
> existing clients. The transition would be a disaster.

This is of course not what I had in mind.  Part of your confusion is
due to your insistence on a notion of followup as separate from reply,
even when interpreting a message that I wrote.  Since I don't believe
that there is a significant difference between these operations,
I obviously would not propose "using Reply-To to control followups".

> > There's a difference between a human making an intelligent choice
> > about where she wants her replies to go,
> 
> Here Keith is referring to people deleting recipients from followups.

Nope.  I don't believe in followups as distinct from replies.

> The problem is that these people don't have the information they need:
> are those recipients members of the mailing list? The result is that
> non-subscribers are often accidentally removed.

If someone replies to a message addressed to both me and this mailing list,
they shouldn't be trying to figure out whether I'm on the mailing list.  I am
on this mailing list, but I don't receive mail from this list at the same
 address that appears in the From field of mail I send.  If someone deletes me
from the recipient list of a response because they assume I'm on the mailing
list, chances are that I won't see the response anytime soon.

> > And if a followup-to field were introduced, lists would add or mung
> > that field also, along with reply-to.
> 
> If Keith doesn't understand why Reply-To munging happens right now, he
> should read http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto. The
> more clients that support a followup field, the less motivation there is
> for this type of munging.

I understand why Reply-To munging happens (actually there are lots of
reasons), but I disagree that adding a followup-to header will
actually lessen the degree of header munging, or simplify things
for the user, or increase the probability that hitting a single
button on the user's UA will do the right thing.  

> > A UA that blindly copy followup-to to followups, creates much the same
> > problem as list robots that blindly mung reply-to.
> 
> If Keith doesn't understand the harms caused by Reply-To munging, he
> should read http://www.unicom.com/FAQ/reply-to-harmful.html.

I pretty much agree with everything in Chip's statement, and have
publically expressed support for it in the past.  Your implication
that I don't understand his argument is disingenuous.

> > Followups are an artifact of the netnews environment, where you have
> > separate address schemes for email and netnews.
> 
> Nonsense. Replies and followups are fundamentally different operations.

please explain what's different about them in a way that doesn't
either: refer to netnews or change the definition of reply and reply-to.

> Practically every mailer supports both replies and followups.

Perhaps every UA that supports netnews supports both replies and followups
(at least for netnews), but none of the email-only UAs that I've used
support both.  

Most UAs support reply-to-sender and reply-to-all, with some variation
as to (a) whether "reply-to" is used instead of the "from" address,
or as the "default" recipient list, and (b) the definition of "all" 
(does it include cc addresses or just to addresses?)

I think we'd be better off defining "reply" and "reply-to-all" in
terms of existing to/cc/from/reply-to headers, than to add new
headers in the mix.

> This has nothing to do with the difference between mail addresses and
> news addresses.
> 
> > having two different address schemes creates lots of problems.
> 
> I agree. One solution is to integrate the newsgroup address space into
> the mail address space. Here's a working example:
> 
>    To: [email-masked], [email-masked]
> 
> It would be easy to set up a global usenet.news domain, configured
> locally to talk to a nearby NNTP server.

I wouldn't mind seeing something like that, though it would be really
difficult to get people to agree on a domain name for news.
(technically it may be easy; politically it would be very difficult.
locally-configured domain names aren't supposed to exist.  don't
try to argue otherwise; this is an old war and reopening it won't
get anywhere useful)

Easier would be to establish a convention for domain literals,
e.g. sci.crypt@[news:] or keith_moore@[fax:+14239748295]

> Newsgroups are simply high-volume mailing lists with many entry points
> and a fancy distribution mechanism.
> 
> > But in the email world there's no inherent distinction
> > between "public responses" and "private responses" and it's silly to
> > pretend that there is one.
> 
> Every popular MUA supports both replies and followups.

Depends on what you mean by followups.

> > You can define some notion of "followup"
> > for email using a followup-to header, but doing so doesn't add any new
> > services -- it just replicates services that already exist.
> 
> False. It provides a direct way to control followups; 

circular argument.  Having X would provide a way to control X.
to which my response is: Not having X would rid me of the need to control X.
unless you can give me a much better justification for X, I'm quite sure 
that I'm better off without it.  (and no, the fact that something called 
X apparently exists on some UAs, which is almost certainly implemented 
differently on each UA, and also differently than what you propose, is 
not a justification for perpetuating X or standardizing X')

> > > Explanation, please. Who exactly would be confused?
> > Besides you?  (sorry, that was too easy.)
> 
> I find this comment rather amusing, given the number of ridiculous
> statements that Keith has made in this discussion---claiming that the
> followup field is for MLMs to set, claiming that the widely recognized
> problem of duplicates doesn't exist, claiming that the problem is solved
> by MUA duplicate elimination, etc.

Your mis-statement of my position provides more evidence of your confusion.

> > Users who are confused by existing reply options would be even more confused
> > by the addition of followup options which basically do the same thing
> > as replies.
>   [ ... ]
> > Support for followup-to would require that UAs add other commands
> > ("followup", "set followup-to") in addition to the set above.  
> 
> Here Keith makes yet another stupid mistake: he seems to think that
> followups are something different from the MUA's existing ``wide reply''
> or ``group reply'' or ``reply to all'' feature.

Absolutely they are.  Reply-to-all doesn't recognize a followup-to
header, and the operation that you're proposing would recognize such 
a header.  If such an operation were implemented, I would still
need a different operation to allow me to send a reply-to-all WITHOUT 
looking at the followup-to field, because I might have reasons
for not following the author's suggestion of where I send my responses.

Above you stated that followups and replies are fundamentally
different operations, and now you're telling me that followup
is no different than "reply to all".  For a large number of users,
"reply" is no different than "reply to all".

> One wonders how many times Keith needs to see the problem statement
> before he understands it. Here it is again:
> 
>    Right now, when someone _follows up_ to a mailing list message from a
>    subscriber, the subscriber and the mailing list are both in the
>    followup's recipient list by default.
> 
> The obvious fix is to let the subscriber override the default _followup_
> target, omitting his own address.

Your problem statement uses an undefined term, and so is meaningless.
If I choose a definition for that term, you'll pick a different
definition and claim that my arguments based on my defintion are
stupid. 

And if I equate your word "followup" to my UA's "reply-to-all" command, 
the author of the subject message does have the ability to override
the default recipient list of "reply-to-all", using reply-to.

I realize that many UAs don't handle "reply-to-all" this way,
in particular a lot of UAs use Reply-to only as a replacement for From.
But the DRUMS document already clarifies that reply-to is the author's
preference as to where replies should be sent.  Adding yet another
header to define replies provides marginal additional value at best,
and increases the complexity (and variation among UAs) as to how
recipients can respond to messages.  It's not worth it.

> > > Explanation, please. How exactly would a followup field hurt anyone?
> > I've already explained this.
> 
> Nonsense. Keith has explained bad consequences of two red herrings:
> first, having MLMs munge the followup field; second, having followups
> distinguished from reply-to-sender-and-recipients.

And you completely ignore my argument against unnecessary complexity,
by citing points irrelevant to this argument and calling them red
harrings.

> > First explain how "followup" would differ from "reply", beyond the
> > fact that it would use different header names and that it's not
> > supported by any of the installed base.
> 
> Nonsense. It's supported by most, perhaps all, of the installed base.
> It's even supported by Berkeley Mail.

Okay, but whatever that operation is, it doesn't recognize a followup-to header, and we're better off without one.  If someone modified Berekeley
Mail to support a followup-to header, I'd end up manually editing headers
even more often than I do now.

> > Also please explain why it
> > would not suffer from the same problems that reply suffers from.
> 
> The motivation for reply-to munging is that, in its absence, a typical
> user has no easy way to follow up without the problem of duplicates
> discussed above.

The problem of duplicates won't be solved by a followup-to header,
in any way that couldn't be solved by use of reply-to.

Let's take this message as an example.  If my preference is for replies
to this message to go to me only, I can set "reply-to: [email-masked]".
If my preference is for replies to go to the 822ext list only, I can
set "reply-to: [email-masked]".  If my preference is for replies
to go to sender and all recipients, but to get only one copy of the
message, I can set "reply-to: [email-masked], [email-masked]"
The recipient of the message can of course override my defaults.

Some, perhaps most, UAs will not do what I intend: e.g. if the recipient
uses "reply to sender" they will send the reply to the reply-to
address, but if the recipient uses "reply to all" they will send 
the reply to reply-to+to[+cc].  In which case I'll get a duplicate.
Followup-to won't fix this: for the forseeable future UAs won't
either recognize it or generate it.  By the time UAs do recognize it,
lists will mung it.   If the followup-to field is somehow specified
so that lists don't mung it, lists will want their own header that 
specifies how to send mail to the list (further increasing the
complexity of UAs' reply operations).

> If, on the other hand, his MUA supports a followup field, subscribers
> suddenly have the ability to eliminate those duplicates.

But the followup-to field would also be used in other ways, just
as reply-to has been used in other ways.  It would increase the
degree of variation in UA behavior and thereby increase  user
confusion and tech support costs.  If anything, it seems like
we have plenty of experience with reply-to that indicates that
yet another header to "control" where replies go is a Bad Idea.

> Once the followup field is universally supported, the motivation for
> reply-to munging will be gone.

There's a lot more motivation for reply-to munging than duplicate
suppression.  Some lists want to keep discussion on the list.
Some lists want to keep discussion off of the list.
Some lists are built with the assumption that recipient's UAs
are broken and can't reply to To or Cc addreses.  (If these UAs
aren't yet fixed to allow replies to To/Cc, how likely is it that 
they will be "fixed" to support followup-to?)  Many lists are set
up to mung reply-to based on the false assumption that "lists are
supposed to work this way", proabably because of experience with
LISTSERV and listproc and other header-munging list software.
(LISTSERV was originally written for BITNET where almost none
of the UAs in use could reply to other than a single address).

> > Once you have defined the new feature, convince people that the new feature
> > is worth implementing and supporting.  *Then* worry about what to call
> > the header field.
> 
> Is there anyone other than Keith who's confused about the function and
> benefits of a followup field?

I freely admit that I'm confused about what exists in your mind.

Most people can argue with some flexibility: by clearly communicating
their ideas, tolerating some difference in definitions from one
person to another, using intuition to guess what someone else means
in the absence of precise specification, and not assuming that others
will uniformly adopt their world-view.  You don't seem to be capable
of any of these.  Consequently, the only reason to discuss things
with you at all is for damage control -- to demonstrate to others
that your ideas aren't well formed.  Which is not to say that you 
never have good ideas, but you are apparently incapable of adapting
your ideas to accomodate others' experience.  The surest way
to destroy a potentially useful suggestion is for you to argue about it,
because you'll exhaust anyone who tries to modify it based on their
own experience.

Your tendency to name calling, misstating others positions,
reiterating positions that have been modified,  diverting
from the original argument and finding something else to attack
when you start to lose, "wife beating" attacks, and non sequitors
and other lapses of logic, do not lend credibility to your
arguments.

Keith

Date: 3 Jul 1997 16:28:33 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

> users don't have the information
> necessary to set a followup-to email header correctly,

The user simply has to

   (1) create a followup field from Reply-To/To/Cc or From/To/Cc, and
   (2) remove his address if it's covered by a mailing list.

Exactly which information is he missing?

#1 is trivial to do automatically. #2 is also trivial for MUAs that know
which lists the user is on, such as mutt.

> Group-Reply-Pref: exclude-me

This is the Mail-Copies-To approach. It covers many simple situations,
as I mentioned---for example, the default situation described above.

However, I prefer a followup field, for the same reason that I like
having a followup field in news: it's more flexible. For example, I can
manually redirect a crossposted discussion away from an inappropriate
mailing list.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

Date: Thu, 03 Jul 1997 02:17:39 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: best name for followups?
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

I find the arguments in:
	<http://www.unicom.com/FAQ/reply-to-harmful.html>
very technically compelling.  I'd love to know of any way to make it
politically compelling...

I also find Keith's comment that users don't have the information
necessary to set a followup-to email header correctly, and won't want to
enter one manually compelling; although I disagree that reply-to offers
sufficient functionality.

I think the current situation is broken as I hate having to manually edit
people out of headers all the time and worry that some of the people I'm
removing might not be on the list. 

Now what information does the person who sends to a list have which is
useful to know?

I think there are three useful preferences the sender can communicate:
(1) Keep my personal address in all group replies.
(2) I read the list; but like to get a bcc of group replies to messages I
    post.
(3) I read the list; so don't use my personal address in replies.

What about a new header which simply communicates this information?

Group-Reply-Pref: include-me
Group-Reply-Pref: bcc-me
Group-Reply-Pref: exclude-me

Defaults to "include-me" if not present since that's current practice and
we don't want to surprise users with a behavior change.  If this got
deployed I know a bunch of people who would love to use it.

		- Chris

Date: 3 Jul 1997 00:16:05 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: best name for followups?
Sender: [email-masked]

Keith says that users can control replies with Reply-To (in the absence
of reply-to munging). I agree. However, users currently have no way to
control followups.

Keith then suggests that there's no need for users to control replies
and followups separately. That's absurd. One of the big munging harms
discussed in http://www.unicom.com/FAQ/reply-to-harmful.html is the
user's inability to control replies.

Next Keith proposes using Sender in place of From, using From to control
replies, and using Reply-To to control followups. This is a massive
change from the RFC 822 Reply-To semantics supported by dozens of
existing clients. The transition would be a disaster.

> There's a difference between a human making an intelligent choice
> about where she wants her replies to go,

Here Keith is referring to people deleting recipients from followups.
The problem is that these people don't have the information they need:
are those recipients members of the mailing list? The result is that
non-subscribers are often accidentally removed.

> And if a followup-to field were introduced, lists would add or mung
> that field also, along with reply-to.

If Keith doesn't understand why Reply-To munging happens right now, he
should read http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto. The
more clients that support a followup field, the less motivation there is
for this type of munging.

> A UA that blindly copy followup-to to followups, creates much the same
> problem as list robots that blindly mung reply-to.

If Keith doesn't understand the harms caused by Reply-To munging, he
should read http://www.unicom.com/FAQ/reply-to-harmful.html.

> Followups are an artifact of the netnews environment, where you have
> separate address schemes for email and netnews.

Nonsense. Replies and followups are fundamentally different operations.
Practically every mailer supports both replies and followups.

This has nothing to do with the difference between mail addresses and
news addresses.

> having two different address schemes creates lots of problems.

I agree. One solution is to integrate the newsgroup address space into
the mail address space. Here's a working example:

   To: [email-masked], [email-masked]

It would be easy to set up a global usenet.news domain, configured
locally to talk to a nearby NNTP server.

Newsgroups are simply high-volume mailing lists with many entry points
and a fancy distribution mechanism.

> But in the email world there's no inherent distinction
> between "public responses" and "private responses" and it's silly to
> pretend that there is one.

Every popular MUA supports both replies and followups.

> You can define some notion of "followup"
> for email using a followup-to header, but doing so doesn't add any new
> services -- it just replicates services that already exist.

False. It provides a direct way to control followups; this feature does
not exist right now. MUAs will check the followup field before checking
From/To/Cc or Reply-To/To/Cc.

Many simple situations can be handled with the proposed Mail-Copies-To
field, which says whether to include the sender in followups, but a
followup field is a much more direct solution.

> > Explanation, please. Who exactly would be confused?
> Besides you?  (sorry, that was too easy.)

I find this comment rather amusing, given the number of ridiculous
statements that Keith has made in this discussion---claiming that the
followup field is for MLMs to set, claiming that the widely recognized
problem of duplicates doesn't exist, claiming that the problem is solved
by MUA duplicate elimination, etc.

> Users who are confused by existing reply options would be even more confused
> by the addition of followup options which basically do the same thing
> as replies.
  [ ... ]
> Support for followup-to would require that UAs add other commands
> ("followup", "set followup-to") in addition to the set above.  

Here Keith makes yet another stupid mistake: he seems to think that
followups are something different from the MUA's existing ``wide reply''
or ``group reply'' or ``reply to all'' feature.

One wonders how many times Keith needs to see the problem statement
before he understands it. Here it is again:

   Right now, when someone _follows up_ to a mailing list message from a
   subscriber, the subscriber and the mailing list are both in the
   followup's recipient list by default.

The obvious fix is to let the subscriber override the default _followup_
target, omitting his own address.

> > Explanation, please. How exactly would a followup field hurt anyone?
> I've already explained this.

Nonsense. Keith has explained bad consequences of two red herrings:
first, having MLMs munge the followup field; second, having followups
distinguished from reply-to-sender-and-recipients.

> First explain how "followup" would differ from "reply", beyond the
> fact that it would use different header names and that it's not
> supported by any of the installed base.

Nonsense. It's supported by most, perhaps all, of the installed base.
It's even supported by Berkeley Mail.

What isn't standardized is the _name_.

> Also please explain why it
> would not suffer from the same problems that reply suffers from.

The motivation for reply-to munging is that, in its absence, a typical
user has no easy way to follow up without the problem of duplicates
discussed above.

If, on the other hand, his MUA supports a followup field, subscribers
suddenly have the ability to eliminate those duplicates.

Once the followup field is universally supported, the motivation for
reply-to munging will be gone.

> Once you have defined the new feature, convince people that the new feature
> is worth implementing and supporting.  *Then* worry about what to call
> the header field.

Is there anyone other than Keith who's confused about the function and
benefits of a followup field? I don't see Keith's self-imposed blindness
as a major problem here; MUA implementors have never paid much attention
to him in the past, and aren't likely to pay attention to him now. The
introduction of Mail-Copies-To in two MUAs indicates that other people
understand the problem here.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: best name for followups? 
Date: Wed, 02 Jul 1997 16:44:33 -0400
Sender: [email-masked]

> It's important to understand that the author sets followups. Let me
> emphasize once again that reply-to munging is harmful; the question is
> how to fix the message duplication _without_ reply-to munging.

In this case, there's no need for a Followup-To header field.  The
existing Reply-To field (as defined in the current 822bis draft) is
sufficient to allow the author to specify his preference as to where
replies should go.

One could argue that Reply-To is broken because so many lists mung it,
and because so many UAs use it only as a replacement for the "From"
address, when doing a "reply to sender and recipients".

I don't really think there is a big need to allow a sender to
separately specify "reply to address-list X if you want to just reply
to me", and "reply to address-list Y if you want to followup".  Even
for those times when this is needed, the author can use From for the
former, and Reply-to for the latter. (With Sender used to indicate the
author's "real" address)

> > And a followup-to like header is certainly not "the" only available
> > solution.  For instance, UAs could suppress duplicate messages.
> 
> Suppressing duplicates is fine, if you can afford to do it securely, but
> it solves only half the problem.
> 
> After a long sequence of followups---let's say a sequence of 500
> messages from different contributors---there are, with current defaults,
> 501 recipient addresses in the header. Software breaks. Humans can no
> longer read the header. Each new message takes ten times as much archive
> space as it should. Every contributor is at risk of being a permanent
> recipient of a neverending discussion; there is no escape.

The existing Reply-To header could be used to prevent such problems.
Why isn't it used that way more often?  Because humans blindly reply
to their mail without checking the recipient list, or because UAs
don't encourage people to check the recipient list when forming
replies, or because UAs don't make it easy to change the recipient
list.  None of these problems can be fixed by adding another frob to
the mail protocol.

> Of course, people don't let the header grow so much. They trim it down
> to just the list address. But this introduces some of the same problems
> as reply-to munging; for example, it destroys cross-posted discussions.

There's a difference between a human making an intelligent choice
about where she wants her replies to go, and a list robot that blindly
(and often incorrectly) assumes that replies should go to the entire
mailing list.

And if a followup-to field were introduced, lists would add or mung
that field also, along with reply-to.

> With a followup field, the solution is trivial: the MUA copies the
> message's followup field into subsequent followups by default.

A UA that blindly copy followup-to to followups, creates much the same
problem as list robots that blindly mung reply-to.

> > Even if you only have reply, sometimes you want to reply to author
> > only, sometimes to author and all recipients, sometimes to author and
> > particular recipients, etc.
> 
> So what? Are you going to argue that we shouldn't have Reply-To since
> people sometimes want followups instead?

Followups are an artifact of the netnews environment, where you have
separate address schemes for email and netnews.  Depending on how you
look at it, this was a big mistake, or an accident of history, but
having two different address schemes creates lots of problems.
Propagating any of this mess into the email world is a Bad Idea.

People who have used netnews are accustomed to the notion of public
responses (aka "followups") as opposed to private responses (aka
"email").  So they may tend to think that their email UA should have a
"followup" button (and UAs for both email and news do have such a
button).  But in the email world there's no inherent distinction
between "public responses" and "private responses" and it's silly to
pretend that there is one.  You can define some notion of "followup"
for email using a followup-to header, but doing so doesn't add any new
services -- it just replicates services that already exist.  It might
makes people feel better because there's something for the followup
button to do, but it's not useful purpose.

> > Add a followup-to
> > (wide-reply-to, group-reply-to whatever) field to the mix and it just
> > makes things more confusing.
> 
> Explanation, please. Who exactly would be confused?

Besides you?  (sorry, that was too easy.)

> Users will have a button for replies, just as they do now.
> 
> Users will have a button for followups, just as they do now.

Good UAs already have separate commands for reply-to-sender and
reply-to-sender-and-recipients.  Ideally, users should be able to
override reply-to for those cases where they really want to send the
message somewhere else, so you need a way to do that.  And users need
to be able to set their reply-to and from addresses on outgoing mail.

This is already getting confusing for most users -- who don't
understand why "reply" doesn't "do the right thing".  (these same
users would never have such a problem with snail mail -- they'd simply
address the snail mail reply to whomever they thought should receive
it.)

Support for followup-to would require that UAs add other commands
("followup", "set followup-to") in addition to the set above.  Users
who are confused by existing reply options would be even more confused
by the addition of followup options which basically do the same thing
as replies.  They'll make more mistakes, there will be more variation
in behaviors between different UAs (thus confusing authors who expect
that their recipients' UAs work the same as theirs), and there will be
more calls to Tech Support.

> > What we haven't had is
> > agreement that such proposals, if adopted, would do more good than
> > harm.
> 
> Explanation, please. How exactly would a followup field hurt anyone?

I've already explained this.

> > We've already had proposals for a name.
> 
> I know. I don't think ``Wide-Reply-To'' will work. As you can easily
> verify, ``wide reply'' is meaningless for a typical user. (``Does that
> have something to do with the window size?'') Even when the MUA has a
> ``wide reply'' feature, most users have no clue what it does.
> 
> ``Group reply'' is somewhat better (and apparently more common in MUAs),
> but still not immediately clear to most users.
> 
> Any other suggestions?

First explain how "followup" would differ from "reply", beyond the
fact that it would use different header names and that it's not
supported by any of the installed base.  Also please explain why it
would not suffer from the same problems that reply suffers from.  Once
you have defined the new feature, convince people that the new feature
is worth implementing and supporting.  *Then* worry about what to call
the header field.

Keith