Re: header-munging

"John W. Noerenberg" <jwn2@qualcomm.com> Sun, 18 August 1996 02:44 UTC

Received: from ietf.org by ietf.org id aa06832; 17 Aug 96 22:44 EDT
Received: from cnri by ietf.org id aa06828; 17 Aug 96 22:44 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa13397; 17 Aug 96 22:44 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id WAA07909; Sat, 17 Aug 1996 22:05:03 -0400
Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.52.129]) by list.cren.net (8.6.12/8.6.12) with ESMTP id WAA07832 for <ietf-smtp@list.cren.net>; Sat, 17 Aug 1996 22:04:44 -0400
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.50.61]) by warlock.qualcomm.com (8.7.5/1.2d/8.7.2/1.12) with ESMTP id UAA21149 for <ietf-smtp@list.cren.net>; Fri, 16 Aug 1996 20:37:16 -0700 (PDT)
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by mage.qualcomm.com (8.7.5/1.4d/8.7.2/1.11) with ESMTP id UAA29083; Fri, 16 Aug 1996 20:33:44 -0700 (PDT)
Message-Id: <v03007821ae3aea99c46c@[129.46.166.223]>
Date: Fri, 16 Aug 1996 20:24:53 -0700
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: "John W. Noerenberg" <jwn2@qualcomm.com>
To: Tim Goodwin <tim@uunet.pipex.com>, "Randall C. Gellens" <RANDY@mpa15ab.mv.unisys.com>
Cc: ietf smtp list <ietf-smtp@list.cren.net>
Subject: Re: header-munging
In-Reply-To: <AABNGDIRrhgADtyk@pipe.pipex.net>
References: <EJPN0542AC3462@MPA15AB>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Sender: jwn2@mage.qualcomm.com
X-Mailer: Eudora [Macintosh version 3.0]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

At 11:44 AM +0100 8/14/96, Tim Goodwin wrote:
>
>I suppose, maybe, if you're a client that already does ESMTP but submits
>broken messages, there might be some point in using SUBMIT.  Such
>clients are currently a tiny minority.  For other clients, it would be
>simpler to generate conforming RFC 822 messages in the first place.

You are assuming it is always possible for the submitting client to
generate the correct headers.  In the case of a list manager that is fixing
up headers for list distribution, it is reasonable to suppose that it may
be in a better position to generate the correct Reply-To and Sender headers
than the submitting client, for example.

>
>If we truly hope to overcome the inertia of the status quo, we need
>something that's trivial to implement on the client side (and preferably
>the server side, too, although that's slightly less important).

Agreed.

john noerenberg
jwn2@qualcomm.com
  --------------------------------------------------------------------
  Once the land touches you, the wind never blows so cold again.
  You feel for the land like it was your child.  When that happens
  to you, you can't be bought.
  -- W. P. Kinsella, "Shoeless Joe", 1982
  --------------------------------------------------------------------