John C Klensin wrote:|
Before we try anything like that, we need actual feature negotiation (not just announcements), which ESMTP lacks.Without debating where "actual feature negotiation" starts, it seems to me that -- Server announces that it can supply extra reply code information for traffic flow control -- Client announces, via an extension argument to MAIL or RCPT (or, in principle, via a new verb) that is it willing to accept such codes. -- Server uses the code iff both announcements have occurred. would be perfectly adequate to permit support for, e.g., 6yz or x7z codes.
Agreed. In referring to "feature negotiation," I was actually thinking of a new verb, since the extension would be enabled for the entire session, not just one message; and I'm already feeling some pain over MAIL FROM parsing. (Don't ask.) What matters most though, IMHO, is a precedent for the next extension that needs the same "Server Has"/"Client Wants" interchange. That's actually something I've wished for for a long time, and I suspect most of us have implemented privately many times over.