--On Friday, October 28, 2011 23:51 -0700 "Carl S. Gutekunst"
<csg(_at_)alameth(_dot_)org> wrote:
...
John suggested a new reply code series, but that scares me a
bit; what would a staunch legacy implementation be likely to
do with that?
It would infer that it was talking to something other than an
SMTP server, and drop the connection as rapidly as possible to
avoid doing further damage.
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.
Whether it is a good idea or not is another question, but it
seems to me that the protocol design is adequate.
Of course, with that model, as with any other negotiation (or
offer-accept) model, if the client doesn't announce that it is
interested in whatever the server is offering, the server should
almost certainly use standard codes and assume that the client
won't pay any attention to anything special it is offering.
john