Hi all, Nothing like a good bun fight to grab my attention ;) Having followed this discussion with interest and having tried to follow the technical side of the argument, I find myself agreeing with Keith Moore's notion of using an RCAP (or whatever) command to determine recipient mailbox capabilities. I don't know if the following contributes anything or nothing to the debate, hopefully it is food for thought. Apologies for any repitition or lack of clarity in what follows, it's late afternoon here and I'm writing quickly. Using RCAP leads, I feel, to a simpler client and clearer error reports. The loss of performance due to issuing two commands per recipient is not really releveant here, IMO. If I were to design a client that transmits a message in various formats to a number of recipients, I would first collect the CONNEG capabilities using an RCAP command for each recipient. I do not care whether the recipient mailbox is valid, all I want is the CONNEG string. I feel that it is necessary that RCAP should be issued before MAIL FROM:. The error code for RCAP is simple and clear, either CONNEG was available or it wasn't and, in particular, it is not affected by the server's ability to relay or deliver to that mailbox (I can see no reason that prevents RCAP from supplying valid CONNEG strings for non-existent mailboxes, perhaps this is even desirable sometimes). Furthermore there is no need for a REQUIRED/OPTIONAL or similar parameter to RCAP. Having obtained all recipient capabilities, the client can make a decision either to remove the failing RCAP recipients from the list and report an error for them - the temporary RCAP failures can obviously be retried later - or to send them the LCD version of the document. The decision on how to proceed has been determined entirely by the client based on information supplied by the server. The server has not tried in any way to second guess the client's intentions or apply any particular intelligence to the situation. Based on CONNEG capabilities, or lack of them, the client can now either generate (or select the best versions from a previously delivered multipart/alternative document, say) for each recipient. At worst a different document is sent to each recipient, at best the same document is sent to all of them. The client can now simply progress to issuing a separate transaction (i.e. MAIL FROM ... RCPT TO ... DATA) for each version of the document and the associated recipients. Error handling for MAIL FROM etc. is identical to the normal case when RCAP is not used. PIPELINING won't affect things much here, all the RCAPs can be pipelined and the client pauses after issuing the last RCAP until it has all the responses, then proceeds with MAIL for the first version of the document. RSET is never required in this scenario (barring errors that make it necessary). I also like RCAP because it does not overload two potential failure modes (CONNEG not available vs recipient not available) on one error code (extended or not). By contrast with the sceanrio outlined above, overloading RCPT means that the client cannot determine what document to send until the entire recipient list is sent (using RCPT) at which point there is no going back, either RSET is issued and we start again with one or more transactions determined by the number of document versions needed or the LCD document is sent with all the problems raised elsewhere in this thread. Even with an overloaded RCPT command, I'd probably design a client to issue MAIL, RCPT ... CONNEG=whatever, ... pause just before DATA and if more than one document version is needed RSET and proceed with a number of transactions as outlined above. Given the extra work MAIL, RCPT and RSET must do and when all I want is the CONNEG string, I'd personally rather have the simpler, more lightweight RCAP command available. More importantly, because the server potentially has to choose which error to report from recipient failure vs conneg failure (not an easy choice, I'm sure) I feel that overloading RCPT leads to loss of useful information at the client. On balance, I would rather code for the "edge cases" over two commands than present potentially ambiguous and misleading reports to the message sender. Just my 0.02 Euros worth. Of course, I may be way off the mark - I am prepared to be convinced that the extended RCPT command is the better choice but so far RCAP seems preferable to me. Brian Stafford