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.
Sure, but it is only useful to treat such failures as permanent.
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.
I remain unconvinced that this is a useful distinction. What REQUIRED says is
"I absolutely require CONNEG info and as such a failure to have it is the same
to me as any other sort of failure and should be responded to accordingly".
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.
I guess this is a valid assessment, but somehow it doesn't offend me
the way it offends you.
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.)
Language preferences are, I believe, already defined as something you can get
out of feature algebra.
and if we go down that path we might really regret having allowed CONNEG
to alter the RCPT reply code.
Why? If the client doesn't want CONNEG to alter the status all it has to do is
use OPTIONAL rather than REQUIRED. Again, REQUIRED implies that the client is
willing to treat different sorts of failures in the same way.
Again, I think a means of distinguishing conneg material in the response is a
good idea and I'm not opposed to eliminating REQUIRED. But really don't believe
REQUIRED causes the problems you think it does.
Ned