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