Re: header-munging

"D. J. Bernstein" <djb@koobera.math.uic.edu> Sun, 18 August 1996 20:00 UTC

Received: from ietf.org by ietf.org id aa17592; 18 Aug 96 16:00 EDT
Received: from cnri by ietf.org id aa17588; 18 Aug 96 16:00 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa09625; 18 Aug 96 16:00 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id PAA26601; Sun, 18 Aug 1996 15:20:52 -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 PAA26585 for <ietf-smtp@list.cren.net>; Sun, 18 Aug 1996 15:20:32 -0400
Received: (qmail-queue invoked by uid 666); 18 Aug 1996 19:24:44 -0000
Message-Id: <19960818192444.28973.qmail@koobera.math.uic.edu>
Date: 18 Aug 1996 19:24:44 -0000
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
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

There are two different problems here.


1. Randall, Arnt, and I agree that the problems caused by sendmail's
rewriting---message corruption and slow message handling---can be
addressed by a RELAY extension that says ``don't rewrite this!''

I share Tim's concern about the difficulty of implementing RELAY. Keith
notes that this is ``100-200 lines of code, tops,'' but an SMTP client
module is only a few hundred lines of code to begin with.

However, to the extent that RELAY is implemented, it will improve the
sendmail rewriting situation.


2. There is a growing interoperability problem of 822-ignorant clients
talking to fast SMTP servers that, unlike sendmail, don't normally
rewrite incoming messages.

This problem is handled right now as follows: the server looks for IP
addresses of the bad clients, and diverts their messages to a fix-up
program. The server administrator has to tell people how to configure
their clients _and_ has to find out what IP addresses they'll be using.

It would be much better to use a separate TCP port. This is what Tim's
draft provides. Now the server administrator just has to tell people to
configure their clients to use that port. Management is much easier.

Randall said that a client, after failing to connect to the separate TCP
port, would have to connect to the usual SMTP port. But I don't see how
this could be useful. (Apparently Keith agrees.)


---Dan