Re: header-munging

Keith Moore <moore@cs.utk.edu> Tue, 17 September 1996 00:07 UTC

Received: from cnri by ietf.org id aa24657; 16 Sep 96 20:07 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa15256; 16 Sep 96 20:07 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id TAA17461; Mon, 16 Sep 1996 19:29:02 -0400
Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by list.cren.net (8.6.12/8.6.12) with ESMTP id TAA17412 for <ietf-smtp@list.cren.net>; Mon, 16 Sep 1996 19:28:36 -0400
Received: from localhost by ig.cs.utk.edu with SMTP (8.6.10/2.8c-UTK) id TAA09950; Mon, 16 Sep 1996 19:28:16 -0400
Message-Id: <199609162328.TAA09950@ig.cs.utk.edu>
Date: Mon, 16 Sep 1996 19:28:16 -0400
Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
From: Keith Moore <moore@cs.utk.edu>
To: ietf-smtp@list.cren.net
Cc: moore@cs.utk.edu
Subject: Re: header-munging
In-Reply-To: Your message of "Mon, 09 Sep 1996 15:54:28 PDT." <5549.842309668@odin.nma.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Sender: moore@cs.utk.edu
X-Mailer: exmh version 1.6.7 5/3/96
X-URI: http://www.cs.utk.edu/~moore/
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

Given the two options being proposed, I agree that a new port is
easier than an SMTP option.  However, this is beside the point.
Neither one of these solves the real problem.

In the general case, even the initial MTA is not in a good position to
"fix up" most mistakes or omissions made by the sender's UA.  For
example, assume that the MTA is run by an ISP (a very common
situation), and the UA runs on the client's machine:

+ The message may lack a Date field.  The ISP's MTA can't reliably 
  supply a correct one, because it may be (with high probability) in a
  different timezone than the sender.

  Even small ISPs have POPs in different cities that cross timezone
  boundaries.   

+ Some addresses in the message may lack domains or fully-qualified
  domain names.  The ISP's MTA can't supply these either, because
  if the user has his own domain, the ISP will use the wrong defaults
  for the DNS lookup.

Of course, the ISP could keep track of user/client defaults for
timezone and domain name on a per-subscriber basis, but this just adds
code and complexity to the ISP's MTA without making those fields much
more accurate than they would be if the users set them by themselves.

The problem is that UAs are generating illegal 822 messages.  The
solution is to fix the UAs, not to hack the MTAs to do dubious fixups.

If we're going to try to fix this problem by tweaking protocol, let's
define a protocol which helps a UA sanity-check its configuration.

For example, if an MTA returned GMT=xxxx in an EHLO response, the UA
could compare that value with its own time+timezone-offset, and
determine whether they were consistent.  A UA could say "I think my
domain is foo.bar" and the MTA could say "no, that's not a legal
domain".  (But wait...SMTP *already* has that capability!)

And if we're going to add an explicit submit protocol to SMTP, let's
fix it so that it works right: it should *reject* any submission
that's not in correct format.  That way, the problem gets fixed at its
source, instead of having the errors (including additional errors
caused by fixups) propagate downstream.

But of course it's hard to verify that a submission is correct.
There's no substitute for insisting the UA generate correct messages.

Keith