Date: 29 Feb 1996 06:40:37 GMT
Message-ID: <19960229064037.17741.qmail@koobera.math.uic.edu>
From: djb@koobera.math.uic.edu (D. J. Bernstein)
To: drums@cs.utk.edu
Subject: Re: comments from a newcomer

> The real point here, I think, was that a server should not simply
> close a connection without sending some error code.

This is analogous to the QUIT requirement. I agree with what Ed Taft
said in 1983: ``What is supposed to be the problem with simply closing
the connection? The QUIT handshake seems entirely redundant. I know TCP
close has rather peculiar semantics in some implementations (e.g., the
Tops20/Tenex TCP) and is therefore somewhat flakey; but such problems
should be fixed at the TCP level rather than adding useless baggage to
higher-level protocols.''

I realize that the useless baggage is rather well entrenched here, and
that some clients and servers complain at sudden EOF; my SMTP server
gives a 451 on timeout. But this is not an example of good protocol
design. Anyway, don't use 5xx.

> The entire purpose of the 7-bit restriction was to prevent conflicts.

What is an SMTP relay supposed to do if it receives an 8-bit message?
Rejecting (or corrupting) the message is a violation of ``be liberal
with what you accept.'' Forwarding the message is a violation of ``be
conservative with what you send.''

There is one very easy way to make this conflict disappear: drop the
SMTP restriction on which characters can be sent.

I see some MTAs that actively corrupt 8-bit messages with MIME headers,
in the name of RFC 821. That's a disaster. It has to be stopped. An X
user who declares his charset, in the hopes of permitting automatic
charset translation for PC users with MIME, will find his message
rendered unreadable to X users without MIME. This destroys what would
otherwise have been a safe upgrade path to MIME.

> That's fine as a hint, but we already have set a direction for how a
> client finds out whether a server supports EHLO. 

Right. The main disadvantage to your approach is speed. People aren't
going to want to use an always-EHLO client, since that means slowing
down most of the outgoing mail.

> Standardizing the
> use of " ESMTP" in the greeting changes that direction and works to
> the disadvantage of servers that meet the ESMTP standard but don't 
> advertise such.

Which servers are those? I've checked a whole bunch of hosts, and
_none_ of them support ESMTP without saying so in the greeting line.
Why not standardize what people are already doing?

---Dan