RFC 1854 (rfc1854) - Page 2 of 7
SMTP Service Extension for Command Pipelining
Alternative Format: Original Text Document
RFC 1854 SMTP Pipelining October 1995
until some intermediate point in the SMTP dialogue.
When this is done material read from the TCP connection
and kept in process buffers can be lost.
(2) Flushing the TCP input buffer when an SMTP command
fails. SMTP commands often fail but there is no reason
to flush the TCP input buffer when this happens.
Nevertheless, some SMTP servers do this.
(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
accommodate this sort of behavior in a client that
employs command pipelining, it does complicate the
construction of the client unnecessarily.
This memo uses the mechanism described in [2] to define an extension
to the SMTP service whereby an SMTP server can declare that it is
capable of handling pipelined commands. The SMTP client can then
check for this declaration and use pipelining only when the server
declares itself capable of handling it.
1. Framework for the Command Pipelining Extension
The Command Pipelining extension is defined as follows:
(1) the name of the SMTP service extension is Pipelining;
(2) the EHLO keyword value associated with the extension is
PIPELINING;
(3) no parameter is used with the PIPELINING EHLO keyword;
(4) no additional parameters are added to either the MAIL
FROM or RCPT TO commands.
(5) no additional SMTP verbs are defined by this extension;
and,
(6) the next section specifies how support for the
extension affects the behavior of a server and client
SMTP.
Freed & Cargille Standards Track