Re: header-munging

"D. J. Bernstein" <djb@koobera.math.uic.edu> Tue, 06 August 1996 06:25 UTC

Received: from ietf.org by ietf.org id aa01322; 6 Aug 96 2:25 EDT
Received: from cnri by ietf.org id aa01318; 6 Aug 96 2:25 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa02460; 6 Aug 96 2:25 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id BAA27786; Tue, 6 Aug 1996 01:50:16 -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 BAA27774 for <ietf-smtp@list.cren.net>; Tue, 6 Aug 1996 01:50:08 -0400
Received: (qmail-queue invoked by uid 666); 6 Aug 1996 05:54:14 -0000
Message-Id: <19960806055414.19379.qmail@koobera.math.uic.edu>
Date: Tue, 06 Aug 1996 05:54:14 -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

> Comments on draft-gellens-smtp-submit-00.txt are appreciated.

Instead of an SMTP extension, why not use a different TCP port?

Advantage #1: Existing servers, including qmail 0.90+ and sendmail 8.8+,
can already be configured to handle this, with no code changes.

Advantage #2: Client support is very easy. In fact, you can make this
work with every existing client, with no code changes, if you have a
machine sitting around that currently doesn't use port 25. (Just have it
forward port 25 to the new port on the real server. Use a port 113 proxy
if you want the real server to know the client's IP address.)

Advantage #3: A separate TCP port makes it easy to set policy. Rewriting
a submitted message takes work---on occasion, hundreds of DNS lookups
for a single message. Most sites will want to control the availability
of this service. Existing firewalls already do the right thing.

Are there any advantages of the extension approach?

The advantage of SMTP extensions, in theory, is that the client can
connect and then modify its behavior on the basis of the extensions
offered by the server. I don't see how that could be helpful in this
case. If the client can't produce a correctly formatted message, and the
server won't accept incorrectly formatted messages, the situation is
hopeless. It's easier for both sides to say this with a refused TCP
connection than to say it with ESMTP.

Of course, many existing clients send invalid messages to port 25, by
out-of-band agreement with the server. They can continue to do so. What
we're trying to do for the future is provide an explicit agreement.

> It suggests using the <ietf-smtp@list.cren.net> mailing list.

ietf-smtp-request responds _extremely_ slowly. It isn't human, is it?

It really doesn't look good for all these e-mail-related lists to be so
many years (decades?) behind the state of the art in list technology:
continuing RFC 1123 violations on cs.utk.edu (``localhost'' is not a
FQDN, though perhaps it should be set up as one); non-automated list
subscription management all over the place; etc.

---Dan