Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA15201; Wed, 16 Aug 1995 18:22:04 -0400 X-Resent-To: drums@CS.UTK.EDU ; Wed, 16 Aug 1995 18:22:02 EDT Errors-to: owner-drums@CS.UTK.EDU Received: from SEARN.SUNET.SE by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA15194; Wed, 16 Aug 1995 18:21:59 -0400 Message-Id: <199508162221.SAA15194@CS.UTK.EDU> Received: from SEARN.SUNET.SE by SEARN.SUNET.SE (IBM VM SMTP V2R2) with BSMTP id 1374; Thu, 17 Aug 95 00:17:23 +0200 Received: from SEARN.SUNET.SE (NJE origin ERIC@SEARN) by SEARN.SUNET.SE (LMail V1.2b/1.8b) with RFC822 id 6959; Thu, 17 Aug 1995 00:17:21 +0200 Date: Thu, 17 Aug 1995 00:11:08 +0200 From: Eric Thomas Subject: Re: "Reply-To" To: Chris Newman , Keith Moore cc: drums@CS.UTK.EDU In-Reply-To: Message of Wed, 16 Aug 1995 17:42:04 -0400 from moore@CS.UTK.EDU On Wed, 16 Aug 1995 17:42:04 -0400 Keith Moore said: >So I'm proposing that we stretch "From" a tiny bit, from "the addresses >of those on whose behalf the message was sent" to "the addresses to >which replies-to-sender should be directed" in the name of better >interoperability (immediately) at little cost. You seem to forget that nowadays a lot of mail is sent to computer programs, as opposed to human beings. Today, "From:" is the person sending the message (and issuing the instruction to the program). If you change it to have the meaning of the current "Reply-To:" field, you will break a lot of applications and make a lot of unhappy users. Or rather, your change will be ignored and people will continue using "Reply-To:" the way they're doing today, because the customer is always right. Generally speaking, you can't make a change that significantly alters the current meaning without a Darn Good Reason - a reason that sales people can explain to their customers in a few minutes, and without losing the sale. Remember, if you don't provide what the users want, someone else will. It's a free market, and the people who ultimately select the standards are the users. So you have to make sure that whatever change you are proposing doesn't break things users have been relying on for years. Eric