> But there's a serious side effect: Advance capability retrieval tends to stall > the pipeline. And while it is natural to view SMTP as a series of commands and > responses, the way modern SMTP clients and servers need to work to be efficient > is by sending batches of commands and getting back batches of responses. > > The naive implementation of capabilities exchange in a separate command then > becomes the worst case scenario: If you send a VRFY (or RCAP) prior to sending > each RCPT TO you end up with at least one round trip per recipient. I don't understand which argument you're making - is it that the naive implementation is slow, or that it's too hard to do an efficient pipelining implementation? as long as RCAP doesn't force any new decision points for the client, I don't see why the efficient pipelining implementation is any more difficult for the RCAP case than the RCPT/RSET case. if RCPT is overloaded then the client sends multiple RCPTs, waits for all of the responses, then decides whether to just send one copy or do RSET/MAIL/etc and send multiple copies. if there's a separate command then the client sends multiple RCAPs, and one RCPT, waits for all of the responses, and then decides whether the version that's right for the first recipient is also appropriate for other recipients. seems like the implementation complexity is about the same in either case. either way the sender wants to divide up the recipients into separate classes and batch up the messages to each. assuming it's trying to optimize, that is. of course the naive/inefficient implementation is quite easy (and equally slow) for both proposals - just use no more than one recipient per SMTP session. but it's hard to see how the client can avoid implementing some kind of logic to convert differently for different recipients, since there's clearly the potential for the recipients' conneg strings to have no format in common. perhaps if the client can only do one or two different kinds of conversion (otherwise it has to bounce) then the decision becomes a bit easier, but this again looks more like a fax-specific facility than a general one. Keith