Re: header-munging

"Randall C. Gellens" <RANDY@mpa15ab.mv.unisys.com> Mon, 12 August 1996 18:23 UTC

Received: from ietf.org by ietf.org id aa05530; 12 Aug 96 14:23 EDT
Received: from cnri by ietf.org id aa05526; 12 Aug 96 14:23 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa10647; 12 Aug 96 14:23 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA10592; Mon, 12 Aug 1996 13:14:38 -0400
Received: from bbmail1.unisys.com (192-63-2005.unisys.com [192.63.200.5]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA10580 for <ietf-smtp@list.cren.net>; Mon, 12 Aug 1996 13:14:22 -0400
Received: from mvdns1.mv.unisys.com (mvdns1.mv.unisys.com [192.59.253.100]) by bbmail1.unisys.com (8.7.3/8.6.12) with SMTP id RAA28867; Mon, 12 Aug 1996 17:14:39 GMT
Received: from MPA15AB.MV.UNISYS.COM by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8) id AA06675; Mon, 12 Aug 96 17:14:24 GMT
Message-Id: <EJOM144793694B@MPA15AB>
Date: Mon, 12 Aug 1996 10:14:47 -0700
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: "Randall C. Gellens" <RANDY@mpa15ab.mv.unisys.com>
To: "D. J. Bernstein" <djb%koobera.math.uic.edu@mv.unisys.com>
Cc: ietf smtp mailing list <ietf-smtp%list.cren.net@mv.unisys.com>
Subject: Re: header-munging
In-Reply-To: Your message of "11 Aug 1996 11:30:01 -0000"
References: <19960811113001.3802.qmail@koobera.math.uic.edu>
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On 11 Aug 1996 11:30:01 -0000, djb@koobera.math.uic.edu (D. J.
Bernstein) wrote:

> Rewriting causes these problems.  To improve the situation, we have to
> reduce the amount of rewriting.  How could we do this with ESMTP
> options?
>
> One possibility is to give the client a way to say ``Hey, don't
> rewrite this!'' If sendmail sees this, it can skip rewriting.  Good.
>
> But that's not what SUBMIT does.  SUBMIT gives the client a way to say
> ``Hey, _do_ rewrite this!'' How is sendmail supposed to take advantage
> of that?  Will it skip rewriting if the client _doesn't_ say this?
> No%--- that would cause trouble for older clients that don't
> understand the option but that do need rewriting.  So how is this
> supposed to help?

It might be a good idea to extend SUBMIT so that the client can say
either SUBMIT or RELAY.  If the client says RELAY, that tells the MTA
not to muck with the message at all (except of course to add a received
header).  If the client says SUBMIT, that gives the MTA permission to
fix the message in any way the MTA decides is needed.  If the client
says neither, the MTA can choose to examine the message according to
the suggestions in the I-D and treat it as either a submission or a
relay (for example, if there are no received headers and the client is
within the MTA's domain, it is likely to be a submission).


--
|Randall Gellens             |                    randy@mv.unisys.com|
|(714) 380-6350              | fax (714)597-8053 can add ,,,,,,,,6350|
|Opinions are personal;  facts are suspect;   I speak only for myself|