Re: header-munging

"Randall C. Gellens" <RANDY@mpa15ab.mv.unisys.com> Thu, 08 August 1996 18:25 UTC

Received: from ietf.org by ietf.org id aa18691; 8 Aug 96 14:25 EDT
Received: from cnri by ietf.org id aa18687; 8 Aug 96 14:25 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa11934; 8 Aug 96 14:25 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA01857; Thu, 8 Aug 1996 13:45:46 -0400
Received: from bbmail1.unisys.com (bbmail1.unisys.com [192.63.200.5]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA01845 for <ietf-smtp@list.cren.net>; Thu, 8 Aug 1996 13:45:42 -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 RAA21109; Thu, 8 Aug 1996 17:45:48 GMT
Received: from MPA15AB.MV.UNISYS.COM by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8) id AA29242; Thu, 8 Aug 96 17:45:44 GMT
Message-Id: <EJJM413422726A@MPA15AB>
Date: Thu, 08 Aug 1996 10:41:34 -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: mark%clipper.cb.lucent.com@mv.unisys.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: ietf smtp <ietf-smtp%list.cren.net@mv.unisys.com>
Subject: Re: header-munging
In-Reply-To: Your message of "7 Aug 1996 16:58:02 -0400"
References: <960807165802.ZM1220@starbase.cb.lucent.com>, <199608071533.LAA27114@black-ice.cc.vt.edu> <19960806213953026.AAA1272@bonn.software.com> <EJHR1635246945@MPA15AB> <EJIO2919FD3447@MPA15AB>
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On 7 Aug 1996 16:58:02 -0400, mark@clipper.cb.lucent.com wrote:

> Why can't the MTA do the fixup anyway?  sendmail has been doing this
> for years, and I'm not aware of any problems its caused.

As long as the MTA only does fixups on messages that are being
submitted, and never does fixups on messages that are being relayed,
all is well.  When MTAs "fix" relayed messages, the headers become
misleading.

The draft being discussed (draft-gellens-smtp-submit-00.txt) proposes
the SUBMIT extension as a way of being able to tell submission from
relaying.  It also proposes techniques for guessing in the absense of
the extension.

> What is the MTA to do if the client doesn't
> give permission?  Pass on a broken message that violates the RFC?

If the message is being relayed, the MTA should pass the message on, or
bounce it if it is feeling especially pedantic.  If the message is being
submitted, the MTA should consider fixing it.  The SUBMIT extension is
a way to tell submission from relaying.

SMTP was not designed for message submission.  It was designed for
relaying.  It is being used for message submission.  Knowing when a
message is being submitted allows the MTA to verify and fix the
message, and perform other actions.  Perhaps adding a Sender field if
the From does not match the user (assuming authentication is also being
used).


--
|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|