First, the word "pipelining" has two meanings in SMTP.
- PIPELINING commands = an smtp client connects and just blasts the EHLO, MAIL FROM, RCPT TO, and DATA commands all at once (exim refers to this as command synchronization)
- PIPELINING messages = an smtp client connects and sends several messages per connection.
It sounds like they are speaking about #2. According to http://www.exim.org/exim-html-current/doc/html/spec_html/ch41.html#SECTmulmessam, with regards to pipelining to hosts over TLS connections:
Exim sends multiple messages down the same TCP/IP connection by
starting up an entirely new delivery process for each message, passing
the socket from one process to the next. This implementation does not
fit well with the use of TLS, because there is quite a lot of state
information associated with a TLS connection, not just a socket
identification. Passing all the state information to a new process is
not feasible. Consequently, Exim shuts down an existing TLS session
before passing the socket to a new process. The new process may then
try to start a new TLS session, and if successful, may try to
re-authenticate if AUTH is in use, before sending the next message.
What that means is instead of what you expect:
connect->starttls->msg1->msg2->...msgX->quit
Exim does this:
connect->starttls->msg1->end_session->starttls->msg2->end_session...->quit
The above is from memory, I can't recall if "end_session" included disconnecting or not. But I helped a guy troubleshoot this behavior once in IRC and he figured out that the above paragraph meant that it wouldn't pipeline in the first way described if STARTTLS was used to encrypt the session. So unfortunately, the only comment I have is that if you force no TLS for this particular host, it should start pipelining the way they want it, but I feel that is not a good answer at all as I believe all email transfers should be encrypted.