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