Well, it is certainly possible to arrange the additional conneg data so
it is
identifiable as such. As for not affecting the response, I'm not sure I
see the
problem: If the client wants an interop guarantee, it requires a conneg
response, and handles 4yz and 5yz codes as temporary or permanent failures
without regard to what's causing the error.
I guess I don't see how this helps the client much, because you can get
interop failures even when there is a conneg string for each recipient.
It helps the client because it can now distinguish between temporary and
permanent conneg failures.
granted it's necessary for the client to be able to do that, but my point
is that having the server report conneg faliures in the RCPT status code
doesn't relieve the client of the necessity to detect other conditions
resulting from valid conneg strings that can cause delivery failure.
it's not as if the client can rely only on the response code to determine
how to handle the message.
So it seems that the proposal could be usefully simplified by removing the
OPTIONAL vs REQUIRED flag from the CONNEG parameter, and having the server
report back the CONNEG status (yes, no, or tempfail) as part of the
response rather than in the reply/status codes.
That would also work, but I don't think it is a useful simplification because
it creates even more instances where the command succeeded but the client
needed for it to fail. The server side of this is trivial either way.
what it accomplishes is to clearly separate different potential sources of
failure into different indications. a RCPT status codes indicating failure
would mean that the server has a problem with sending the message to the
recipient, as distinct from failures caused by the client's inability
or unwillingness to deliver the message to the recipient based on the
server's conneg report for that recipient.
right now we have the situation where the server is essentially being asked
to report an error (and an error code) which is really happening on the client.
the server doesn't know the reason that the client doesn't want to deliver
the message to the recipient, and it shouldn't be expected to report the
error (or the enhanced status code) in the absence of such knowledge.
that, and once we've established that it's okay to use RCPT to request
information about the recipient's UA capabliities and preferences,
it's hard to imagine that there won't be a demand to use RCPT to request
other information about the recipient's UA or preferences, such as
whether the recipient will honor MDN requests, what languages the
recipient can read, whether the recipient wants to opt-out of spam,
whether the recipient supports vendor-proprietary extension FOO, etc.
(I didn't say that I liked all of these ideas, just that these are
obvious uses of a facility that lets you query UA capabilities.
OTOH I do like some of them.)
and if we go down that path we might really regret having allowed CONNEG
to alter the RCPT reply code.
Keith