Extensions to SMTP

John C Klensin | 18 Aug 1992 18:57

Re: Another thread.

>  It probably wins you a lot of grief.  Unless the design takes into
>account the buffering and forking assumptions of sendmail, it will surely
>not work with all implementations.

Neil,
  I don't understand this.  Not only have I repeatedly heard about
implementation that do a certain amount of streaming to minimize
stop-and-wait behavior, but I see nothing in the protocol that requires
that behavior.  Now one much clearly keep careful track of the responses
that come back to know what verbs they are associated with, but nothing
in the protocol, as I read it, justifies sending those back out of 
order.
  I've heard debates about whether one has to stop and wait before
sending DATA, or whether one send DATA and then wait for everything up
to the 354, but those are most of the active debates I'm aware of.
  Now, if an implementation lost state completely (i.e., behaved as if
an implicit RSET had been delivered) after sending a 5xx reply to
something, there clearly might be a problem but, even then, I read 821
to imply that it would just have to keep sending "command out of
sequence" replies to subsequent verbs until some real resetting action
occurred.
  Of course, I am here taking into account the (non-existent) buffering
and forking assumptions of RFC821, rather that those of any particular
correct or incorrect implementation.
     --john

headers

Neil W Rickert | 18 Aug 1992 19:47

Re: Another thread.

 on command streaming:

>>  It probably wins you a lot of grief.  Unless the design takes into
>>account the buffering and forking assumptions of sendmail, it will surely
>>not work with all implementations.

>Neil,
>  I don't understand this.  Not only have I repeatedly heard about
>implementation that do a certain amount of streaming to minimize
>stop-and-wait behavior, but I see nothing in the protocol that requires
>that behavior.  Now one much clearly keep careful track of the responses
>that come back to know what verbs they are associated with, but nothing
>in the protocol, as I read it, justifies sending those back out of 
>order.

Firstly, let me make it clear that I am only a user of sendmail, not
the designer.  I believe the following is a fairly accurate picture of
how it handles the protocol.  As background, sendmail reads the TCP
stream as a buffered stream.  If you are not familiar with Unix, remember
that in normal process creation, fork() creates a child in almost all
respects identical to the parent - and, most important, that there is
no shared memory between parent and child.

    MAIL:
	On receipt of this command, sendmail fork()s.

	Parent:	wait for child.
	Child:	continue processing the tcp/ip buffered stream.

    RSET and the '.' at the end of data, reset state by

(Continue reading)