Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199508170434.AAA01079@thud.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: Mark Crispin <MRC@panda.com.utk.edu>
cc: drums@CS.UTK.EDU, moore@CS.UTK.EDU
Subject: Re: "Reply-To" 
In-reply-to: Your message of "Wed, 16 Aug 1995 20:24:04 PDT."
             <MailManager.808629844.4753.mrc@Ikkoku-Kan.Panda.COM> 
Date: Thu, 17 Aug 1995 00:34:47 -0400
Sender: moore@CS.UTK.EDU

> It is also the case that many MUAs and MTAs, and a great many sites, forbid
> the user from altering the contents of the From: header in his outgoing mail,
> in a misguided belief that this "adds security".  The consequence of this is
> that many email users find themselves obliged to configure their MUAs so that
> a constant Reply-To: header is written on *all* of their outgoing mail.

Yes, this is true.  However, we are free to recommend that UAs NOT
impose such restrictions in the future.
 
> Any definitions arrived at by this group have to keep the above facts firmly
> in mind, along with the very great likelihood that it will not be possible to
> change any of these facts.  It would, therefore, be exceptionally foolish for
> a standard to be issued that introduces incompatible changes that will be
> ignored.

I think we have to make sure that no basic functionality is denied
because the sender cannot set the From field on his outgoing mail.  
However, even in 822 it is clearly intended that the sender be
able to do just that.  We aren't obliged to extend every bit of
Internet mail functionality to those with dysfunctional user agents.

> Nor did I see, at the time this WG was formed, any sentiment on the part of
> the IESG that supports such an alteration of fundamental functionality, NO
> MATTER HOW DESIRABLE IT MAY OTHERWISE BE.  Certainly, the addition of a new
> header for a portion of contemporary reply-type functionality is such an
> alteration.

We're not allowed to create new features.  We *are* allowed to fix existing
features that are demonstrably broken, due to design flaws, to 
ambiguities in the current specs, or to conditions not forseen when those
specs were written.  "Reply" is certainly a feature of 822, and to the
extent it appears to be broken or 822 seems to be ambiguous, we can try 
to fix it.

Our charter does not specify what mechanisms we can use.  If the mechanism 
we choose involves adding new headers, that's within our scope.

On the other hand, I'm quite confident that this group isn't going to
approve anything that has a significant negative impact on interoperability
with the installed base.
 
> If the esteemed members of this working group are unable or unwilling to
> accept the basic principles that (1) this is the status quo among mailer
> reading programs in the Internet and (2) you are not going to succeed in
> changing this, then there is no reason for me to participate any further in
> the discussions of this working group.  I wish to put my efforts into 
> projects that have some hope of being useful.

As for (1), we'll get a better idea of the status quo when the survey 
results come in.  I don't expect a representative sample, but it might
give us some idea of the spectrum.

As for (2), I see no harm in us providing recommendations to user agents
as to how they should do things in the future, provided those recommendations
don't seriously break things for the installed base.

> I may, however, protest to the IESG that this working group has exceeded its
> charter, which emphatically does *not* include any changes to the status quo.

Consider this message "from the chair".  If you have a dispute with this
ruling, please either respond privately to me or report it to the IESG 
ADs now, so that we won't be doing our work under false assumptions.

(note: I'll be out of town for the next couple of days; don't interpret
my failure to respond immediately as bearing on your response.) 

Keith