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