John C Klensin wrote:
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
would be perfectly adequate to permit support for, e.g., 6yz or
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.
Two passing related thoughts regarding backward compatibility:
1) Support for SMTP clients who issue HELO for whatever reason
including the idea that it may be EHLO capable and in violation of
choose to use HELO for a simplistic session transport.
Server still allowed to add its structure text response
to 4yx for HELO clients.
2) Post SMTP session logging or the final reply code and text is
is also passed, but presently only interested in reply code
for any subsequence processing, including rescheduling
(i.e. 4yz - reschedule, 5yz - bounce/delete, 2yz - delete)
I guess my question is, does a SMTP extension need to provide service
keyword? Someone offlist
indicated that SMTP extensions requires one.