PIPELINING

PIPELINING

---

Enable PIPELINING SMTP extension

tune with confENVDEF

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: <[e-mail]>  250 2.1.0 <[e-mail]>  ... Sender ok RCPT TO: <[e-mail]>  250 2.1.5 <[e-mail]>  ... 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: <[e-mail]> RCPT TO: <[e-mail]> DATA  250 2.1.0 <[e-mail]>  ... Sender ok  250 2.1.5 <[e-mail]>  ... 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=   ')   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).