RFC1854 describes an SMTP service extension which is advertised in the
EHLO response as PIPELINING.
Advertising PIPELINING is a promise that the receiver-SMTP won't
discard input or output if more than one command is transmitted at a
time (even if errors occur), and that its state machine is implemented
sensibly, returning reasonable error codes in response to
out-of-sequence commands (eg DATA after no valid RCPTs).
Any sanely implemented UN*X MTA which doesn't fork/exec halfway
through an incoming SMTP conversation should advertise PIPELINING, and
Exim falls or should fall in this category.
If Philip agrees that Exim doesn't deliberately flush its input
buffers, or switch between using stdio and system calls for SMTP
incoming conversations, or exec after reading from or writing to an
incoming SMTP session, or do other things that might lose buffered
input or output, then the EHLO response have PIPELINING included.
Even nicer would be if Exim's sender-SMTP would take advantage of
PIPELINING when offered by a remote receiver-SMTP, but this is
obviously much more work. Advertising PIPELINING in a receiver-SMTP
doesn't imply that the sender-SMTP will make use of other receivers'
pipelining capability.
Thanks,
Ian.
--
*** Exim information can be found at
http://www.exim.org/ ***
