Date: 29 Feb 1996 00:41:04 GMT
Message-ID: <19960229004104.17097.qmail@koobera.math.uic.edu>
From: djb@koobera.math.uic.edu (D. J. Bernstein)
To: drums@cs.utk.edu
Subject: comments from a newcomer

I found draft-ietf-drums-smtpupd-01 a few days ago. A few comments.

> [[Note in draft: Keith and Ned suggest that we should invent a new
> error code to be sent by the server when it shuts down the connection
> because it has timed out waiting for a client command and that it
> should be a 5yz code (since nothing temporary is happening).

Are you people actively _trying_ to cause reliability problems?

Imagine, for example, that a RCPT packet is delayed; the server times
out; and the server sends 555 TIMEOUT. Would you say that ``nothing
temporary is happening''?

In fact, since a typical SMTP client doesn't pay attention to incoming
data until it's sent a command, it's hard to imagine how your proposed
timeout code could ever _avoid_ incorrectly bouncing mail!

> MUST NOT transmit messages with information in the high-order bit

Why not? If you're updating the SMTP spec, how about bringing it in line
with reality by dropping the 7-bit restriction? Europeans transmit 8-bit
messages all the time.

The current 7-bit restriction produces a blatant---and entirely
artificial---conflict between ``be liberal with what you accept'' and
``be conservative with what you send.''

> clients SHOULD preferentially utilize EHLO

SMTP is already painfully slow; it'll be many years before most servers
support ESMTP. Why not standardize the convention of putting " ESMTP"
into the greeting line to indicate that EHLO is acceptable?

> Implementations MAY make provision for SMTP servers to be
> configured to disable the software and version announcement where it
> causes security concerns. 

``Where it causes security concerns'' is EVERYWHERE. Anyone who controls
a DNS server can, right now, break into practically every machine on the
net that runs sendmail.

> Loop detection by examination of Received fields

See ftp://koobera.math.uic.edu/pub/docs/RFCLOOPS for how to do it right.

---Dan