RFC 1854 (rfc1854) - Page 3 of 7

SMTP Service Extension for Command Pipelining

RFC 1854                    SMTP Pipelining                 October 1995


2.  The Pipelining Service Extension

   When a client SMTP wishes to employ command pipelining, it first
   issues the EHLO command to the server SMTP. If the server SMTP
   responds with code 250 to the EHLO command, and the response includes
   the EHLO keyword value PIPELINING, then the server SMTP has indicated
   that it can accommodate SMTP command pipelining.

2.1.  Client use of pipelining

   Once the client SMTP has confirmed that support exists for the
   pipelining extension, the client SMTP may then elect to transmit
   groups of SMTP commands in batches without waiting for a response to
   each individual command. In particular, the commands RSET, MAIL FROM,
   SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear anywhere
   in a pipelined command group.  The EHLO, DATA, VRFY, EXPN, TURN,
   QUIT, and NOOP commands can only appear as the last command in a
   group since their success or failure produces a change of state which
   the client SMTP must accommodate. (NOOP is included in this group so
   it can be used as a synchronization point.)

   Additional commands added by other SMTP extensions may only appear as
   the last command in a group unless otherwise specified by the
   extensions that define the commands.

   The actual transfer of message content is explicitly allowed to be
   the first "command" in a group. That is, the RSET/MAIL FROM sequence
   necessary to initiate a new message transaction can be placed in the
   same group as the final transfer of the headers and body of the
   previous message.

   Client SMTP implementations that employ pipelining MUST check ALL
   statuses associated with each command in a group. For example, if
   none of the RCPT TO recipient addresses were accepted the client must
   then check the response to the DATA command -- the client cannot
   assume that the DATA command will be rejected just because none of
   the RCPT TO commands worked.  If the DATA command was properly
   rejected the client SMTP can just issue RSET, but if the DATA command
   was accepted the client SMTP should send a single dot.

   Command statuses MUST be coordinated with responses by counting each
   separate response and correlating that count with the number of
   commands known to have been issued.  Multiline responses MUST be
   supported. Matching on the basis of either the error code value or
   associated text is expressly forbidden.

   Client SMTP implementations MAY elect to operate in a nonblocking
   fashion, processing server responses immediately upon receipt, even



Freed & Cargille            Standards Track