> You can avoid the need for additional round trips by batching all the > capabilities queries with the first RCPT TO. But this results in a rather sharp > rise in implementation complexity. surely is it less complex than what is required by the current protocol - i.e. doing a RSET followed by additional MAIL and RCPT commands. > > That's quite a bit of overhead, for something that frequently will have no > > effect on the content being transferred. actually I don't see why putting the conneg response in a separate command is "quite a bit of overhead" - the extra bandwidth required for "RCAP <recipient>" is neglibible, there's no difference in the response at all, and the client logic to deal with separate commands is simpler since the client doesn't have to distinguish ordinary RCPT failures from CONNEG failures. and the client doesn't have to do RSET followed by a separate set of MAIL/RCPT commands for each recipient if for some reason it wants or needs to deliver different versions of the message to different recipients. > Indeed. The average number of recipients for legitimate mail does tend to be > quite small, which implies we're optimizing the uncommon case here. to understand the tradeoff it may be useful to compare each proposal under the same set of scenarios. e.g. a. single recipient b. multiple recipients, all with similar capabilities c. multiple recipients, different capabilities d. multiple recipients, mutually exclusive capabilities with each case evaluated for a. ease/simplicity of implementation, b. necessary round-trip delays, c. future extensibility Keith