Message-Id: <199512061839.MAA01027@jean-baptiste.internetMCI.ietf.org>
To: drums@cs.utk.edu
From: Eric Allman <eric@sendmail.org>
Subject: comments on draft-ietf-drums-smtpupd-01.txt
Date: Wed, 06 Dec 1995 12:39:26 -0600
Sender: eric@CS.Berkeley.EDU

Following are my comments regarding specifics of the SMTP update
document -- that is, I'm not going to comment on structural issues,
which we discussed in the WG meeting.  I'm also not going to comment
on the semantics of VRFY, since we already have a thread running on
that topic.

------------------------------------------------------------------------------

Section 2.2.1.  Extensions might feasibly extend commands other than
MAIL FROM and RCPT TO; point (3) should probably read ``additional
parameters to SMTP commands''.

Section 2.2.2.  Points (5) and (7) -- same comments.

Section 3.1.  Reference to EHLO in title is incorrect; this is the
initial connection establishment.

Sections 3.1 and 3.2 should mention that the first word of the
response must be the FQDN.

Section 3.5 should mention that EXPN is listed as an extension in
ESMTP.

Section 3.5.1.  ``Paths (explicit source routes) MUST NOT be returned
by VRFY or EXPN.''  What if you EXPN an alias that has such a route?
Given that we seem to be converging on EXPN as a debugging tool, I
urge relaxation of the restrictions on EXPN responses.  For example,
if you EXPN a user who forwards their mail to a program and leaves a
copy in a file, the current semantics require that I return something
like:

	250-Joe User </home/juser/mail.log@this.host>
	250 Joe User <|procmail@this.host>

However, these are not legal addresses if given in an RCPT command
(since you can't send directly to programs or files).  My suggestion
is to have EXPN return the internal form, even if that doesn't make
sense from another host -- e.g.,

	250-Joe User </home/juser/mail.log>
	250 Joe User <|procmail>

Section 3.5.2.  My recollection is that VRFY is not listed as an
ESMTP extension in the current RFCs (EXPN is).

Section 3.10.  I don't see any advantage to adding a new 5yz code
for idle shutdown.  In fact, I think using a 5yz code at all is a
mistake, since it makes an existing implementation return a permanent
failure on a command that might succeed.  I don't see what is wrong
with using 421, which is specifically designated as a legal reply to
any command if the service is shutting down.

Section 4.1.1.1 seems to imply that HELO/EHLO imply RSET, that is,
the following sequence of commands is legal:

	EHLO some.host
	MAIL FROM:<userA@some.host>
	EHLO some.host
	MAIL FROM:<userB@some.host>

and this sequence is illegal:

	EHLO some.host
	MAIL FROM:<userA@some.host>
	EHLO some.host
	RCPT TO:<userX@other.host>

I can guarantee that at least one popular MTA does not handle this
in this manner, and that the implied RSET semantics are difficult
to achieve.  I believe that either second and subsequent HELO/EHLO
commands should be ignored (that is, they return the standard
response but have no effect on the connection state) or should be
illegal (503 Bad sequence of commands) when not issued when the
connection is in a reset state (beginning of transaction or after
a DATA ".").  That is, the preceding two examples should be illegal,
but the following should be legal:

	EHLO some.host
	EHLO some.host
	MAIL FROM:<userA@some.host>
	RCPT TO:<userX@other.host>
	DATA
	.
	EHLO some.host
	...

Section 4.1.1.2 seems to imply that the following scenario is legal:

	MAIL FROM:<userA@some.host>
	RCPT TO:<userX@other.host>
	MAIL FROM:<userB@some.host>

That is, the second MAIL FROM implies RSET.  I can guarantee that
the same popular MTA does not and can not handle this properly, and
should be illegal (503 Bad sequence of commands).

Section 4.1.1.5.  RSET ``is effective equivalent to a NOOP if issued
immediately after EHLO or HELO'' should add ``another RSET or after
a DATA "." response.''

Section 4.1.1.6 and 4.1.1.7 should clarify if VRFY and EXPN are
legal at any point in a transaction -- e.g., can they be given in
the midst of a mail transaction?  Since the obvious implementation
of EXPN creates the send list and then prints it, I suggest that
these commands be limited to the "reset state" -- that is, the same
state a connection is in after an RSET command.

Section 4.1.2 needs to discuss IPv6 domain-literal syntax.  The use
of colons are probably problematic.

I had the impression from Stockholm that the WG had consensus to drop
the NUL byte from the list of legal characters (that is, in the <x>
non-terminal).

The example of "Joe\,Smith" is somewhat confusing -- are the quotes
part of the example or not?

The <from-domain> in a Received: line needs to be optional (albeit
encouraged); there are transports where this can not always be
determined.

Section 4.1.3 also mentions HELO/EHLO implying RSET -- same comments
as above.  It also explicitly says that EXPN and VRFY can be given at
any time -- same comments as above.

Section 4.2, ``the text [of an SMTP reply] may be receiver-dependent
and context dependent...'' is somewhat confusing until you realize
that ``receiver'' refers to the ``receiver-SMTP'' not to the receiver
of the SMTP reply; perhaps this can be made explicit.

Section 4.3.1 mentions ``Failure'' and ``Error'' conditions without
making the difference explicit.  In particular, since it itemizes
Failure and Error reply codes, what do you call something that is
not listed in either list?  This caused me some confusion when
implementing sendmail.  My understanding is that anything that is
not ``Success'', ``Intermediate'', or ``Failure'' should be an
``Error'', in which case the ``E:'' lines can be eliminated.  However,
this may not be what was intended, since 421 is legal everywhere but
is listed as an Error, not a Failure in most cases.

Section 4.4 says that the ``FOR field MAY contain a list of <path>
entries when multiple RCPT commands have been given.''  First, the
ABNF in 4.1.2 does not allow a list.  Second, this may expose Bcc:
recipients.

Section 4.6.3 should mention that some of the indicated limits may
be increased by ESMTP extensions.

Section 4.6.4.1 shows two sample command sequences without MAIL
commands; I suggest that the MAIL commands be inserted to avoid
confusion.

Section 5.2 suggests that examination of Received: lines for the
domain name is effective for preventing loops.  However, this is
not reliable.  For example, if list@hostA is a simple alias which
includes user@hostB, and user@hostB is forwarded to user@hostA, the
copy of the message that should be delivered to user@hostA will be
tossed as a duplicate, when in fact it is not.  I believe such
behaviour should be strongly discouraged.

Appendix F Scenario 10 (the ``too many recipients'' scenario)
incorrectly shows the user of the 552 reply code; this should be
452.

------------------------------------------------------------------------------

That's about it for now.

eric