Re: header-munging

"D. J. Bernstein" <djb@koobera.math.uic.edu> Tue, 17 September 1996 08:50 UTC

Received: from cnri by ietf.org id aa07501; 17 Sep 96 4:50 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa20811; 17 Sep 96 4:50 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA08297; Tue, 17 Sep 1996 03:26:10 -0400
Received: from koobera.math.uic.edu (qmailr@KOOBERA.MATH.UIC.EDU [128.248.178.247]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA08285 for <ietf-smtp@list.cren.net>; Tue, 17 Sep 1996 03:26:03 -0400
Received: (qmail 6362 invoked by uid 666); 17 Sep 1996 07:30:41 -0000
Message-Id: <19960917073041.6361.qmail@koobera.math.uic.edu>
Date: 17 Sep 1996 07:30:41 -0000
Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
From: "D. J. Bernstein" <djb@koobera.math.uic.edu>
To: ietf-smtp@list.cren.net
Subject: Re: header-munging
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

> Neither one of these solves the real problem.

There's more than one real problem in the universe.


The problem I'm concerned with is a very real interoperability problem:
a crappy MUA talking to a fast MTA ends up spewing garbage into the net.

Right now this problem is solved by bilateral agreement: the MTA will
take the time to fix up messages from certain IP addresses. A separate
port would solve it by IANA agreement.


Another problem I've mentioned is a very real speed problem for one
common MTA: sendmail does a lot of DNS lookups to fix up messages from
clients that don't want any fixups.

The RELAY extension would solve this problem. An alternative solution is
for sendmail to stop doing the fixups by default; of course, this causes
interoperability problems, just as it does for fast MTAs.


You seem to be concerned with a third problem: the aforementioned crappy
MUAs often generate messages missing crucial information. (For example,
what does a user mean by ``to: eric@cs''?)

To the extent that this is a problem, the obvious solution is for the
MUAs to generate more information.


---Dan