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(_at_)bar(_dot_)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