> > > 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. > how so? Because you said: "other conditions resulting from valid conneg strings that can cause delivery failure." If the conneg result is something you do not like I don't think treating this as a temporary failure in hopes the conneg string will change in the future is either reasonable or appropriate. > if there is a temporary failure to get conneg information, the > client might quite reasonably decide to retry later. or if the client > can't translate part of the message, it might reasonably decide that > delivering the remainder of the message is preferable to bouncing it. That wasn't the case you were talking about. > > 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". > it's still poor separation of function, and it's still asking the server > to report a failure condition which the client understands better than the > server does. E.g. the server is told to report errors as 4.3.3 or 5.3.3 > when codes x.6.1 or x.6.2 or x.6.3 might be more appropriate. The server > can't tell the difference between those conditions; the client can. Ah, I see. We've moved from assertions that there were sure to be problems to the nonspecific "poor separation of function". But the entire point of REQUIRED is to say "I don't want these functions separated; conneg failures are just like any other failure to me". So this entire line of argument turns out to be specious. > > > 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. > well, if we had such other features then the client wanting to assert such > other features would not be able to assert CONNEG=REQUIRED, it would just > have to implement the error detection by itself. Doesn't follow. If some other functionality is implemented that results in RCPT TO failing in some new way it can return errors in the same way. Of course the error report is limited to a single error condition, but the potential for multiple failures having to be collapsed into a single return value already exists in abundance; the existance of this extension or an arbitrary number of future extensions changes nothing in this regard. > > 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. > The overall effect of REQUIRED is probably to increase the number of > implementation errors and the number of mis-reported delivery failures. Well, I've worked out what code is necessary to do this, and IMO this just doesn't rise to the level of complexity for this to be the case. > It's by no means the worst thing I've ever seen in a protocol, nor is > it the worst thing in this proposal. Getting rid of REQUIRED just > makes the protocol slightly cleaner. It doesn't get rid of the RSET > ugliness, it doesn't address the applicability of this extension to > non-fax scenarios, nor the lack of attention to other issues. > These other things need to be considered also. > But given the importance of SMTP and the fragility of the mail system > I think that the fewer warts we add to SMTP the better off we'll be. Keith, I was willing to give you the benefit of the doubt before. But now that your concerns about this have become clear I'm finding I flat out disagree with your assessment of the risks and concerns involved. Ned