Re: header-munging

Mark Horton <mark@lucent.com> Mon, 23 September 1996 23:58 UTC

Received: from cnri by ietf.org id aa11208; 23 Sep 96 19:58 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa09758; 23 Sep 96 19: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 TAA01821; Mon, 23 Sep 1996 19:24:22 -0400 (EDT)
Received: from cbgw1.lucent.com (cbgw1.att.com [192.20.239.133]) by list.cren.net (8.7.6/8.6.12) with SMTP id TAA01805 for <ietf-smtp@list.cren.net>; Mon, 23 Sep 1996 19:24:06 -0400 (EDT)
Received: from clipper.cb.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id TAA25999; Mon, 23 Sep 1996 19:18:18 -0400
Received: by clipper.cb.lucent.com (SMI-8.6/EMS-L sol2) id TAA25957; Mon, 23 Sep 1996 19:18:24 -0400
Received: from starbase.cb.lucent.com by clipper.cb.lucent.com (SMI-8.6/EMS-L sol2) id TAA25950; Mon, 23 Sep 1996 19:18:21 -0400
Received: by starbase.cb.lucent.com (SMI-8.6/SMI-SVR4) id TAA07445; Mon, 23 Sep 1996 19:20:10 -0400
Message-Id: <960923192009.ZM7443@starbase.cb.lucent.com>
Date: Mon, 23 Sep 1996 19:20:09 -0400
Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
From: Mark Horton <mark@lucent.com>
To: ietf-smtp@list.cren.net
Subject: Re: header-munging
In-Reply-To: "D. J. Bernstein" <djb@koobera.math.uic.edu> "Re: header-munging" (Sep 23, 9:24pm)
References: <19960923212405.9635.qmail@koobera.math.uic.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Face: ndc&nER^htTr+=fQHFZ`KUb!Tf^[!Kdm+aFa@(|l3)*e'=r.Ab}#o<+HeG, @(KqfF3Z.%, P $TasGQyEt<@Yo?!L_Iu0U; D,')n#`rw?{`D6:'CVj)vpCbpizBQNc})j@m80vcvt*nF#1[Q%)SKaRd v}s@h}b+8b)}xB87jcld'5wd7aXYh%Ui6!Des@Q+x8s0(3nb0Q:myXM%9TLyGT(pRU%1)8$n:hT5u= &/[[>Oswh@;{V3FE#$X[5!rL6&7
X-Mailer: Z-Mail (4.0b.514 14may96)
X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN

On Sep 23,  9:24pm, D. J. Bernstein wrote:
> Subject: Re: header-munging
> > 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.

I have to agree with Dan on this one.

In the real world (somewhere down off the ivory tower) there are real
situations where incorrect headers (according to the RFC-822 view of the
world) get transmitted.  Examples include:

(1) People running a simply-configured client.  If the client knows its
fully qualified domain name (user@foo.subdomain.company.com) then when the
company gets bought, or sold, or reorganized, that must be changed to
user@foo.newsubdomain.newcompany.com.  If this reconfig has to happen on
every single client, it costs a zillion staff-hours.  If it only has to be
done on the server, it saves a couple orders of magnitude of work.  This
suggests that having every client know its full name is not such a great idea.
(Yeah, I know that att.com just became lucent.com, but we're the only company
that's ever been bought or sold or reorganized, right, the rest of the world
never has this problem.  :-)

(2) Gateways.  The real world has other systems besides the Internet.  Maybe
they will eventually go away.  Maybe.  But for the foreseeable future there
are UUCP, X.400, PROFS, cc:Mail, MS Mail, maybe even BITNET, to deal with.
There is a real major market for MTAs that are able to convert between these
various alien formats.  They are going to rewrite headers or they are not
going to sell any gateways.  If the next RFC-822++ comes along and says it
is now illegal to change any header, you have to either pass the message
intact or bounce it, what do you think the gateway vendors are going to do?
They're going to write a gateway that can be configured to run in pure 822
mode, or can be configured to rewrite headers, to meet the need of the
customer.
And I'll bet there are plenty of customers who have their own need to do
rewrites.

In fact, sendmail perfectly capable of passing 822 without changing a thing.
It's also capable of rewriting headers.  How you use it depends on how the
configuration file is set up.

There seem to be a lot of people voting with their sendmail.cf's that they
need to rewrite headers.  I have to wonder, if we pass a law that says that
header munging is illegal, how many of them will comply, and how many will
determine that they have some business need to mung anyway?

Improving the information available is a good thing.  Improving the quality
of any headers over the current status quo is a good thing.  But it seems
like the underlying message of the current proposal is a ban on rewriting
of headers.  I don't believe such a ban will have much effect in the real
world.

	Mark