Re: Suggestions on SMTP enhancement drafts

[Ned Freed <[e-mail]>]

> From: Paul Robinson <[e-mail]>
> Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
> -----
> The following comments represent questions and/or suggestions regarding
> certain aspects of the following files which have been offered up for
> public comment.  Since all of the files are interrelated, I am posting
> one message in response.

As John has already pointed out, the documents may be interrelated but actually
break down into two separate groups: (1) The new versions of RFC1425, RFC1426,
and RFC1427, and (2) The new draft of the pipelining document.

> ...

I don't plan to implement any of these changes in regards to what SMTP
servers do or don't say unless I'm directed to do so. These are at best
only superficial formatting issues, and I concur with John's take on what
is or is not standard practice.

However, there's a more important reason not to mess with any of this now.
These documents are now proposed standards moving to draft standard. As such,
textual changes are supposed to be minimized, and should only be entertained
when the reward is a substantial increase in clarity.

> For File:

> > <draft-ietf-smtpex-pipeline-00.txt>
> >
> >                     SMTP Service Extension
> >                     for Command Pipelining
> >
> > (3)  Improper processing and promulgation of SMTP command
> >      failures. For example, some SMTP servers will refuse to
> >      accept a DATA command if the last RCPT TO command fails,
> >      paying no attention to the success or failure of prior
> >      RCPT TO command results. Other servers will accept a DATA
> >      command even when all previous RCPT TO commands have
> >      failed. Although it is possible to accomodate this sort
> >      of behavior in a client that employs command pipelining,
> >      it does complicate the construction of the client
> >      unnecessarily.

> Even if all addresses are bad, the receiver should still accept a DATA
> command, it should simply throw the message away with a 5xx response
> or send it back to the sender with a message that no valid recipients are
> used.  To do otherwise risks having a message text accepted as an SMTP
> envelope, perhaps consisting of 200 lines of '500 Invalid Command' sent
> back to the sender, who won't know what is going on.

This isn't right. The DATA can and is rejected by many extant SMTP servers
when no valid recipients are present. For that matter, it is perfectly legal
for an SMTP server to reject a DATA command with a 4xx or 5xx code because of
some internal condition. When this happens no change of state occurs, and any
software that assumes there's a change of state without checking the result
of the DATA command is simply broken.

Pipelining doesn't change any of this at all -- you still have to treat the
DATA command as a synchronization point. Asking existing SMTP servers to
unconditionally accept a DATA command so that broken SMTP clients can stay
broken isn't acceptable.

This is a significant issue for batch SMTP, where there's no way to know
whether or not a state change has happened, and as such the client has to
assume a positive response and a server knows that the client assumes this. But
that's not what we're talking about here. Pipelining is quite different from
batch SMTP.
  
> > (3)  MUST NOT, after issuing a positive response to a DATA
> >      command with no valid recipients and subsequently
> >      receiving an empty message, send any message whatsoever
> >      to anyone.

> Why is sending an error message back to the MAIL FROM: address, perhaps
> warning them that their mailer is brain dead?  Oh, perhaps to prevent
> mail loops?

Because their mailer is not brain dead. This is an explicitly allowed case
that is in essence defined by the pipelining draft to mean that no message
has been transferred. This is present as a legal alternative to the preferred
case where the DATA command is rejected when no valid recipients have been
specified.

I opted to compromise on this point to allow more leeway in server
implementations. The only other viable course I see is a stricter one where
servers implementing the pipelining extension MUST reject the DATA command if
no valid recipients are present.

> > S: <wait for open connection>
> > C: <open connection to server>
> > S: 220 innosoft.com SMTP service ready
> > C: HELO dbc.mtview.ca.us
> > S: 250 innosoft.com
> > The client waits for a server response a total of 9 times in
> > this simple example. But if pipelining is employed the
> > following dialogue is possible:
> >
> > S: <wait for open connection>
> > C: <open connection to server>
> > S: 220 innosoft.com SMTP service ready
> > C: EHLO dbc.mtview.ca.us
> > S: 250-innosoft.com
> > S: 250 PIPELINING
> > C: MAIL FROM:<[e-mail]>
> > C: RCPT TO:<[e-mail]>
> > C: RCPT TO:<[e-mail]>
> > C: RCPT TO:<[e-mail]>
> > C: DATA
> > S: 250 sender <[e-mail]> OK
> > S: 250 recipient <[e-mail]> OK
> > S: 250 recipient <[e-mail]> OK
> > S: 250 recipient <[e-mail]> OK
> > S: 354 enter mail, end with line containing only "."
> > The total number of turnarounds has been reduced from 9 to 4.

> When there is a string of multiple responses, should not all but the last
> message contain '-' between the number and the response?

No, you are confusing a multiline response (singular) with multiple
responses (plural).

> If not, then I
> think the document should make this clear,

I completely agree, and I have added text describing this.

> and perhaps indicate that only
> 354 indicates end of stream?

There is no requirement that 354, or any other code, indicates the end of
anything.

> Otherwise, if there is a very slow return
> link, it may not be certain when all responses are returned (unless the
> sender SMTP wants to count and match its outgoing addressees against
> returned responses, which I think is an unnecessary complexity.)

Counting and matching responses with commands sent is absolutely required. This
has always been true in SMTP. It is also not especially complex.

> In the 354 line, the message might be clearer if it read
> 354 enter mail, end with CR,LF, line containing only ".", CR,LF

It is not my purpose to clarify the basic requirements of SMTP here.
I'm trying to use simple illustrative text here that doesn't obscure
the real purpose of these examples.

				Ned