> > > 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
