> > > But, in that "two message" case, one really doesn't want 5yz > > > codes coming back from the server in response to a RCPT TO. > > > If the "one digit" rule is observed, there is no way to > > > differentiate between "bad mailbox" and "bad parameter". If > > > it is not, and three digits are processed, the server cannot > > > effectively differentiate between a bad parameter to CONNEG > > > and one to some other option by the code -- the reply string > > > has to be parsed, and that leads to bad trouble. So I would > > > think that a batch of capability-determining commands before > > > the first RCPT one would be a better idea, complexity > > > notwithstanding. > > I'm not sure I get what you're driving at here. The client gets > > to choose whether the server treats a recipient with unknown > > capabilities as an error or simply by indicating as much. > Suppose the client sends > RCPT TO:<foo@bar.baz> CONNEG=REQUIRED;bazoption=REQUIRED > and gets back > 504 option parameter stinks - REQUIRED > or > 504 bad parameter - CONNEG REQUIRED If the server after having offering the CONNEG and bazoption extensions subsequent rejects them as "bad", it is broken. Simple as that. And trying to accomodate arbitrary broken server behavior is an exercise in futility. I suspect what you meant is something more along the lines of 504 required information not available for this recipient or 504 required CONNEG information not available for this recipient > in the one-digit case, it can't distinguish either one from > 500 Never heard of foo > in the three-digit case, the first 504 variant doesn't give a > clue as to the difference between "don't know the client's > capabilities" and "REQUIRED is not a valid parameter for > bazoption". The second variant is better, but requires parsing > of a string whose format is not precisely specified. To some > degree, this is a general problem with multiple ESMTP > option-parameter sets, but it seems to be that the CONNEG case > is a little worse than average. But the entire point of REQUIRED is that client is stating categorically that no such distinction needs to be made. The client is saying "CONNEG and bazoption are vital to me, if either of them fails I'm giving up on this recipient and you should too -- give me an error and I'll report that back to the originator". A client that wants to proceed in the case where no CONNEG information, bazoption information, or both are available it has no business using REQUIRED. > Yes, but what a nightmare. To really get it right may require > fairly complete knowledge of what the client can actually do > _and_ fairly complete knowledge of what the recipient (not just > the receiving server) can actually do. In a better world, that > requires an MUA-MUA negotiation, but we don't have any semantics > for talking about that (especially in SMTP). Of course, forcing > the problem into > one receiving MUA > no relay > would permit getting close without giving all of us a bad > headache. But I don't know if that is feasible. What I'm > getting fairly sure of is that the present document is rather > seriously underspecified for the mind-boggling general case. I'm afraid I'm coming to a very different conclusion. I think these discussions have conflated a bunch of different things: (1) Specification bugs that definitely need to be fixed, (2) A single protocol change that definitely should be made -- that of making conneg information and status identifiable as such in the command response, (3) A bunch of concerns about protocol details that aren't standing up to close inspection and which absent a clear consensus for change can remain as-is, and (4) A general concern about the many possible uses for this mechanism that has all of us engaging in futile speculation and which cannot possibly be dealt sensibly with in a specification without actual implementation and use experience. Of course (1) and (2) need to be fixed before proceeding. As for (3) and (4), well, this is why we have a standards process and not a rubber stamp. Ned