> 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. 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. If the client wants an interop guarantee (how does the sender specify this?) then it can reat the absence of the CONNEG string in the response, or the absence of CONNEG in the EHLO response, as a failure. This should really be a client-generated error anyway since there's really no error on the server side. I think this would be a significant improvement - particularly if this extension isn't generalized to support things other than fax and it then becomes necessary to add another extension later for voice mail or whatever. Keith