RFC2920 defines an SMTP extension called "pipelining." With pipelining, SMTP commands and replies do not have to be synchronized. To illustrate, consider the following example of a normal (not pipelined) SMTP dialog, in which the server machine's half of the dialog is shown in bold font and the client machine's dialog is not:

220 your.host ESMTP Sendmail 8.12.2/8.12.2; Sat, 16 Feb 2002 08:12:44 -0700 (MST) 
HELO some.domain.com
250 your.host.domain Hello some.domain.com [123.45.67.8], pleased to meet you 
MAIL FROM: <friend@some.domain.com>
250 2.1.0 <friend@some.domain.com> ... Sender ok
RCPT TO: <bcx@your.host>
250 2.1.5 <bcx@your.host> ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself 
                                                message sent, end with a dot
.
250 2.0.0 g1GFCigc025138 Message accepted for delivery 
QUIT
221 2.0.0 your.host closing connection 

The important point to notice about this SMTP conversation is that it is synchronous. The client machine always waits for a reply from the server before sending its next command. For example, in the preceding dialog it waits for the 220 before sending the HELO command, and then waits for the 250 before sending the MAIL command.

Pipelining allows the commands of the client machine to be sent without waiting for the replies from the server machine.^[8] The same dialog as before, but with pipelining enabled, might look like the following (again the server is shown in bold font):

^[8] Note that EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP are still required to wait for a reply before proceeding.

220 your.host ESMTP Sendmail 8.12.2/8.12.2; Sat, 16 Feb 2002 08:12:44 -0700 (MST) 
EHLO some.domain.com
250-your.host.domain Hello some.domain.com [123.45.67.8], pleased to meet you 
250-ENHANCEDSTATUSCODES 
250-PIPELINING                               note this keyword 
250-8BITMIME 
250-SIZE 
250-DSN 
250-ETRN 
250-DELIVERBY 
250 HELP 
MAIL FROM: <friend@some.domain.com>
RCPT TO: <bcx@your.host>
DATA
250 2.1.0 <friend@some.domain.com> ... Sender ok
250 2.1.5 <bcx@your.host> ... Recipient ok
354 Enter mail, end with "." on a line by itself 
                                                message sent, end with a dot
.
250 2.0.0 g1GFCigc025138 Message accepted for delivery 
QUIT
221 2.0.0 your.host closing connection 

In the preceding dialog, notice that the client issued the EHLO command instead of the HELO command, as in the first example. One result of issuing the EHLO command is that the server lists all the SMTP extensions it supports. Note that the list shows the PIPELINING keyword. When this keyword is listed in response to the EHLO command, the client is thereafter allowed to issue selected commands without waiting for a reply from the server.

In our second earlier example, the client issued the MAIL, RCPT, and DATA commands before waiting for a reply. Because pipelining requires DATA to wait, the client waits for replies after issuing that command. The three replies are also grouped together. The first 250 refers to the MAIL command. The second 250 refers to the RCPT command. And the final 354 reply refers to the DATA command.

When there are many recipients to a mail message, pipelining can increase the transmission rate of that message. It is otherwise a benign enhancement to SMTP. Pipelining is turned on by default. If for any reason you wish to turn off that extension you can do so with a Build m4 file command such as this:

APPENDDEF(`conf_sendmail_ENVDEF', `-DPIPELINING=0 ')
                                                
                            to turn off pipelining

The srv_features rule set (srv_features) allows you to turn off PIPELINING on a selective basis using the access database.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10) to determine if PIPELINING support is defined (if it appears in the list, it is defined).