> If I understand both your comments and Keith's suggestion, the key is a > separate command. > > It, too, find that aesthetically preferable. The problem is with efficiency. > > A separate command means 2 commands per recipient and it means at least one > synchronization event, between issuance of this new command and issuance of > the first RCPT-TO. The bandwidth required by the extra command is negligible. I don't think the extra command needs to add another synchronization event; offhand it looks like it can piggyback on the event following the MAIL command. Since all downgrade decisions should be made by the client anyway, there's actually no need for the RCAP command to change the state of the SMTP protocol engine. In other words, the client would be be doing MAIL RCAP a RCAP b RCAP c <wait for responses, then decide what conversions to do for what recipients> * ( *RCPT DATA . ) instead of MAIL <wait> even if another synchronization event were needed, I don't think that's a big price to pay, particularly when the alternative (from a protocol architecture perspective) is to clutter up the RCPT command and (from a implementor perspective) to either a) require a separate RCPT/DATA exchange for each recipient, (far more overhead than your extra synchronization event) b) downgrade to the least common acceptable format for all recipients (assuming there is one - which might be true for fax but is not a reasonable assumption in general), or c) send RSET following all the RCPTs if it is desirable to send different versions to different recipients, followed by another set of RCPT/DATA exchanges - again resulting in far more overhead than a single additional synchronization eent. Keith