Re: header-munging

"Randall C. Gellens" <RANDY@mpa15ab.mv.unisys.com> Tue, 06 August 1996 22:55 UTC

Received: from ietf.org by ietf.org id aa23543; 6 Aug 96 18:55 EDT
Received: from cnri by ietf.org id aa23539; 6 Aug 96 18:55 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa16650; 6 Aug 96 18:55 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id SAA10711; Tue, 6 Aug 1996 18:23:48 -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 SAA10682 for <ietf-smtp@list.cren.net>; Tue, 6 Aug 1996 18:23:26 -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 WAA22162; Tue, 6 Aug 1996 22:23:21 GMT
Received: from MPA15AB.MV.UNISYS.COM by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8) id AA17134; Tue, 6 Aug 96 22:21:12 GMT
Message-Id: <EJHR1635246945@MPA15AB>
Date: Tue, 06 Aug 1996 15:16:35 -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: Michael D'Errico <michael.derrico%software.com@mv.unisys.com>
Cc: djb%koobera.math.uic.edu@mv.unisys.com, ietf-smtp%list.cren.net@mv.unisys.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: header-munging
In-Reply-To: Your message of "6 Aug 1996 14:56:30 -0700"
References: <19960806213953026.AAA1272@bonn.software.com>
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On Tue, 06 Aug 1996 14:34:28 -0700, Michael D'Errico <michael.derrico@
software.com> wrote:

> > > Comments on draft-gellens-smtp-submit-00.txt are appreciated.
> >
> > Instead of an SMTP extension, why not use a different TCP port?
>
> I won't comment on that, but....
>
> > [....] If the client can't produce [....] a correctly formatted
> > message, and the server won't accept incorrectly formatted
> > messages, the situation is hopeless.
>
> ....this is exactly why I don't like the SUBMIT idea either.

But this is rarely the case.  More commonly, the client produces a
message which is often good enough, but should be better (for example,
it lacks a Message-ID, and the Date is either missing or incomplete),
and the server either passes everything through as is, or attempts to
fix messages.  If it attempts to fix messages, it might do this for
every message, or for messages it guesses are being submitted.

The SUBMIT extension makes it very clear that the client is giving the
server permission to attempt any fix-ups that might be needed.  The
draft also lists tests which can be used for the server to guess at
message submission if SUBMIT isn't used.

Examples of clients which fail to produce Message-ID and/or proper Date
headers are everywhere, as are examples of servers which munge messages
(often all messages) in an attempt to fix them.

So the SUBMIT extension takes real-world situations and makes them more
deterministic.

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