On Thu, 22 Apr 2004, Matthew Byng-Maddick wrote:
>
> Other things about this standard appear to be totally braindead, (VRFY causing
> a change of state - you what!?) so it's not clear that a client can't
> believe that it's allowed to send other things, because of the unclearness
> between what goes in one TCP send operation and the places where it is
> pausing for a response. In particular, if one does several send operations
> one after the other, but without waiting for a response (having switched
> off Nagle, of course), then it would appear to be conformant to STD60 as
> specified, but would cause a synchronization error in exim.
No that isn't allowed. Pipelining clients have to employ some
sophisticated knowledge about the transport layer.
Client SMTP implementations MAY elect to operate in a nonblocking
fashion, processing server responses immediately upon receipt, even
if there is still data pending transmission from the client's
previous TCP send operation. If nonblocking operation is not
supported, however, client SMTP implementations MUST also check the
TCP window size and make sure that each group of commands fits
entirely within the window. The window size is usually, but not
always, 4K octets. Failure to perform this check can lead to
deadlock conditions.
--
Tony Finch <dot@???>
http://dotat.at/
