--On Sunday, October 30, 2011 08:26 +0000 Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
On 29/10/2011 21:10, John C Klensin wrote:
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, this assumes you don't want the 'new' response
before the negotiation.
In the case of a 'wait' extension, it would be 'nicer' to have
<connection>
421 Server in maintenance, try later wait:600
With three qualifications, you can do that today:
(i) According to RFC 5321, 421 is one of the replies
that has a specific syntax. It must appear as
421 <domain> SP <string>
not just
421 <string>
So the above cannot be used here at all and cannot be
used anywhere else without a server offer and client
acknowledgment.
(ii) It depends on a slightly stretched interpretation
of "(This may be a reply to any command if the service
knows it must shut down)" )or the similar text in
Section 3.8). Precisely speaking, connection opening
isn't a command and you are describing a slightly
different situation from "about to shut down". I think
that interpretation might be reasonable, but, if it were
to go anywhere, it needs discussion in a dedicated
thread.
(iii) The client may not interpret the string as meaning
anything at all other than "temporary failure, retry
sometime".
Regardless of "nicer", that is about the best you can do with
the SMTP mode. You know that already.
rather than
<connection>
220 hi
EHLO me
220-AUTH LOGIN
220 SMTPRETRY
AUTH <stuff>
220 OK (which may need to be faked if the real auth database
is not available)
...
Not _quite_ that bad because the statement about 421 above
clearly applies to AUTH. So, unless I'm missing something,
[...]
220 SMTPRETRY
AUTH <stuff>
421 <smtp.my.example> in maintenance, try later wait:600
Would be perfectly valid today without needing an "server
offers" extension (with or without a client request. They might
still be a good idea (see other notes), but, if you are willing
to risk having the reply text treated as noise, there is no
problem.
john