Re: header-munging

"D. J. Bernstein" <djb@koobera.math.uic.edu> Mon, 23 September 1996 21:58 UTC

Received: from cnri by ietf.org id aa09893; 23 Sep 96 17:58 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa11547; 23 Sep 96 17:58 EDT
Received: from localhost (localhost.0.0.127.in-addr.arpa [127.0.0.1]) by list.cren.net (8.7.6/8.6.12) with SMTP id RAA28413; Mon, 23 Sep 1996 17:19:33 -0400 (EDT)
Received: from koobera.math.uic.edu (KOOBERA.MATH.UIC.EDU [128.248.178.247]) by list.cren.net (8.7.6/8.6.12) with SMTP id RAA28399 for <ietf-smtp@list.cren.net>; Mon, 23 Sep 1996 17:19:22 -0400 (EDT)
Received: (qmail 9636 invoked by uid 666); 23 Sep 1996 21:24:05 -0000
Message-Id: <19960923212405.9635.qmail@koobera.math.uic.edu>
Date: Mon, 23 Sep 1996 21:24:05 -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.1 -- ListProcessor(tm) by CREN

> NONE of the proposals which use SMTP in any way to do "fixup" of
> submitted messages are ANY more likely (certainly not "significantly"
> more likely) to produce correct messages than the status quo.

Wrong.

The following very real situation is a growing part of the status quo:

   Netscape sends an 822-violating message through qmail-smtpd, which
   passes the message on without inspecting it. The message ends up at
   the recipient with something like ``Sender: joe''---no domain name.

Some people change their configuration as follows:

   Tell qmail-smtpd to fix up messages from particular IP addresses.
   Now, when Netscape sends its 822-violating message, qmail-smtpd takes
   the time to convert ``Sender: joe'' into ``Sender: joe@what.ever''.

This produces the desired results in many cases where the original
situation did not. Your assertion to the contrary is completely wrong.

One of the proposals here is as follows:

   Run qmail-smtpd on another port, fixing up all incoming messages.
   Configure Netscape to use that port.

Again, this is much more likely to produce correct messages than the
original situation. Your assertion to the contrary is completely wrong.

---Dan