Message-ID: <0kt4IMm00WBwAICG5=@andrew.cmu.edu>
Date: Fri, 29 Dec 1995 14:44:24 -0500 (EST)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: drums@cs.utk.edu
Subject: smtpupd-01 issues

Section 2.3(2): I think it's improper to have the SMTP transport
define the message format this way, in terms of a header and body,
with different references for each.  I would word it something like:

	The SMTP content is sent in the SMTP DATA protocol unit and is
	a message as defined by [822-prime].

Section 3.3, paragraph 7 needs to be modified to deal with MX records.
Second sentence should be something like "If source routes are used,
the first domain in the forward-path SHOULD be the one currently being
delivered to."

Section 3.8, paragraph 7, I have to reiterate my opposition to the
statement "Of course, SMTP server should not send notification
messages about problems with notification messages" because following
that advice causes mail with unusable forward and reverse paths to be
silently discarded.  Suggested replacement text follows:

	This notification message must be from the SMTP server at the
	relay host or the host that first determines that delivery
	cannot be accomplished.  Of course, SMTP servers should avoid
	"notification loops", where delivery of a notification message
	causes delivery of another notification, and so on.  One way
	to avoid loops in error notification is to specify a null
	reverse-path in the MAIL command of a notification message.
	When such a message is transmitted the reverse-path SHOULD be
	set to "<>".  A MAIL command with a null reverse-path appears
	as follows:
	
		MAIL FROM:<>

	When an SMTP server cannot deliver a mail message which has a
	null reverse-path, it SHOULD notify the local postmaster or
	some other administrator of the delivery failure through some
	appropriate mechanism that will not itself result in the
	generation of a failure notification.  In particular the SMTP
	server SHOULD NOT interpret the null reverse-path as a request
	to suppress failure notifications.  Doing so would create an
	interesting situation when a message arrives with one or more
	nonfunctional forward-paths in addition to a nonfunctional
	reverse-path.  When delivery to one of the recipient addresses
	fails, the SMTP server will attempt to send a failure
	notification to the reverse-path, setting the reverse-path on
	the notification to "<>".  When the delivery of this
	notification fails, the SMTP server attempting delivery of
	that notification sees a null reverse-path.  If that SMTP
	server were not to inform anyone of the situation, the
	original message would be silently lost.  Furthermore, a
	nonfunctional reverse-path is often indicative of a
	configuration problem in the sender's MTA.  Reporting the
	condition to the local postmaster may help to speed correction
	of such errors.

Section 3.10: I disagree with the "MUST NOT" directive added here.
Simply closing the connection on a timeout has proved to work quite
well in practice.  The directive appears to be aimed at past
implementations which closed connections in response to unrecognized
commands.  I believe we should limit the scope of the solution to that
particular problem--the spec should simply state that implementations
MUST handle an unrecognized command by returning a 500 reply and
no 4xx or 5xx reply should cause a change in protocol state [except
for the initial greeting].

Section 4.2.3: The 502 reply code is functionally indistinguishable
from 500.  Perhaps we should just mark 502 as being
obsolete/deprecated.

Section 4.4, paragraph 8: "It is sometimes difficult for an SMTP
server to determine..."  I disagree strongly with this sentence and
believe the paragraph should simply be removed.  There is an important
model of a mail delivery which includes message submission on one end
and final delivery on the other.  A non-SMTP 822-based transport may
tunnel the reverse-path information in the Return-Path: header, or a
recipient may re-submit a message to the transport system, but these
are two completely different and distinguishable situations.

Section 4.6.3: "too many recipients" is a transient condition.
Instead of 552, it should instead use 452.

Section 6.2: the privacy concern does not exist when there is exactly
one forward-path address.  In that situation only, the forward-path
should be placed in the "for" clause of the timestamp (Received:
header).

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up